Agent Supply-Chain Integrity

Threats mitigated

• T11 Unexpected RCE and Code Attacks

  Tools or environments enabling unexpected code execution, presenting direct risks to code execution environments.

• T16 Insecure Inter-Agent Protocol Abuse

  Attackers abuse the trust and control semantics of agent interoperability protocols such as MCP and A2A: manipulating server responses, injecting context, publishing misleading tool descriptions or exploiting ambiguous consent flows.

• T17 Supply Chain Compromise

  Vulnerable, malicious or outdated components enter the agent through models, libraries, tools, plugins, prompt templates, build environments or framework updates.

OWASP AISVS coverage

The AISVS 1.01 chapters and verification requirements this control helps satisfy.

C3 Model Lifecycle Management & Change Control

• C3.1.2 Level 2

  Verify that all model artifacts (weights, configurations, tokenizers, base models, fine-tunes, adapters, and safety/policy models) are cryptographically signed by authorized entities.

• C3.1.3 Level 2

  Verify that model cryptographic signatures are verified at deployment admission and on load.

C6 Supply Chain Security for Models

• C6.1.1 Level 1

  Verify that models are scanned for malicious code before import.

• C6.1.2 Level 1

  Verify that model weights, datasets, and fine-tuning adapters are downloaded only from approved sources.

• C6.1.3 Level 2

  Verify that every third-party model artifact can be integrity-verified.

• C6.1.4 Level 2

  Verify that models pass a behavioral acceptance test suite before being promoted to any non-development environment.

• C6.2.1 Level 1

  Verify that every model artifact publishes a version-controlled, machine-readable AI BOM listing datasets, weights, licenses, and data-origin statements.

• C6.2.2 Level 2

  Verify that AI BOMs are cryptographically signed before deployment.

• C6.2.3 Level 2

  Verify that AI BOM completeness checks fail the build if any component metadata is missing.

C9 Orchestration & Agentic Security

• C9.2.5 Level 2

  Verify that any self-modification capability (e.g., prompt rewriting, tool-list changes, parameter updates) is restricted by boundaries that are enforced by the runtime and cannot be changed or bypassed by the agent.

• C9.3.7 Level 2

  Verify that external resources named in model output are verified against an approved allow-list or registry before the agent installs or invokes them.

C10 Model Context Protocol (MCP) Security

• C10.1.1 Level 1

  Verify that MCP components are obtained only from trusted sources and cryptographically verified.

• C10.4.8 Level 3

  Verify that MCP clients maintain a snapshot of tool definitions and that any change to a tool definition triggers re-approval before the modified tool can be invoked.

Design phase

Architecture, threat modelling and policy decisions made before code is written. 4 tasks.

Agent Artifact Inventory

• Treat prompt templates, system prompts, agent cards, tool definitions and MCP server configs as versioned code, not runtime settings
• Define the AI bill of materials (AIBOM / agent SBOM) the build must produce: models, datasets, adapters, libraries, tools, servers and their licences (AISVS C6.2.1)
• Decide approved sources for weights, datasets, adapters and tools (AISVS C6.1.2) and who may approve a new one
• Plan isolated, reproducible build environments for agent artifacts (SLSA build levels)

Build phase

Implementation, testing and hardening while the agent is developed. 7 tasks.

Signing and Verification

• Sign model artifacts, prompt templates, agent cards and tool definitions; verify signatures at admission and on load (AISVS C3.1.2, C3.1.3)
• Scan models for malicious code before import and verify third-party artifact integrity (AISVS C6.1.1, C6.1.3)
• Sign the AIBOM and fail the build when component metadata is missing (AISVS C6.2.2, C6.2.3)

Change Control

• Require peer review for changes to prompts, agent configuration and tool manifests, the same as for code
• Pin framework, plugin and MCP server versions; update through a reviewed pipeline, never auto-update in production
• Block agents from installing tools or packages that are not on the approved registry (AISVS C9.3.7) and restrict self-modification of prompts and tool lists (AISVS C9.2.5)
• Run a behavioral acceptance suite before promoting any new model or tool version (AISVS C6.1.4)

Operations phase

Monitoring, response and continuous improvement once the agent is live. 5 tasks.

Continuous Assurance

• Monitor the AIBOM against vulnerability and compromise feeds; alert on newly reported indicators for any component
• Detect drift between deployed artifacts and their signed versions; quarantine on mismatch
• Keep rollback-ready signed versions of prompts, configs and tools for fast recovery
• Red-team with simulated supply-chain attacks (malicious tool package, poisoned template, rogue update)
• Re-validate tool definitions after every upstream update (AISVS C10.4.8)

Tools and frameworks

Supply-Chain Tooling

• Signing: Sigstore / cosign, OpenSSF model signing (sigstore/model-transparency), in-toto attestations
• Bills of materials: CycloneDX ML-BOM, SPDX 3.0 AI and Dataset profiles
• Build integrity: SLSA provenance, reproducible builds, isolated CI runners
• Scanning: model-file scanners for unsafe serialization, dependency and secret scanners, MCP server scanners
• Guidance: OWASP AISVS 1.01 chapters C6 and C3, MITRE ATLAS AML.T0010

Related controls

• M2 Tool Sandboxing & Isolation shares T11, T16
• M6 Comprehensive Security Monitoring & Auditing shares T16, T17
• M13 Secure Development Lifecycle Integration shares T11, T17
• M17 Supply Chain Security & Provenance shares T11, T17

References

• OWASP AISVS 1.01 C6: Supply Chain Security for Models
• SLSA Specification v1.0
• Sigstore model-transparency (model signing)
• CycloneDX Machine Learning BOM
• MITRE ATLAS AML.T0010: Supply Chain Compromise