Architecture

MCP proxy

Coding agents (Claude Code, Cursor, Codex) run with your full permissions and call MCP tools that touch repos, databases, and prod, leaving no record your security tooling can see. The MCP proxy is the enforcement point for that boundary: it sits in front of any MCP server, inspects every tool call, and blocks the ones it shouldn’t allow before they land.

A mandatory chokepoint

The proxy is a mandatory pass-through: you wrap an existing MCP server entry in your client config, and every tools/call now flows through the proxy first. Governance then does not depend on the agent choosing to cooperate, which is the case that fails when a prompt-injected agent is the one misbehaving. It is small, zero-dependency, and drops in front of any server without changing it.

What it does per call

It reads the tool name and arguments, evaluates them against your policy (allow or deny, per tool), and, for an allowed call, mints the intent token that authorizes it. A denied call never gets a token, so the MCP server never sees an authorized request for it. The agent is told why it was refused, and every attempt (allowed or blocked) is written to an append-only audit log.

Figure 1. The proxy is the Hop-A enforcement point. It authorizes the agent’s tool call and stamps the intent token into the JSON-RPC _meta; the MCP server mints a fresh Hop-B token for the real downstream call.

Note

You don’t need to own the MCP servers your agents use, and usually you don’t. The proxy is the enforcement point between the agent and a server you don’t control, and it needs no account to start blocking destructive calls locally.

The audit trail

Every tool call the agent tried, the safe ones that passed and the destructive ones that were stopped, lands in an append-only log. That is the record otherwise missing: a durable, after-the-fact account of what an autonomous coding agent attempted at the tool boundary, independent of anything the agent itself reports.

▶Where it fits against the in-process runtime

The proxy and the client runtime are two enforcement points for two boundaries. The runtime governs an agent’s own HTTP egress from inside its process; the proxy governs what an agent asks a third-party MCP server to do, one tool call at a time. A system can use either or both.

The proxy’s token is a Hop-A delegation subject. It rides in the JSON-RPC _meta and carries no key binding, because the MCP server, not the agent, makes the downstream call. The binding moves to the server’s Hop-B token. The full chain is covered under MCP governance.

Keep reading