Securing the Agent Supply Chain: Tools, Skills, MCP Servers, and Third-Party Risk

Installing a normal dependency gives code some level of access to your application.

Installing an agent dependency can give language to a system that already has access to your files, browser, cloud accounts, customer records, and shell.

That is a different security problem.

An MCP server can introduce tools and descriptions that influence what an agent chooses to do. A skill can add instructions, scripts, and resources. A model provider can change behavior behind a stable API name. A retrieval connector can inject untrusted content into context. A package update can alter the runtime that enforces every other control.

The agent supply chain is not just the code you deploy. It is the complete set of artifacts and services that can shape decisions or receive authority at runtime.

In 2026, teams need to manage those components as deliberately as production software dependencies, with an additional rule: anything that can instruct the agent belongs in the threat model too.

---

TL;DR

• Maintain an agent bill of materials covering code, models, prompts, skills, tools, servers, policies, data sources, and remote services.
• Pin immutable versions and verify provenance before promotion.
• Snapshot tool and prompt definitions at approval time; require review when they change.
• Treat registries and signatures as evidence of origin, not proof of safe behavior.
• Give each dependency the minimum runtime permissions, data, network access, and lifetime it needs.
• Separate discovery from enablement and enablement from authorization.
• Monitor runtime behavior and support rapid quarantine and credential revocation.
• Test supply-chain failures: compromised updates, mutable metadata, dependency confusion, poisoned content, and unavailable vendors.

---

Why the agent supply chain is larger

A traditional software bill of materials lists packages, libraries, and components. That remains necessary. CISA describes SBOMs as a mechanism for transparency across the software supply chain and for integrating component knowledge into asset and vulnerability management. (CISA SBOM Resources)

Agents add new behavior-bearing inputs:

• foundation and specialist models
• system and policy prompts
• agent skills and instruction bundles
• tool schemas and descriptions
• MCP and A2A servers
• orchestration templates
• guardrails and policy engines
• retrieval connectors and corpora
• evaluators and model graders
• browser extensions and desktop bridges
• generated code and downloaded artifacts
• hosted APIs whose behavior can change remotely

Some execute code. Some provide data. Some provide instructions. Some do all three.

A malicious library may run directly. A malicious document may persuade the model to run an already trusted tool. Different mechanism, same need for provenance, containment, and detection.

Build an agent bill of materials

Call it an ABOM, an agent manifest, or a release inventory. The name matters less than completeness.

For every production agent release, record:

agent: procurement-review
release: 2026.10.23
models:
  - provider: example
    model: reasoning-model
    immutable_snapshot: 2026-10-02
prompts:
  - id: procurement-system@31
skills:
  - name: contract-review
    version: 4.2.1
    digest: sha256:...
tools:
  - name: vendor_lookup
    server: procurement-mcp@2.8.0
    schema_digest: sha256:...
    scopes: [vendor:read]
packages:
  - lockfile_digest: sha256:...
data_sources:
  - id: approved-contract-library
    snapshot: 2026-10-22
policies:
  - id: procurement-policy@18

Also record:

• source repository and revision
• publisher identity
• build provenance and signature
• review status and owner
• requested permissions
• network destinations
• data classifications touched
• transitive dependencies
• expiration or review date
• known rollback version

Generate the manifest during the build, verify it at deployment, and attach its fingerprint to runtime traces.

Provenance tells you where; review tells you whether

Supply-chain provenance answers:

• where did this artifact come from?
• which source and build process produced it?
• was it modified after the build?

SLSA defines provenance as verifiable information tracing an artifact through its source, build process, and materials. Its framework increases confidence that the code being run is the code that was analyzed. (SLSA provenance)

That is vital, but provenance does not prove the artifact is benign.

A correctly signed tool can still request excessive access. An official server can contain a vulnerability. A trusted publisher can be compromised. A prompt can be faithfully packaged and dangerously designed.

Use provenance to establish identity and integrity. Use review, testing, and runtime policy to establish acceptable behavior.

Pin more than package versions

Teams pin npm or Python dependencies and then call model: latest, download skills from a moving branch, or discover tools dynamically on every startup.

That is not a reproducible release.

Pin:

• package versions and lockfiles
• container image digests
• model snapshots when the provider supports them
• prompt and policy versions
• skill bundle digests
• MCP server versions
• tool-schema snapshots
• retrieval corpus snapshots or index generations
• evaluation suite versions

