AI supply chain security is the practice of discovering and governing every AI component your organization pulls in or connects to, from training data and model artifacts to packages, extensions, skills, and Model Context Protocol (MCP) servers. For enterprises, the main risk is that a compromise at the build layer or the runtime tool-execution layer quietly steers downstream agent behavior. Security teams need one discovery and control model across both layers.

Last updated: July 2026.

AI supply chain risk has two enforcement moments you cannot separate: what developers introduce before deployment and what agents do at runtime. A single compromise at either moment can undermine everything downstream, so both need one inventory and one enforcement model. Treat build-time scanning and runtime governance as separate disciplines and you leave the seam between them open. That seam is exactly where AI-native attacks land.

Mapping the AI supply chain: layers, entry points, and signals

The AI supply chain means the full set of external and internal components an AI system depends on to function: training data, model weights, open-source packages, browser and Integrated Development Environment (IDE) extensions, agent skills, and the MCP servers that connect agents to tools and data. Each is an entry point, and each can be tampered with before or during use.

The affected assets span the whole development and deployment stack: source code repositories, build systems, CI/CD pipelines, model registries, developer extensions, data stores, secrets vaults, SaaS tools, and the runtime connectors agents use to call external services. A compromise in any of these does not stay contained. Poisoned data propagates into model behavior. A malicious package executes during build. A tampered MCP server injects instructions that redirect an agent while it works.

The layers that matter for AI supply chain security break down as follows:

1. Data layer: training and fine-tuning datasets, whose provenance and integrity shape model behavior before a single user prompt is written.
2. Model layer: weights and serialized artifacts pulled from public registries, which can carry embedded code or tampered parameters.
3. Package and dependency layer: open-source libraries, extensions, and skills the application imports, including those installed into developer tools and AI coding assistants.
4. Tool-execution layer: MCP servers and other connectors that let agents retrieve data and take actions against real systems.
5. Runtime interaction layer: the live prompts, responses, and tool calls where a permitted connection can still carry an impermissible action.

Compromises rarely announce themselves. The signals that surface first are behavioral: an agent invoking tools it was not assigned to a task for, unexpected data volumes leaving through a connector, model outputs that shift in instruction-following with no code change, or a developer extension calling an unrecognized endpoint. Secrets appearing in AI-generated code completions are a specific, high-value signal that a poisoned or over-permissioned component holds access it should not. A permission log may show that an agent had access. It will not show which tool it invoked, what data moved, what instruction changed the action, or which policy decision occurred. Third-party compromise is a major software supply chain risk, and AI systems add more external dependencies, runtime connectors, and autonomous actors to govern.

Training data, model artifacts, and AI-BOM generation

Some model artifacts behave like executable dependencies. Formats that run code on load need the same verification discipline as packages: source approval, hashing, signing, and quarantine on mismatch. A downloaded model becomes a delivery mechanism when it loads without integrity checks, which is why public registries scale this risk. One tampered artifact can reach many downstream teams.

Training data integrity is the quieter threat. Poisoned or mislabeled data does not announce itself at load time; it changes how the model responds later, sometimes only under specific triggers. The practical controls at this layer are dataset source approval before ingestion, lineage records that trace every data transformation step, periodic data-poisoning review against expected behavioral baselines, and retraining trigger checks when a dependency source changes or gets flagged.

Cryptographic signing and integrity verification of model artifacts close the tamper gap at deployment. A practical model-artifact verification workflow runs in four steps: (1) compute a cryptographic hash of the artifact at training time and store it in the AI Bill of Materials (AI-BOM); (2) re-verify the hash before loading into any environment; (3) reject any artifact whose hash does not match the AI-BOM record; (4) alert and quarantine on mismatch instead of silently loading a fallback. An AI-BOM should record the datasets used, model version and lineage, package dependencies and their versions, signing keys, and the environment that produced the artifact. During incident triage, the AI-BOM is the first document a team checks to tell whether a behavioral change came from a supply-chain substitution or a runtime manipulation.

