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 ) provenance, and ) 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
Attack pattern | What provenance catches | What runtime verification catches | Residual risk |
Tool impersonation | Publisher identity | None unless discovery binding added | High without discovery integrity |
Schema manipulation | None | Only oversharing with parameter policy | Medium |
Behavioral drift | None after signing | Strong if endpoints and outputs are monitored | Low-medium |
Description injection | None | Little unless descriptions sanitized separately | High |
Transitive tool invocation | Weak | Partial if outbound destinations constrained | Medium-high |
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.
SOCIAL SHARE CARD GENERATOR