Enterprise AI agents are getting better at picking tools, but the security model around those tools is still stuck in a world where trust stops at the download page. The uncomfortable part is that shared registries let agents choose by natural-language descriptions, and nobody is reliably checking whether those descriptions match reality.
The answer is runtime checks for enterprise AI agents, not just provenance. Supply-chain controls such as code signing, SBOMs, SLSA provenance, and Sigstore help prove where an artifact came from. They do almost nothing to prove that the tool behaves the way its description claims once an agent actually uses it.
Why provenance is only half the answer
This is where enterprise teams can talk themselves into a false sense of safety. A malicious tool can be signed, carry clean provenance, and still smuggle prompt-injection language in its description, nudging the agent toward the wrong choice. The model is reading metadata as if it were instruction, which is a neat trick if you happen to be the attacker.
Even worse, a tool can behave properly when it is published and drift later on the server side, quietly changing what it sends or receives. That makes runtime checks the missing layer, not a nice-to-have. HTTPS-era identity assurances were never enough by themselves, and tool registries are heading straight for the same mistake if the industry stops at provenance.
What a verification proxy should check
The practical fix is a proxy between the agent and the MCP server that validates every invocation. Think of it as a traffic cop with a manifest: it checks whether the called tool matches what the agent already approved, whether the server reaches only declared endpoints, and whether the output fits the promised schema. In other words, discovery binding, endpoint allowlisting, and output validation.
- Discovery binding blocks bait-and-switch tool swaps.
- Endpoint allowlisting stops undeclared outbound connections.
- Output schema validation catches odd fields, exfiltration hints, and prompt-injection residue.
The key ingredient is a behavioral specification: a machine-readable declaration of what the tool is allowed to contact, read, write, and change. That specification needs to travel with the signed attestation so the proxy can verify it at runtime. A lightweight setup adds only a small delay per call, while heavier data-flow analysis can be reserved for systems that actually deserve the extra friction.
How teams should roll it out
The sensible rollout order is boring, which is usually a good sign in security. Start with endpoint allowlists at deployment time, then add output checks, then apply discovery binding to the riskiest tools first. Credential-handling, PII processing, and financial tools deserve stricter controls before somebody decides that ”agent autonomy” is a synonym for ”good luck.”
The broader lesson is simple: provenance tells you where a tool came from, not whether it will behave. For teams already leaning on central registries, the bare minimum is clear endpoint enforcement today. The harder question is how fast vendors will expose the behavioral metadata needed for everything else, because that will decide whether runtime verification becomes standard plumbing or another optional security feature everybody says they plan to adopt later.