When a remote service cannot be pinned, record its observed contract and treat behavior drift as an operational risk. Use canaries and stronger runtime controls around mutable dependencies.

Do not allow an agent to install or enable new dependencies in its own production runtime. Discovery may be autonomous; trust promotion should not be.

Tool metadata is executable influence

Tool names and descriptions are usually inserted into the model's context. They influence planning and argument generation. Changing metadata can change behavior even when the underlying executable is identical.

This creates a subtle supply-chain path:

1. A server is reviewed with a benign tool description.
2. The client trusts the server and refreshes its catalog later.
3. The server changes the description or adds a tool.
4. The agent receives new instructions inside an already trusted relationship.

OWASP's 2026 agentic-security reporting highlights mutable MCP metadata and third-party servers as supply-chain concerns, recommending snapshots and re-approval when definitions change. (OWASP agentic exploit roundup)

Treat these as controlled artifacts:

• tool name
• description
• argument and result schemas
• annotations about read/write behavior
• UI templates
• prompt templates
• declared resources

Hash the normalized definitions at approval time. On reconnect, compare the live catalog. Block, quarantine, or require re-approval for material changes.

Discovery is not authorization

Finding a server in a registry tells you that it exists. A package signature may tell you who published it. Neither means your finance agent should call it with payroll credentials.

Separate three decisions:

Discovery

The system knows a component is available.

Enablement

An administrator allows the component in a specific environment.

Authorization

A particular user or agent run may invoke a particular capability on a particular resource.

Do not collapse them into an "installed" boolean.

The current MCP specification has strengthened authorization, routing, and task isolation, but the server and host still need to enforce caller permissions on every request. (MCP 2026-07-28 specification)

An enabled tool should still receive user-bound, narrowly scoped, short-lived authority.

Review capabilities, not just code

Code review asks what the component does. Agent dependency review must also ask what the component can cause the rest of the system to do.

For a tool server or skill, inspect:

• executable code and install hooks
• instruction and prompt content
• tools added or modified
• files and environment variables accessed
• network destinations
• subprocess execution
• credential requirements
• persistence and update behavior
• telemetry and data retention
• whether content can influence unrelated tools
• how the component behaves when offline or compromised

A skill containing only Markdown can still redirect an agent toward sensitive files. A data connector returning untrusted web content can carry prompt injection. "No executable code" does not mean "no behavior risk."

Use capability-scoped runtime isolation

Assume review will miss something.

Contain each dependency at runtime:

• run local servers in a sandbox or restricted container
• mount only required directories
• make filesystems read-only by default
• block credential directories explicitly
• allowlist outbound network destinations
• use per-tool identities rather than shared environment secrets
• set CPU, memory, process, and time limits
• prevent arbitrary subprocess execution
• isolate tenants and users
• terminate credentials when the session ends

The Agent Sandboxes article covers execution isolation. The supply-chain extension is to tailor the sandbox to the dependency's declared capability, then detect when observed behavior exceeds that declaration.

Keep credentials out of the component

A third-party tool should not receive a vault full of long-lived secrets and decide which one to use.

Use a credential broker:

1. The agent requests a capability.
2. Policy evaluates the user, resource, action, and context.
3. The broker issues or injects a short-lived scoped credential.
4. The tool uses it for one bounded operation.
5. The runtime records the grant and revokes it on completion.

Bind grants to the intended audience so a token issued for one server cannot be replayed against another. The Agent Identity and Credential Brokers guide explains the broader pattern.

Never expose raw credentials in model context, tool descriptions, error messages, or general-purpose memory.

Treat retrieved content as an untrusted dependency

An agent's supply chain continues after deployment. Every webpage, email, issue, PDF, and document it retrieves may affect behavior.

Use a trust-aware context pipeline:

• label content origin and trust class
• keep external text separate from system instructions
• strip active content and unsafe attachments
• prevent retrieved instructions from granting permissions
• require tool authorization outside the model
• preserve source provenance
• detect suspicious instruction-like content
• restrict high-risk tools when processing untrusted sources

The agent should be allowed to summarize "ignore your previous instructions" as text without obeying it as control.

This is why context engineering and supply-chain security meet at runtime. Static scanning cannot know every document the agent will read.

Verify updates before they enter production

An update pipeline for agent dependencies should include:

1. fetch into quarantine
2. verify signature and provenance
3. compare permissions and network behavior
4. diff prompts, instructions, schemas, and tool metadata
5. scan code and dependencies
6. run contract and security tests
7. execute in a sandbox with synthetic credentials
8. compare behavior against the approved version
9. deploy to shadow or a limited canary
10. promote only after explicit gates pass

