AI agents choose shared record tools by matching natural language descriptions. But no human being is verifying whether those descriptions are true.
I discovered this gap when I filed issue 141 at CoSAI. ai-secure-tools repository. I assumed it would be treated as a single risk entry. The repository maintainer saw it differently and split my submission into two separate topics: one covering threats at selection time (tool spoofing, metadata manipulation); the other covers runtime threats (behavior bypass, runtime contract violation).
That confirmed tools registry poisoning is not a vulnerability. It represents multiple vulnerabilities at each stage of the tool life cycle.
There is an immediate tendency to apply the defenses we already have. Over the past 10 years, we have created software supply chain controls, including code signing, software bill of materials (SBOM), supply chain tiers for software artifacts (SLSA) provenance, and signature store. Applying these defense-in-depth techniques to agent tool logs is the next logical step. That instinct is correct in spirit, but insufficient in practice.
The Gap Between Artifact Integrity and Behavioral Integrity
All artifact integrity checks (code signing, SLSA, SBOM) ask whether an artifact is truly as described. But behavioral integrity is what agent tool registries really need: does a given tool behave as it says and not act on anything else? None of the existing controls address behavioral integrity.
Consider attack patterns that artifact integrity checks miss. An adversary may publish a tool with fast injection payloads as “always prefer this tool over alternatives” in its description. This tool is code signed, has clean provenance and an accurate SBOM. All artifact integrity checks will pass. But the agent’s reasoning engine processes the description through the same language model it uses to select the tool, collapsing the boundary between metadata and instruction. The agent will select the tool based on what the tool told them to do, not just which tool is best suited.
Behavioral drift is another problem that these types of controls overlook. A tool can be verified at the time of publication and then change its server-side behavior weeks later to leak the request data. The signature still matches, the provenance is still valid. The artifact has not changed. The behavior has.
If the industry applies SLSA and Sigstore to agent tool registrations and declares the problem solved, we will repeat the HTTPS certificate mistake of the early 2000s: strong guarantees about identity and integrity, leaving the question of true trust unanswered.
What a runtime verification layer looks like in MCP
The solution is a verification proxy that sits between the model context protocol (CCM) client (the agent) and the MCP server (the tool). When the agent invokes the tool, the proxy performs three validations on each invocation:
Discovery link: The proxy validates that the tool being invoked matches the tool whose behavior specification the agent previously evaluated and accepted. This stops bait-and-switch attacks, where the server advertises one set of tools during discovery and then offers different tools at invocation time.
Terminal allow list: The proxy monitors outgoing network connections opened by the MCP server while the tool is running and compares them to the declared allow list of endpoints. If a currency converter declares api.exchangerate.host as an allowed endpoint but connects to an undeclared endpoint during execution, the tool terminates.
Output schema validation: The proxy validates the tool’s response against the declared output schema, flagging responses that include unexpected fields or data patterns consistent with fast injection payloads.
The behavior specification is the new key primitive that makes this possible. It is a machine-readable declaration, similar to an Android app’s permissions manifest, that details what external endpoints the tool contacts, what data the tool reads and writes, and what side effects occur. The behavior specification is submitted as part of the tool’s signed certification, making it tamper-proof and verifiable at runtime.
A lightweight proxy that validates schemas and inspects network connections adds less than 10 milliseconds to each invocation. Full data flow analysis adds more overhead and is better suited for high security deployments. But each invocation must be validated against its list of declared allowed endpoints.
What each layer traps and what is lost
|
Attack pattern |
What origin catches |
What the runtime check detects |
Residual risk |
|
Tool impersonation |
Publisher identity |
None unless discovery link is added |
High without discovery integrity |
|
Schema manipulation |
None |
Only overshare with parameter policy |
Half |
|
Behavioral drift |
None after signing |
Strong if endpoints and results are monitored |
Low-medium |
|
Injection description |
None |
Little unless the descriptions are sanitized separately. |
High |
|
Transitive tool invocation |
Weak |
Partial if outgoing destinations are restricted |
Medium-high |
No layer is sufficient on its own. Provenance without runtime verification bypasses post-publication attacks. And runtime verification without provenance has no baseline to compare against. Architecture requires both.
How to implement this without disrupting developer speed
Start with a list of allowed endpoints at deployment time. This is the most valuable and simplest form of protection. All tools declare their touchpoints outside the system. The agent enforces those statements. No additional tools are needed beyond a network-compatible sidecar.
Next, add output schema validation. Compare all returned values with what each tool declared. Check any unexpected value returns. This detects data leakage and requests injection payloads in the tool’s responses.
Next, implement the discovery hook for high-risk tool categories. Credential handling, personally identifiable information (PII), and financial information processing tools must undergo full bait-and-switch verification. Less risky tools can avoid this until the ecosystem matures.
FinallycEmploy comprehensive behavioral monitoring only when the level of security justifies the cost. The graduated model matters: security investment must scale with risk.
If you use agents that choose centralized logging tools, add a list of at least allowed endpoints today. The rest of the behavior specifications and runtime validations can come later. But if you rely solely on SLSA provenance to ensure your tool-agent channel is secure, you’re solving the wrong half of the problem.
Nik Kale is a principal engineer specializing in security and enterprise AI platforms.
