Agent and MCP Tool Governance.

Every tool an agent can reach is named in the active policy profile. Each named tool carries an allowlist of agent identities permitted to invoke it, an allowlist of human user identities the agent can act on behalf of, and the data classifications its arguments may carry. A tool call outside the profile fails closed at the gateway, before the MCP server sees the request.

Per-tool rate limits and per-identity quotas apply to tool traffic the same way they apply to model traffic. An agent that begins issuing an unusual volume of writes to a CRM tool trips the same rate-limit response as a user that begins issuing an unusual volume of prompts to a flagship model.

Tool registries live in the control plane. When a new MCP server is onboarded, its tools are catalogued, classified, and added to the active profile through the same workflow that governs model routes. There is no separate “agent control plane” to operate.

Tool-call arguments carry data out of the agent context and into a third-party server. The gateway runs the same data-classification engine over the argument payload that it runs over a model prompt, so PII, PHI, and regulated identifiers are redacted or tokenized before the MCP server receives them. A tool that legitimately requires a customer identifier receives a tokenized form that the calling identity can reverse, and a tool that does not is blocked from receiving the raw value.

Tool responses carry data back into the agent context. The gateway inspects responses on the return path, redacts regulated content the policy does not permit the agent to see, and lands the original and transformed responses in the forensic record. The next model call in the agent trace runs against the inspected response, so a tool that returns a payload with embedded PHI does not leak that PHI into the next prompt.

A single user prompt to an agent often produces ten to fifty downstream calls. The gateway requires the calling application to attach the originating user identity to the first request and propagates that identity through every subsequent model and tool call in the same agent run. Policy evaluates against the human identity, not the agent service account, so a tool call from an agent acting on behalf of a Finance user evaluates differently than the same call from an agent acting on behalf of an HR user.

Agent identity is preserved alongside human identity in the forensic record. A reviewer can ask “what did this agent do across all users” or “what did this user do across all agents” and get the same record set from either direction.

Each tool invocation lands its own HMAC-signed record in the forensic store, tagged with the agent run identifier so the full sequence of model calls and tool calls in a single agent run can be reconstructed in order. A regulator asking “what did this agent do with this customer’s data” gets a chronological export of every model and tool interaction across the agent trace, each independently verifiable.

The same export answers the security investigation question of which tools were touched during a compromised agent session, and the cost question of which tools accounted for the largest share of a project’s spend.

Agent observability tools that sit outside the request path see what an agent did after the fact. They are useful for debugging and metrics, and they are not a control. The MCP server itself can authorize a call, but the MCP server has no view of the originating user identity, the policy version in effect for that user, or the data sensitivity of adjacent calls in the same agent trace.

The gateway has all three. Tool governance and model governance run on the same engine, against the same policy profile, and produce the same forensic record. There is one place to write a rule and one place to defend a decision.