Automatic security updates are valuable for conventional libraries. Automatically promoting a tool server that also changed its requested scopes and instructions is not the same thing.

Separate acquisition from activation.

Monitor the dependency after approval

Runtime monitoring should compare declared and observed behavior.

Watch for:

• tool-catalog or schema changes
• new network destinations
• access to undeclared files
• unusual credential requests
• subprocess creation
• increased data volume
• tools called outside expected workflows
• instructions that reference secrets or concealment
• changed error and retry patterns
• server identity or certificate changes

Emit a dependency identity and version on every tool span. OpenTelemetry's GenAI conventions provide common attributes for model, operation, agent, and data-source telemetry; add your dependency and policy metadata consistently rather than burying it in log messages. (OpenTelemetry GenAI conventions)

Baseline per component. A calendar tool reading a calendar is normal. The same tool enumerating shell history is not.

Make quarantine fast

When a dependency is suspected, responders need one control that works across the fleet.

Support:

• disable by digest, version, publisher, or server identity
• revoke associated credentials
• block network destinations
• remove the tool from future contexts
• pause in-flight runs using it
• identify every affected agent and run
• preserve evidence for investigation
• fall back to a known-safe version

Do not rely on editing prompts to say "please do not use this tool." Remove the capability from the runtime.

An inventory is valuable only if it can answer blast-radius questions quickly:

• Which agents loaded this component?
• Which users invoked it?
• What data could it access?
• Which side effects occurred?
• Which versions remain active?

Test the supply-chain failure modes

Add adversarial scenarios to your release and incident drills:

• a signed dependency requests a new permission
• a server changes tool descriptions after approval
• a package name is replaced by a lookalike
• an update endpoint is compromised
• a retrieval source contains prompt injection
• a model alias changes behavior
• a tool returns poisoned instructions in its result
• a dependency exfiltrates through an allowed domain
• the vendor disappears during a long-running workflow
• emergency revocation occurs while actions are in flight

Verify that the system fails closed where consequence is high and degrades gracefully where availability matters more.

Procurement questions for agent dependencies

Before adopting a hosted model, tool, or server, ask:

• Are versions immutable and available during rollback?
• How are updates announced and deprecated?
• Is build or artifact provenance available?
• What data is retained, trained on, or shared?
• Can processing region and subprocessors be controlled?
• Which security events and audit logs are exposed?
• How quickly can credentials be revoked?
• Can tool definitions change without a version change?
• What happens when the service is unavailable?
• How are vulnerabilities disclosed?

"It supports MCP" is an interoperability statement, not a security review.

Metrics that matter

Track:

• percentage of dependencies with verified provenance
• percentage pinned by immutable digest
• stale-review and unsupported-version counts
• unapproved metadata-change attempts
• permission-expansion requests
• dependencies with unrestricted egress
• mean time to inventory and quarantine an affected component
• runtime policy violations by dependency
• runs using mutable or unknown versions
• rollback and safe-fallback success rate

The objective is not zero third-party dependencies. It is bounded, observable trust.

Implementation checklist

• Generate an agent bill of materials.
• Pin models, prompts, skills, schemas, packages, and policies.
• Verify signatures and provenance.
• Snapshot and diff behavior-bearing metadata.
• Separate discovery, enablement, and authorization.
• Review instructions and capabilities, not only executable code.
• Sandbox components with narrow filesystem and network access.
• Broker short-lived credentials per action.
• Label retrieved content as untrusted input.
• Gate updates through testing and canaries.
• Monitor declared versus observed behavior.
• Build one-step fleet quarantine and revocation.
• Drill compromised and unavailable dependency scenarios.

The bottom line

Agents turn dependencies into participants.

A tool server does not merely answer API calls; its descriptions can shape plans. A skill does not merely package files; its instructions can redirect authority. A document does not merely provide facts; its contents can compete with policy inside the context window.

That makes supply-chain security a runtime discipline, not a procurement checkbox.

Know every component. Verify where it came from. Limit what it can reach. Detect when it changes. And make removal faster than compromise can spread.

---

Further reading

• CISA: SBOM Resources
• SLSA v1.2 Provenance
• MCP 2026-07-28 Specification Release
• OWASP GenAI Security Project
• OpenTelemetry GenAI Semantic Conventions