112 — Agent Supply Chain Security

Concept overview

An agent's supply chain extends beyond application packages. Behavior depends on model artifacts or hosted versions, prompt bundles, tool schemas, connector binaries, retrieval corpora, policy files, and runtime images. A change to any of these can alter the actions the system takes even when application code is unchanged.

Build a release manifest that identifies every behavior-relevant dependency and its approved provenance. Verify artifacts before execution and separate content acquisition from authority to enable capabilities. Signed provenance can show where an artifact came from and how it was built; it does not prove the artifact is safe, correct, or appropriate for the workflow.

Why it matters in production

Proof of concept

A proof of concept should inventory external packages, models, prompts, and tools and avoid executing downloaded components with broad host credentials.

Production

Production requires pinned artifacts, integrity verification, reviewed capability changes, dependency scanning, provenance records, and release evaluation of the complete agent bundle.

Enterprise scale

Enterprise scale adds trusted build identities, private registries, transitive dependency review, emergency revocation, reproducible release manifests, and ownership across connector and model providers.

Architecture components

Dependency and capability inventory

Lists packages, models, prompts, corpora, tools, and the permissions each component can exercise.

Trusted build pipeline

Produces immutable artifacts and provenance tied to controlled source and build identities.

Artifact registry

Stores approved versions, digests, attestations, ownership, and revocation status.

Admission verifier

Checks integrity, provenance policy, compatibility, and requested capabilities before enabling a release.

Runtime monitor and rollback controller

Detects unexpected capability or artifact changes and returns to an approved compatible release when necessary.

The architecture, mapped

flowchart LR
    S["Controlled source and dependencies"] --> B["Trusted build"]
    B --> P["Artifact and provenance"]
    P --> R["Approved registry"]
    C["Capability change review"] --> A["Release admission verifier"]
    R --> A
    E["Regression evidence"] --> A
    A --> W["Constrained agent runtime"]
    W --> V["Revocation and compatible rollback"]

Runtime flow

1. 1

   Inventory behavior inputs

   Enumerate executable dependencies and non-code artifacts that influence tool selection, retrieval, policy, or model behavior.

2. 2

   Build and attest

   Produce controlled artifacts and provenance identifying source, build process, and immutable output digests.

3. 3

   Review capability changes

   Compare requested permissions and tool schemas with the previous release; route material expansion to the responsible owner.

4. 4

   Verify before activation

   Check digests, trusted provenance, revocation status, compatibility, and evaluation evidence for the entire release bundle.

5. 5

   Run with constrained authority

   Grant only approved capabilities and observe actual tool use so a trusted artifact cannot silently acquire broader permissions.

6. 6

   Revoke and recover

   Disable compromised versions, identify affected workflows through manifests, and roll back only to a compatible approved bundle.

Connector release integrity

Enterprise software · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

Illustrative architecture: A platform team upgrades a document connector used by several customer-facing assistants.

The problem

The new package may contain an unexpected dependency or advertise a write capability that the old release did not expose.

Agent requirement

Verify the deployed artifact and explicitly review any permission expansion before customer workflows can use it.

Architecture

A release manifest pins connector digest, tool schema, prompt bundle, and policy version; admission verifies provenance and evaluation results before enabling the connector.

Runtime

• Build connector artifact
• record provenance
• diff capabilities
• run denied-action tests
• verify digest at deployment
• monitor active manifest

Failure scenario

The runtime discovers a tool schema that differs from the approved manifest; the connector is quarantined until the owner reviews the change.

Operational impact

Measure manifest coverage, verified artifact rate, unreviewed capability changes, revocation propagation time, and recovery success rather than equating signatures with security.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Auditing application packages while ignoring prompts and tool schemas.

Inventory all behavior-relevant artifacts and their release ownership.

Treating a valid signature as proof of safe behavior.

Combine provenance with scanning, permission review, isolation, and workflow evaluation.

Rolling back one component without checking compatibility.

Restore a tested bundle whose models, prompts, tools, and policy versions work together.

When to choose this pattern

Choose it when

• Agents depend on third-party tools, connectors, executable plugins, or downloaded model artifacts.
• Several teams independently update components that affect agent behavior.
• A platform needs to identify and revoke every workflow using a compromised dependency.

Avoid it when

• A component has no executable or behavior-changing role in the agent workflow.
• The proposed verification process cannot identify an accountable artifact owner or trusted build source.
• Provenance checks would be used as a substitute for runtime authorization and isolation.

Architecture checklist

• Inventory code and non-code dependencies that affect agent behavior.
• Pin immutable artifact digests and maintain a complete release manifest.
• Verify provenance against trusted build identities before activation.
• Review tool schema and permission changes independently of package version changes.
• Evaluate the complete model, prompt, tool, corpus, and policy bundle.
• Constrain runtime capabilities even for approved signed artifacts.
• Test revocation propagation and compatible rollback across affected workflows.

Related concepts

• 11 — Tool Invocation & Function Calling
• 24 — Prompt Injection Mitigation
• 27 — Responsible AI Governance (ISO/IEC 42001)
• 30 — Non-Repudiation Logs
• 35 — Adversarial Prompt Testing
• 44 — Human-in-the-Loop (HITL)
• 60 — Chaos Engineering for AI
• 93 — Model Versioning and A/B Testing
• 100 — Asynchronous Fine-Tuning Pipelines

Primary references

• SLSA specification version 1.2
• SLSA build provenance
• Kubernetes: Pod Security Standards
• NIST SP 800-207: Zero Trust Architecture