AI tool poisoning is a critical issue that highlights a significant flaw in enterprise agent security. It occurs when AI agents select tools from shared registries based on natural-language descriptions, without any human verification of the accuracy of these descriptions. This oversight was brought to light by the author's submission to the CoSAI secure-ai-tooling repository, which was split into two separate issues by the maintainer. The author argues that tool registry poisoning represents multiple vulnerabilities at every stage of a tool's lifecycle, not just a single risk entry.
The author emphasizes the distinction between artifact integrity and behavioral integrity. While artifact integrity controls (such as code signing, SLSA, and SBOMs) focus on whether an artifact is as described, behavioral integrity is crucial for agent tool registries. Behavioral integrity ensures that a tool behaves as stated and acts on nothing else. The author highlights attack patterns that artifact-integrity checks miss, such as prompt-injection payloads and behavioral drift, which can lead to data exfiltration and other malicious activities.
The author warns against the industry's tendency to apply existing defenses to agent tool registries, similar to the HTTPS certificate mistake of the early 2000s. They propose a runtime verification layer, implemented as a verification proxy, to address this issue. This proxy sits between the model context protocol (MCP) client (the agent) and the MCP server (the tool), performing three validations: discovery binding, endpoint allowlisting, and output schema validation.
The behavioral specification is a key component of this solution, detailing the tool's external endpoints, data reads and writes, and side effects. It is included in the tool's signed attestation, making it tamper-evident and verifiable at runtime. The author argues that a lightweight proxy validating schemas and inspecting network connections adds minimal overhead, while full data-flow analysis is better suited for high-assurance deployments.
The author provides a table comparing the attack patterns, what provenance catches, what runtime verification catches, and the residual risk. They emphasize that neither layer is sufficient on its own and that both provenance and runtime verification are necessary for a comprehensive security architecture.
To roll out this solution without breaking developer velocity, the author suggests starting with endpoint allowlisting at deployment time, followed by output schema validation and discovery binding for high-risk tool categories. Behavioral monitoring should be deployed only where the assurance level justifies the cost. The author concludes by emphasizing the importance of endpoint allowlisting as a bare minimum and warns against solely relying on SLSA provenance for agent-tool pipeline security.
