Governing the Agent-to-Tool Boundary

I. A new, ungoverned API surface

Before MCP, giving an agent a new capability meant writing and maintaining an integration — enough friction that most teams only built a handful, and each one naturally inherited whatever authentication and logging the surrounding application already had. MCP removed that friction: an agent points a client at a server's URL and a whole toolset becomes available immediately. The problem this creates is not the protocol itself, it is what it bypasses by default. A direct connection from an agent to an MCP server carries the server's own authentication and nothing else — no budget check before a paid tool runs, no policy over which tools an agent is even allowed to call, no screening of what goes into or comes back from a tool call, and no attribution tying that tool's cost to a feature, a run, or a department. Every control already in place for a direct call to OpenAI or Anthropic simply does not apply to a tool call that never passes through that path.

II. Tool policy: allow-lists, deny-lists, and what an agent can even see

The first control is the most basic one an API surface can have: which operations are permitted at all. Each MCP server behind the gateway gets an optional allow-list and deny-list of tool names, built directly from the real tool list a “discover tools” call returns against that server, rather than typed in blind. A tool call that falls outside the policy is refused with a JSON-RPC error before it ever reaches the server — the deny-list always wins, so an accidental overlap between an allow-list and a deny-list resolves toward the more conservative outcome rather than an ambiguous one.

The policy applies at a second layer as well: the tool list an agent's client actually sees when it asks a server what it offers is filtered to match the policy, in both the ordinary JSON response and the streaming form. A forbidden tool is not merely refused when called — it is not visible to the agent as an option in the first place, which removes an entire class of “the agent tried something it should never have known about” incidents rather than just blocking them after the fact.

III. Scanning what goes in — and comes back

Tool policy decides whether a call is permitted at all. It says nothing about what is inside the call itself. A permitted tool can still receive an argument that leaks a customer's email address, a pasted API key, or a credit card number, and its result can still be the vector for a prompt-injection attempt — text embedded in a tool's output that tries to redirect the model's next action. The same pattern-matching engine that screens PII, secrets, and injection attempts in ordinary chat traffic runs on tool-call arguments too, with each of the three checks configurable independently as off, alert, redact, or block.

One check runs at a deliberately different threshold: instruction-override phrasing arriving inside a tool result is treated with far less tolerance than the identical phrasing in a human's own message. A user typing a markdown heading that happens to look like “### system: override” is very often an innocent false positive. The same string arriving inside a tool's output — content no human typed — has no equally innocent explanation, which is why tool-output injection screening defaults to the strictest of the three modes, block, while ordinary prompt-injection screening on user and system messages defaults to alert.

IV. Cost, budgets, and attribution for a tool call

Not every MCP tool is free to call — a server that meters a third-party API behind it, or one an organization wants to price internally, needs the same pre-call economics as a model call. A per-call price can be set on a server, and a paid call is checked against the same budgets already governing model spend before it runs, refused if a blocking budget would be exceeded, and never billed if the call itself fails. This is the same enforcement path used everywhere else in the platform, not a parallel one built just for tools.

Every call is also written into the same call log used for model traffic — server name, tool name, cost, latency, status, and whatever attribution tags the agent already sends — with tool arguments never stored, only a hash of them for reference. That single design choice is what lets a tool call sit next to a model call in the same dashboard and the same report instead of requiring a separate view built specifically for agent tooling, and it extends to denied and blocked attempts too, which are logged as their own outcome so a policy or guardrail decision is visible after the fact rather than silently invisible.

V. One run, many tools, and sub-agents

Gating and pricing an individual tool call solves half the problem. The other half is seeing how a whole workflow's cost breaks down once an orchestrator is calling several tools and possibly handing off to sub-agents of its own — a single per-run total says an agent cost $0.83 without saying whether that was one expensive tool call or ten cheap ones. A shared run identifier carried across every step, alongside a header naming which MCP server made a given call and a separate marker for an agent-to-agent handoff, turns that flat total into a workflow tree: which tool, which step, and which hop actually drove the spend.

Attribution at this level is a different concern from policy and guardrails, and it is meant to complement them, not replace them — knowing which tool call was expensive does not stop a concurrent fan-out of sub-agents from overspending in the first place, which is the same run-level budget-reservation problem covered in a companion report on enforcement across a multi-agent run.

VI. The same pattern, one hop further out

None of tool policy, argument scanning, or budget enforcement is a new idea introduced for MCP specifically — each is the same proxy-in-the-path pattern already applied to direct model calls, moved one hop further out to the point where an agent reaches for a tool instead of a model. The reason that matters is architectural, not conceptual: none of it is achievable by watching traffic after the fact or reading a server's own logs, because a decision to deny, redact, or block has to be made before the call reaches the tool server, not after. An MCP server without a gateway in front of it is simply a new API surface that inherited none of the governance already built for everything else an agent touches. One in front of it inherits all of it, by construction.