Control plane

• private core
• private runner
• optional marketplace API service
• compatibility database
• verification pipeline

Data plane

• plugin OCI images
• customer-owned runtime
• customer-selected registries

Public plane

• plugin catalog UI/API
• plugin manifests
• publisher docs
• verification badges

1. Plugin manifest registry

Stores metadata only.

Manifest fields:

api_version: v1
name: jira-ticket
publisher: acme
display_name: Jira Ticket Plugin
description: Create and update Jira issues
runtime:
  type: oci
  image: ghcr.io/acme/aisopsflow-plugin-jira@sha256:...
entrypoints:
  send:
    path: /send
compatibility:
  runner_api: v1
  min_core: 1.2.0
  min_runner: 1.2.0
capabilities:
  - outbound_http
  - secrets_read
network:
  outbound_hosts:
    - jira.example.com
security:
  signed_image: true
  sbom_attached: true

2. Verification pipeline

Runs before a plugin gets a verified badge.

Checks:

• manifest schema validation
• image pull by digest
• signature verification
• SBOM presence
• vulnerability scan
• conformance test run
• policy lint
• optional manual review

Outputs:

• verified / unverified state
• compatibility result
• security findings summary

3. Conformance test harness

A language-neutral test suite that validates:

• endpoint availability
• JSON contract compliance
• internal auth verification
• error response semantics
• timeout behavior
• backward compatibility with runner API version

4. Plugin execution policy

Enforced by runner.

Policy inputs:

• manifest capabilities
• tenant admin approval
• deployment profile
• allowlist / denylist

Policy decisions:

• allowed image registries
• required image signatures
• allowed outbound hosts
• CPU/memory limits
• secret access scope
• whether plugin is first-party only or third-party allowed

5. Catalog service

Public read path:

• browse plugins
• search by category / capability
• see versions and compatibility
• see verified badge and publisher reputation

Private write path:

• publisher registration
• manifest submission
• verification status
• deprecation notices

Publish flow

1. publisher builds plugin image
2. publisher signs image and publishes to OCI registry
3. publisher submits manifest to catalog
4. verification pipeline runs
5. catalog publishes plugin metadata and compatibility state

Install flow

1. tenant admin selects plugin from catalog
2. AisOpsFlow stores approved plugin reference by digest
3. runner pulls image according to local registry policy
4. runner launches plugin under resource/network policy
5. runner communicates with plugin over published HTTP/JSON contract

Upgrade flow

1. publisher releases a new plugin version
2. verification reruns
3. compatibility matrix is updated
4. tenant admin chooses pinned upgrade
5. runner rolls to the new digest

Trust boundaries

• core trusts only runner
• runner trusts only plugins that pass local policy
• plugin-to-core callbacks must use signed internal auth

Hard requirements

• pull by digest, not mutable tag
• signed image required for verified plugins
• non-root containers
• read-only filesystem by default
• explicit env/secret injection
• per-plugin network egress policy

Optional hardening

• sandboxed runtime profile
• seccomp/apparmor profile
• isolated network namespace
• audit trail for plugin pull/start/stop/request failures

Mode A: first-party only

• only official plugins
• simplest starting point

Mode B: curated third-party

• publisher submission
• verification required
• admin opt-in per tenant

Mode C: fully self-hosted catalog

• customer runs their own catalog mirror
• useful for regulated on-prem environments

Recommended order:

1. Mode A
2. Mode B
3. Mode C

Publisher identity

• verified publisher profile
• signing key registration
• support and security contact

Deprecation

• plugin can be marked:
  • active
  • deprecated
  • insecure
  • removed

Reputation

• verification badge
• download/install count
• issue rate
• last compatibility check date

Phase 1

• public plugin spec repo
• first-party plugin manifests
• digest-pinned plugin install
• local conformance tests

Phase 2

• publisher submission flow
• verification pipeline
• public catalog UI/API

Phase 3

• tenant-scoped plugin marketplace
• paid/private plugins
• customer-hosted catalog mirror