Code and change control
Repository ownership, protected changes, reviewed commits and a traceable source revision.
Field guide / agentic component integrity
AI agent supply chain security: verify every component before it gains authority.
Agentic systems assemble models, MCP servers, tools, skills, plugins, prompts and dependencies into one decision path. Secure admission requires more than a package scan: identify what can influence the agent, verify where it came from, constrain what it can do and detect when the deployed composition changes.
Direct answer
Inventory influence, verify identity, then budget authority
AI agent supply chain security is the practice of identifying every component that can influence a decision or exercise a capability, binding it to an expected owner and immutable version, evaluating provenance and behavior, granting only the authority it needs, monitoring the live composition and preserving a tested removal and recovery path.
Eight links in the agentic supply chain
Artifacts and infrastructure
Builders, dependencies, lockfiles, containers, packages, attestations and distribution channels.
Weights and hosted endpoints
Provider, model identity, revision, routing, safety configuration and change notifications.
Prompts, policy and retrieval
System prompts, skills, memory templates, datasets, embeddings and content ingestion paths.
Servers, tools and registries
Server identity, live tools, schemas, annotations, credentials, destinations and side effects.
Skills, plugins and connectors
Install source, code execution, update behavior, file access, network access and secrets.
Agents and external services
Identity, authority transfer, nested calls, accountability and downstream data handling.
Composition and configuration
The exact versions, policies, feature flags and permissions assembled for a production decision.
Seven admission questions
Who owns this component?
Resolve the maintainer, source repository, registry or provider, distribution channel, support path and the party accountable for updates.
Which exact thing was reviewed?
Pin a commit, package version, digest, model revision, prompt revision or signed release. A mutable name such as latest is not review evidence.
How was it produced?
Inspect source and build provenance, dependencies and attestations where available. Record the unverified links instead of converting missing evidence into trust.
What authority will it receive?
Name credentials, files, private data, tools, network destinations, state changes and delegated permissions. Review the combination, not each capability in isolation.
What does it do at runtime?
Inspect live capabilities under the intended identity, test safe negative cases and compare observed side effects and egress with the declared contract.
How can it change?
Model automatic updates, mutable registries, tool-list changes, feature flags, provider routing and configuration drift. Define which changes require re-admission.
Can it be removed safely?
Prove disablement, credential revocation, dependency isolation, impact identification, rollback and restoration to a known-good composition.
Inventory, provenance and behavior prove different things
An inventory is not an integrity proof
SBOM and AIBOM records make components visible and improve incident response. Completeness, authenticity and runtime use still need separate evidence.
Origin is not fitness
SLSA 1.2 provenance can connect a software artifact to source and build process. It does not prove that the component is vulnerability-free or safe for a given authority.
A clean scan is not a runtime boundary
Static analysis and package scanning cannot prove a hosted model, MCP server, plugin or delegated agent behaves within the approved data and side-effect boundary.
Trusted code can still be overpowered
A correctly built component becomes dangerous when it receives unnecessary secrets, broad egress, silent update power or an irreversible action path.
MCP needs two supply-chain checks
First verify the server as software and infrastructure: ownership, install source, artifact identity, dependencies, update path and runtime destination. Then verify the capability surface it presents to the agent: live tools, descriptions, schemas, annotations, authorization, data handling, side effects and list changes.
MCP tool annotations are untrusted metadata
The MCP 2026-07-28 Tools specification requires clients to consider tool annotations untrusted unless they come from trusted servers. A trusted server identity still does not make every tool appropriate: compare the live list and schema with the approved snapshot, show side effects to the user and re-authorize high-impact actions at execution time.
Evidence to verify
- A component inventory that includes models, prompts, retrieval, MCP, skills, plugins, agents, APIs, packages, containers and runtime configuration.
- Owner, source, immutable revision or digest, distribution channel and update policy for every authority-bearing component.
- SBOM or AIBOM where useful, plus completeness and authenticity checks rather than an unsupported “covered” label.
- Source and build provenance or a recorded evidence gap; verification policy must fail closed on mismatched subject, builder or materials.
- An authority matrix for secrets, data classes, files, tools, destinations, side effects and delegated permissions.
- Runtime snapshots of models, MCP tool lists and schemas, skills, plugins, feature flags, policy and network destinations.
- Negative tests for unauthorized tools, expanded scopes, changed digests, unexpected egress and unapproved component updates.
- Revocation, isolation, rollback and recovery evidence tied to the same component identities used in admission.
Safe verification plan
Start in an isolated environment with synthetic identities, inert destinations and no production secrets. Freeze the expected component manifest and authority matrix before testing. Change one link at a time, observe whether admission fails closed, and use the smallest proof that distinguishes declared behavior from deployed behavior.
A decision-grade result names the component, exact revision, expected provenance, observed behavior, authority, evidence, limitation, remediation and retest. A missing attestation is an evidence gap; it is not proof of compromise. A valid attestation is evidence of origin; it is not a security guarantee.
Need a bounded supply-chain review?
Start with the five-minute readiness checklist → or map the authority and trust boundaries first →
Safety boundaries
- Defensive work only, on systems owned by the requester or explicitly authorized in writing.
- Active testing requires written Rules of Engagement with exact assets, techniques, data handling, timing, contacts and stop conditions.
- Use synthetic data and inert destinations by default; stop on unexpected sensitive or third-party access.
- No malicious package publication, registry impersonation, credential harvesting, destructive testing, persistence or third-party targeting.
- This guide is not a certification, a guarantee of component safety or permission to test infrastructure you do not own.
Primary sources and further reading
OWASP Top 10 for Agentic Applications 2026Agentic threat baseline ↗OWASP AIBOM GeneratorAI component inventory ↗SLSA 1.2 specificationSupply-chain integrity ↗SLSA 1.2 provenanceOrigin and build evidence ↗MCP 2026-07-28 Tools specificationTool trust and interaction ↗NIST SP 800-218 — Secure Software Development FrameworkPrimary source ↗MCP security checklistReview the tool boundary ↗AI agent security controls baselineSelect observable outcomes ↗
Direct answers
What belongs in an AI agent supply chain?
Include source and builds, software packages, container images, models, prompts and policies, retrieval corpora, MCP servers and tools, skills and plugins, delegated agents, registries, external APIs and the runtime configuration that composes them. If a component can influence a decision or receive authority, it belongs in scope.
Is an SBOM or AIBOM enough to secure an AI agent?
No. An SBOM or AIBOM improves inventory and incident response, but an inventory is not an integrity proof, a behavior test or an authorization decision. Teams still need provenance, admission policy, runtime observation, least privilege, revocation and evidence that the deployed component matches the reviewed one.
How should a team evaluate an MCP server before connecting it?
Verify ownership, distribution channel, immutable version, source and build evidence, requested credentials, network destinations, tool schemas, side effects, data handling and a removal path. Inspect the live tools list under the intended authorization because MCP tool descriptions and annotations are untrusted metadata unless they come from a trusted server.
Does SLSA prove an AI component is safe?
No. SLSA 1.2 provides a vocabulary and verifiable provenance for source and build integrity. It can increase confidence that an artifact came from the expected process, but it does not prove model behavior, prompt safety, data quality, vulnerability absence or fitness for a particular authority boundary.
What should happen when an agent dependency changes?
Fail closed for unexplained identity, digest, capability, permission or destination changes. Re-inventory the component, compare provenance and behavior, rerun the risk-based admission tests and require a new approval when the authority or data boundary expands.
Can Delx Security review an agentic supply chain?
A bounded review can verify an authorized system's component inventory, provenance, admission gates, authority, runtime composition, update path and revocation evidence. Active testing starts only after written Rules of Engagement define exact assets, techniques, data handling, timing, contacts and stop conditions.