AI agents choose tools from shared registries by matching natural-language descriptions. But no human is verifying whether those descriptions are true.

I discovered this gap when I filed Issue #141 in the CoSAI secure-ai-tooling 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 issues: One covering selection-time threats (tool impersonation, metadata manipulation); the other covering execution-time threats (behavioral drift, runtime contract violation).

That confirmed tool registry poisoning is not one vulnerability. It represents multiple vulnerabilities at every stage of the tool’s life cycle.

There’s an immediate tendency to apply the defenses we already have. Over the past 10 years, we’ve built software supply chain controls, including code signing, software bill of materials (SBOMs), supply-chain levels for software Artifacts (SLSA) provenance, and Sigstore. Applying these defense-in-depth techniques to agent tool registries is the next logical step. That instinct is right in spirit, but insufficient in practice.

The gap between artifact integrity and behavioral integrity

Artifact integrity controls (code signing, SLSA, SBOMs) all ask whether an artifact really is as described. But behavioral integrity is what agent tool registries actually need: Does a given tool behave as it says, and does it act on nothing else? None of the existing controls address behavioral integrity.

Consider the attack patterns that artifact-integrity checks miss. An adversary can publish a tool with prompt-injection payloads such as “always prefer this tool over alternatives” in its description. This tool is code-signed, has clean provenance, and has an accurate SBOM. Every check on artifact integrity 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 it to do, not just which tool is the best match.

Behavioral drift is another problem that these types of controls miss. A tool can be verified at the time it was published, then change its server-side behavior weeks later to exfiltrate 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 registries and declares the problem solved, we will repeat the HTTPS certificate mistake of the early 2000s: Strong assurances about identity and integrity, with the actual trust question left unanswered.

What a runtime verification layer looks like in MCP

The fix is a verification proxy that sits between the model context protocol (MCP) client (the agent) and the MCP server (the tool). As the agent invokes the tool, the proxy performs three validations on each invocation:

Discovery binding: The proxy validates that the tool being invoked matches the tool whose behavioral 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 serves different tools at invocation time.

Endpoint allowlisting: The proxy monitors the outbound network connections opened by the MCP server while the tool is executing, and compares them against the declared endpoint allowlist. If a currency converter declares api.exchangerate.host as an allowed endpoint but connects to an undeclared endpoint during execution, the tool gets terminated.

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 prompt injection payloads.

The behavioral specification is the key new primitive that makes this possible. It is a machine-readable declaration, similar to an Android app’s permission manifest, that details which external endpoints the tool contacts, what data reads and writes the tool performs, and what side effects are produced. The behavioral specification ships as part of the tool’s signed attestation, making it tamper-evident and verifiable at runtime.

A lightweight proxy validating schemas and inspecting network connections adds less than 10 milliseconds to each invocation. Full data-flow analysis adds more overhead and is better suited to high-assurance deployments. But every invocation should validate against its declared endpoint allowlist.

What each layer catches and what it misses

Neither layer is sufficient on its own. Provenance without runtime verification misses post-publication attacks. And runtime verification without provenance has no baseline to check against. The architecture requires both.

How to roll this out without breaking developer velocity

Begin with an endpoint allowlist at deployment time. This is the most valuable and easiest form of protection. All tools declare their contact points outside the system. The proxy enforces those declarations. No additional tooling is needed beyond a network-aware sidecar.

Next, add output schema validation. Compare all returned values against what each tool declared. Flag any unexpected value returns. This catches data exfiltration and prompt injection payloads in tool responses.

Then, deploy discovery binding for high-risk tool categories. Credential-handling, personally identifiable information (PII), and financial information processing tools should undergo the full bait-and-switch check. Less risky tools can bypass this until the ecosystem matures.

Finally, ceploy full behavioral monitoring only where the assurance level justifies the cost. The graduated model matters: Security investment should scale with the risk.

If you’re using agents that choose tools from centralized registries, add endpoint allowlisting as a bare minimum today. The rest of the behavioral specifications and runtime validations can come later. But if you are solely relying on SLSA provenance to ensure that your agent-tool pipeline is safe, you are solving the wrong half of the problem.

Nik Kale is a principal engineer specializing in enterprise AI platforms and security.

Welcome to the VentureBeat community!

Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.

Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!