Plugins

Make external capabilities reviewable.

Plugins and tools can extend AutoDevOps, but third-party and customer-authored capabilities are code with permissions. They need explicit manifests and trust treatment.

Security manifest

Declare the permissions and evidence a reviewer needs before trusting a capability.

ts
const myPlugin = {
  metadata: {
    id: 'my-plugin',
    name: 'My Plugin',
    version: '1.0.0',
    trustLevel: 'customer_internal',
    securityManifest: {
      trustLevel: 'customer_internal',
      files: {
        read: ['src/**/*.ts'],
      },
      network: {
        egress: 'none',
      },
      policyTags: ['code-quality'],
      emittedEventFamilies: ['result'],
      auditEvidence: ['analysis-summary'],
    },
  },
};

Trust levels

Trust levels drive review expectations and fail behavior.

Trust levelMeaningDefault treatment
Built-in AutoDevOpsShipped in this repo and covered by AutoDevOps review/tests.Can emit trusted AutoDevOps signals where the runtime already allows it.
Customer-internalBuilt and approved inside the customer boundary.Requires manifest and policy metadata.
Vendor-providedThird-party package approved by the customer.Requires manifest, provenance, version, and stricter default approval handling.
Untrusted/local-devLocal experiment or unsigned extension.Dry-run by default where possible; sensitive execution fails closed.

Manifest checklist

Use this before loading a new external capability.

  • File read/write scope.
  • Command execution scope.
  • Network and egress scope.
  • Environment variable and secret access requirements.
  • Cloud resource access requirements.
  • Approval requirements.
  • Policy tags and sensitivity hints.
  • Emitted event families.
  • Default audit evidence.

Implementation status

The current implementation validates and displays manifest metadata. Some permission scopes are metadata first and enforcement second.