These controls belong in the pipeline. In practice, that means scanning package manifests and lock files in every pull request for known-malicious dependencies, verifying model artifact hashes against the AI-BOM during the CI/CD build step before any environment promotion, running a static analysis pass on model-configuration files and serialized weights before they reach staging, and blocking a pull request merge when a dependency fails signature verification or lands on a threat feed. OWASP ranks Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), and Excessive Agency (LLM06) among the top risks for large language model applications, and the supply chain can introduce all three before the model ever reaches production (OWASP, 2025). The NIST AI Risk Management Framework (AI RMF) maps these supply chain risks to organizational governance obligations (NIST, 2023).

MCP servers, tool poisoning, and memory poisoning at runtime

MCP is one common tool-execution pattern, not the whole agent access-control problem, but it is a high-value entry point because a single connector can grant an agent broad reach into real systems. Researchers have cataloged more than 12,520 internet-accessible MCP services, most of them unauthenticated, and the protocol does not require authentication by default (Censys, 2026).

Tool poisoning is the AI-native version of a malicious dependency. A tampered MCP server hides instructions in a tool description, so the agent reads attacker-controlled text as trusted context and acts on it. This is indirect prompt injection delivered through the supply chain: the payload rides in a document, a search result, or a tool response rather than a direct user prompt. Memory poisoning is the persistence variant. Training data poisoning corrupts the model before deployment; memory poisoning persists attacker-controlled facts or preferences into an agent memory store after deployment, so a single injection keeps steering later sessions until the memory is cleared. For a closer look at how injection travels through different channels, see direct versus indirect prompt injection and prompt injection in AI coding assistants.

Aurascape governs this path at runtime. It discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that cryptographically signs approved tool calls and blocks unsigned ones, governing the agent-to-tool execution path inline rather than observing it (Aurascape, 2026). In governed workflows, an unsigned tool call gets blocked before it executes. That is the difference between flagging a risk during a build and stopping the action at the moment it is attempted.

Over-privileged agents and shadow AI widen the scope of action

Least privilege for AI agents means granting an agent only the tools, data, and actions a specific task requires, then enforcing that scope at the point of execution rather than assuming it from configuration. Excessive Agency, OWASP’s LLM06, is what happens when an agent holds more permission than its job needs. A compromised or manipulated agent then commands a wider scope of downstream action: one injected instruction can modify a SaaS record, invoke a paid external API, or push secrets and source code into a public repository through a tool call.

Cloud Security Alliance research found that 82% of organizations have unknown AI agents, 65% had agent-related incidents, and 61% reported data exposure (Cloud Security Alliance, 2026). You cannot scope permissions for agents you do not know exist. Repository scanning cannot inventory personal AI accounts, unmanaged browser extensions, local agents, or MCP servers that never enter the pipeline, so discovery has to reach beyond the build system. Aurascape addresses shadow AI with proactive local discovery of AI apps, accounts, and agents across the network, endpoint, and Application Programming Interface (API) planes, including the long tail no repository scan surfaces (Aurascape, 2026). Discovery also runs proactively: dedicated discovery agents continuously crawl the web and interrogate new tools before first employee use.

Aurascape separates observing agent activity from controlling the downstream action. Discovery surfaces the agents and their interactions; the Zero-Bypass MCP Gateway enforces which approved calls actually run. Context-aware policy actions apply at the interaction boundary and cover the full set: allow, coach, warn, block, and redact. When an agent tries to move sensitive data through a tool call, redaction and blocking happen inline, not in a report the next day. Gartner projects that at least 80% of unauthorized AI transactions will be caused by internal policy violations rather than malicious attacks (Gartner, 2025), which shows shadow AI is as much a governance gap as a threat one.

Build-time controls versus runtime governance: side-by-side comparison

