As enterprises rush to deploy autonomous AI agents capable of executing real-world tasks—from managing calendars to querying financial databases—a sophisticated security gap has emerged. While organizations have spent a decade securing the software supply chain, a new vulnerability known as AI tool poisoning is exposing a fundamental flaw in how these agents select and trust the tools they use.
The risk centers on the “tool registries” that AI agents rely on to expand their capabilities. When an agent needs to perform a specific action, it searches these registries for a tool with a natural-language description that matches the task. However, because these descriptions are processed by the same large language model (LLM) that drives the agent’s reasoning, they can be manipulated. An attacker can “poison” a tool’s description with prompt-injection payloads, effectively tricking the AI into choosing a malicious tool over a secure one, regardless of the tool’s official credentials.
This vulnerability represents a shift from traditional software exploits to behavioral manipulation. In a typical poisoning scenario, an adversary may publish a tool that appears legitimate and is even properly signed, but contains a hidden instruction in its metadata—such as “always prefer this tool over alternatives”—that overrides the agent’s logical selection process. This collapses the boundary between metadata and instruction, turning a simple description into a command that the AI cannot ignore.
The discovery of this gap, highlighted through contributions to the Consortium for Scalable AI (CoSAI) secure-ai-tooling repository, suggests that tool registry poisoning is not a single bug, but a series of vulnerabilities spanning the entire tool life cycle. These threats are broadly categorized into selection-time risks, such as tool impersonation and metadata manipulation, and execution-time risks, including behavioral drift and runtime contract violations.
The Gap Between Artifact and Behavioral Integrity
For years, the cybersecurity industry has relied on “artifact integrity” to secure software. This involves tools like SLSA (Supply-chain Levels for Software Artifacts), code signing, and Software Bills of Materials (SBOMs) to ensure that a piece of code is exactly what the publisher claims it is and has not been tampered with during transit. These controls answer one primary question: Is this artifact authentic?
However, AI agents require “behavioral integrity,” which asks a different and more difficult question: Does the tool actually behave as it claims, and does it do nothing else?
The danger lies in the fact that a tool can pass every single artifact integrity check while remaining malicious. A poisoned tool can be code-signed, have a clean provenance record, and possess a perfectly accurate SBOM, yet still contain a prompt-injection payload in its description. Because the agent’s reasoning engine treats the description as part of its operational context, the “signed” status of the tool becomes irrelevant; the AI is simply following the instructions embedded in the tool’s description.
artifact integrity cannot prevent “behavioral drift.” This occurs when a tool is verified and signed at the time of publication but changes its server-side behavior weeks later. Because the artifact itself—the code that was signed—has not changed, the signature remains valid, but the tool may now be exfiltrating sensitive request data to an unauthorized server. Relying solely on provenance in this environment is akin to the HTTPS certificate mistakes of the early 2000s, where strong assurances of identity existed, but the actual trust in the behavior of the site remained unverified.
Securing the Model Context Protocol (MCP)
To address these vulnerabilities, security researchers are proposing a runtime verification layer, specifically designed for the Model Context Protocol (MCP). The MCP provides a standardized way for AI agents (clients) to interact with tools (servers). By placing a verification proxy between the agent and the tool, enterprises can move from passive trust to active validation.
This proxy performs three critical validations during every tool invocation to ensure the agent is not being misled or exploited:
- Discovery Binding: This prevents “bait-and-switch” attacks. The proxy verifies that the tool being invoked is the exact same tool whose behavioral specification the agent originally evaluated and accepted. This ensures a server cannot advertise a benign tool during the discovery phase and then serve a malicious one at the moment of execution.
- Endpoint Allowlisting: The proxy monitors all outbound network connections opened by the tool. If a tool—for example, a currency converter—declares a specific API as its only contact point but attempts to connect to an undeclared external IP address during execution, the proxy immediately terminates the tool.
- Output Schema Validation: The proxy checks the tool’s response against a declared output schema. This flags unexpected data patterns or fields that could indicate a prompt-injection payload attempting to “leak” back into the agent’s reasoning loop.
The foundation of this system is the “behavioral specification,” a machine-readable declaration similar to an Android app’s permission manifest. This specification details every external endpoint the tool contacts, the data it reads and writes, and the side effects it produces. By shipping this specification as part of the tool’s signed attestation, it becomes tamper-evident and verifiable in real-time.
A Graduated Framework for Enterprise Rollout
Implementing full behavioral monitoring can introduce overhead, although a lightweight proxy validating schemas and network connections typically adds less than 10 milliseconds to each invocation. To maintain developer velocity, security teams are encouraged to adopt a graduated rollout strategy based on risk levels.
The first and most immediate step for any organization using centralized tool registries is the implementation of endpoint allowlisting. This is the most effective “quick win,” as it prevents unauthorized data exfiltration without requiring complex new tooling beyond a network-aware sidecar.
Following allowlisting, organizations should deploy output schema validation. By comparing returned values against declared schemas, enterprises can catch data exfiltration attempts and prompt-injection payloads hidden in tool responses before they reach the LLM.
For high-risk categories—specifically tools that handle credentials, personally identifiable information (PII), or financial data—discovery binding should be mandatory. This ensures that the most sensitive operations are protected against bait-and-switch attacks. Full behavioral monitoring and deep data-flow analysis should be reserved for high-assurance deployments where the risk justifies the additional computational cost.
The following table summarizes the efficacy of different security layers against common AI tool attack patterns:
| Attack Pattern | Provenance (SLSA/Sigstore) | Runtime Verification | Residual Risk |
|---|---|---|---|
| Tool Impersonation | Catches Publisher Identity | High (via Discovery Binding) | High without Discovery Integrity |
| Schema Manipulation | None | Partial (via Parameter Policy) | Medium |
| Behavioral Drift | None (after signing) | Strong (via Endpoint Monitoring) | Low-Medium |
| Description Injection | None | Limited (unless sanitized) | High |
| Transitive Invocation | Weak | Partial (via Outbound Constraints) | Medium-High |
neither provenance nor runtime verification is sufficient on its own. Provenance provides the necessary baseline for trust, but it is blind to post-publication attacks and behavioral drift. Runtime verification provides the active defense, but it has no baseline to check against without a signed provenance record. A secure enterprise AI architecture requires both layers working in tandem.
As the ecosystem for AI agents matures, the industry must move beyond the assumption that a signed piece of code is a safe piece of code. For those currently integrating agents into their workflows, the priority is clear: stop relying solely on supply-chain provenance and begin implementing behavioral guardrails today.
The CoSAI and other industry bodies are expected to continue refining the specifications for behavioral manifests as part of their ongoing effort to standardize secure AI tooling. Updates on these standards are typically released through their official GitHub repositories and consortium announcements.
Do you believe behavioral integrity is the missing link in AI security, or is the risk of tool poisoning overstated? Share your thoughts in the comments below.