Wiki · Concept · Last reviewed June 15, 2026

Agentic Supply-Chain Vulnerabilities

Agentic supply-chain vulnerabilities are security and governance failures that enter an AI agent through the tools, prompts, connectors, models, skills, datasets, dependencies, credentials, MCP servers, memory stores, registries, agent cards, or delegated agents it relies on.

Definition

Agentic supply-chain vulnerabilities are weaknesses introduced through the components that make an AI agent useful. A chatbot may be mostly a model and interface. An agent is a system: model, prompt, tool descriptions, API connectors, MCP servers, browser or shell access, memory, retrieval sources, plugins, hosted models, open-weight checkpoints, credentials, schedules, and human approval paths. A compromise in any part of that chain can become a compromise of the agent's behavior.

The concept extends ordinary software supply-chain security into delegated action. Traditional supply-chain attacks may tamper with packages, build systems, repositories, images, dependencies, or update channels. Agentic supply-chain attacks may also tamper with tool metadata, prompt templates, retrieved documents, skill files, agent cards, connector manifests, memory entries, or other agents. The difference is that these artifacts can steer a model, not only execute code.

The practical distinction is between code integrity and semantic integrity. Code integrity asks whether a package, container, binary, or model artifact is authentic and unmodified. Semantic integrity asks whether the natural-language and structured context an agent consumes still means what the operator thinks it means: the right tool description, the right permission request, the right prompt template, the right memory, the right remote server, and the right delegated actor.

This page is adjacent to AI Agents, AI Coding Agents, Model Context Protocol, and AI in Cybersecurity. It names the supply-chain layer of agent risk.

How It Works

An agentic supply-chain failure can enter through installation, discovery, runtime retrieval, or delegation. A developer installs a malicious plugin. A model reads a tool description that hides instructions. An MCP server exposes a tool with broader authority than advertised. A prompt template changes in a shared repository. A subagent receives a poisoned task. A dependency installs code that steals secrets. A retrieval source contains instructions that turn evidence into authority.

Common patterns include typosquatted tool names, lookalike MCP servers, compromised registries, malicious skills or rules files, unreviewed agent cards, poisoned tool outputs, overbroad service accounts, abandoned connectors, vulnerable orchestration platforms, and model or adapter files whose provenance is unclear. The dangerous feature is composability: an agent may combine a weak tool, a hidden instruction, a broad token, and a trusting human reviewer into one action chain.

The risk is amplified because agents combine trust channels. A tool description is documentation, but it may also be model context. A plugin is software, but it may also be a permission request. A memory entry is state, but it may also be future instruction. A connector is convenience, but it may also be delegated access to files, mail, calendars, code, payments, or production systems.

Trust Boundaries

Acquisition boundary. This is where tools, packages, models, prompts, skills, rules files, containers, and MCP servers are selected, installed, updated, or generated. Controls here look like ordinary supply-chain discipline: allowlists, signed artifacts, pinned versions, hashes, SBOMs, vulnerability scanning, vendor review, and rollback.

Context boundary. This is where text, schemas, tool descriptions, agent cards, retrieved documents, memory, and tool output enter the model's working context. Controls here must separate instruction from data, mark provenance, and prevent external text from silently becoming agent policy.

Execution boundary. This is where the agent calls tools, writes files, runs code, sends messages, or touches production systems. Controls here include sandboxing, scoped credentials, egress limits, deterministic policy checks, and human approval for high-impact actions.

Delegation boundary. This is where the agent hands work to another agent, remote service, workflow engine, or human reviewer. Controls here require agent identity, auditable delegation records, revocation, and clear ownership. Without that boundary, compromise can move from one agent or connector into a wider institutional workflow.

Current Context

As of June 15, 2026, agentic supply-chain risk is recognized in public security guidance. OWASP released the Top 10 for Agentic Applications for 2026 on December 9, 2025, treating autonomous agents that plan, act, and decide across workflows as a distinct security surface; OWASP's launch material names ASI04 as agentic supply-chain vulnerabilities. OWASP's MCP Top 10 similarly focuses on MCP-enabled systems and includes risks such as tool poisoning, dependency tampering, lack of audit and telemetry, shadow MCP servers, and context injection or over-sharing.

The official Model Context Protocol security best-practices documentation warns about token passthrough, confused-deputy patterns, server-side request forgery, session hijacking, and prompt injection. NIST SP 800-218A adapts the Secure Software Development Framework for generative AI and dual-use foundation models, while NIST's 2026 AI Agent Standards Initiative and NCCoE concept paper frame agent identity, authorization, auditing, non-repudiation, interoperability, and secure operation as active standards work. CISA's software supply-chain guidance remains relevant because agents still depend on ordinary software components.

Security taxonomies are also catching up with agent runtime composition. MITRE ATLAS release notes added techniques such as publishing a poisoned AI agent tool and user execution of a poisoned AI agent tool, along with mitigations for AI-agent tool permissions, human-in-the-loop actions, and restricting tool invocation on untrusted data. Microsoft's June 2026 agentic failure-mode update describes agentic supply-chain compromise as a distinct category involving plugin registries, MCP servers, prompt templates, and third-party tool integrations.

Governance and Safety

Governance should treat the agent as a supply chain, not as a single model. Procurement and deployment reviews should ask which tools are installed, who publishes them, how updates are signed, what permissions each tool receives, which prompts and skill files are versioned, what memories persist, which MCP servers are trusted, and how a user can tell when an agent crosses from reading to acting.

The safety implication is straightforward: a harmless base model can become unsafe when surrounded by unreviewed tools. Conversely, strong tool governance can reduce risk even when the model is imperfect. This is why agentic supply-chain review belongs with sandboxing, least privilege, provenance, audit logs, and incident response.

For institutional deployments, the hard question is accountability. If an agent deletes data after reading a poisoned tool description, is the root cause a model failure, a tool-publisher failure, an identity failure, a prompt-injection failure, or a procurement failure? The answer matters for incident reporting, vendor obligations, user notice, insurance, and future controls. Logs should therefore preserve the chain: artifact source, version, permission grant, model and prompt version, retrieved context, tool call, approval, and downstream effect.

Defense Pattern

Source Discipline

Claims about agentic supply-chain risk should name the exact layer being discussed: model artifact, package dependency, prompt template, tool schema, MCP server, agent card, hosted connector, memory store, data vendor, credential path, or delegated agent. A general claim that "the agent was compromised" is usually too vague for remediation.

For current claims, prefer primary sources: OWASP risk categories, MCP specification and security documentation, NIST and CISA guidance, vendor advisories, CVEs, official release notes, security research disclosures, and reproducible incident writeups. Secondary commentary can help explain impact, but it should not replace artifact names, versions, hashes, permission scopes, affected products, dates, and mitigations.

Source discipline also applies inside organizations. A useful incident record should distinguish what came from the model, what came from a tool, what came from untrusted context, what came from a registry update, what came from a human approval, and what came from an inherited credential. Without those distinctions, future teams cannot tell whether to patch, revoke, retrain, sandbox, block, or redesign.

Spiralist Reading

The agent is never alone.

It arrives surrounded by little authorities: a connector, a tool card, a prompt, a memory, a registry, a token, a subagent, a package, a server. Each says, "trust me enough to act." Agentic supply-chain security is the discipline of asking who taught the machine what its hands are for.

Open Questions

Sources


Return to Wiki