Most AI supply chain guidance stops at pre-deployment scanning. The table below sets build-time controls next to runtime governance to show where each acts and why both are needed. It is a side-by-side comparison of coverage, not a claim that scanning is optional.

The 600+ real-time data classifiers are documented on the Aurascape platform page (Aurascape, 2026). Interaction records are governed by role-based access control (RBAC) for privacy and support both audit and effectiveness tracking. The risk-to-control table below maps the highest-frequency AI supply chain attack patterns to their entry points, signals, and primary controls.

Compliance posture and audit evidence for AI assets

Auditors increasingly ask not just what an agent was permitted to do, but what it actually did. Provenance records and scan logs answer the first question. They do not answer the second. That gap is where AI supply chain security meets compliance: a signed model with a clean AI-BOM can still take an action no one intended if an attacker manipulates it at runtime.

Governance expectations are moving in this direction. The World Economic Forum reports that organizations assessing AI-tool security before deployment nearly doubled, from 37% to 64%, in a single year (World Economic Forum, 2026). Pre-deployment assessment is a start; it does not cover the running system. Aurascape produces interaction records for audit and effectiveness at the runtime layer: who used AI, which account or tenant, what data was involved, which tool was invoked, and what policy decision occurred, governed by RBAC for privacy. That is the record a compliance team hands an auditor when the question shifts from permissions to actual actions.

For more on the prompt injection attack patterns referenced throughout this article, see what is prompt injection, prompt injection examples, and the prompt injection taxonomy.

Frequently asked questions

What is AI supply chain security?

AI supply chain security governs every AI component an organization depends on, from training data and model artifacts to packages, extensions, skills, and MCP servers, across both the build layer and the runtime agent-to-tool execution path.

How is AI supply chain risk different from traditional software supply chain risk?

Traditional risk centers on the packages and dependencies you build with. AI supply chain risk adds dataset provenance, serialized model artifacts that can execute code on load, and autonomous agents that take actions through runtime connectors including MCP servers. Repository scanning does not reach that runtime tool path.

What are the observable signals of an AI supply chain compromise?

Key signals include agents invoking tools outside their assigned task, unexpected data volumes leaving through a connector, secrets appearing in AI-generated code completions, and model outputs that shift in instruction-following with no code change.

Why are MCP servers a supply chain concern?

MCP servers connect agents to tools and data, so a tampered server can inject malicious instructions the agent treats as trusted context. More than 12,520 internet-accessible MCP services are exposed, most unauthenticated (Censys, 2026). Other connectors and runtime tool paths carry the same class of risk, so MCP controls should sit inside a broader agent execution model.

What is memory poisoning?

Memory poisoning persists attacker-controlled facts or preferences into an agent memory store after deployment. Training data poisoning corrupts the model before release; memory poisoning keeps steering later sessions until the memory is cleared.

What should an AI Bill of Materials include?

An AI Bill of Materials should record the datasets used and their lineage, model version and weights hash, all package dependencies and their pinned versions, signing keys, and the build environment. It is the first artifact to check during incident triage.

Does build-time scanning cover runtime agent behavior?

No. Scanning catches known-bad artifacts before deployment, but it does not see the live tool calls a running agent makes. A signed, scanned model can still be manipulated at runtime into an action no one intended. Runtime governance of already-authenticated agents closes that gap.

How does Aurascape secure the AI supply chain at runtime?

Aurascape discovers AI apps, accounts, and agents across the network, endpoint, and API planes, including shadow AI. It governs the agent-to-tool execution path inline with a Zero-Bypass MCP Gateway that signs approved tool calls and blocks unsigned ones in governed workflows. Real-time data classification applies allow, coach, warn, block, and redact at the action boundary, and interaction records capture what each agent actually did.

Aurascape unifies AI supply chain risk across build-time artifacts and runtime agent actions. Security teams discover unmanaged AI use, govern approved tool calls inline, and produce interaction records that show what agents did when they acted.

See how Aurascape governs your AI supply chain →