MCP server security: put a gate in front of the tools your agent can call

An MCP server's job is to expose tools and route calls to them. It does that well, and deliberately doesn't take a position on whether a particular call should happen — that's the agent's decision. So the security model of "agent + MCP server" is really just the agent's judgment, and an agent's judgment is a probabilistic model that can be injected, confused, or simply mistaken. The more powerful the tools you connect, the more a single bad call can cost.

This is the same problem agents have everywhere, sharpened by how easy MCP makes it to grant power. Connect a database tool and a wrong call drops a table. Connect a shell tool and a wrong call runs rm -rf. The tools are doing exactly what they were built to do; the question is whether you want them firing the instant the model decides, with nothing in between.

Because MCP tool calls travel over HTTP, you can put a transparent proxy in their path. agent·shield sits between the agent and the server it calls, inspecting each request — method, path, and body — against your policies. Safe tool calls (reads, lookups, routine writes) are forwarded instantly, so the agent uses its tools at full speed. Calls that match a destructive pattern are held in an approval queue, and a person approves or denies before the tool ever runs.

The integration is the deliberately boring part: you point the agent's outbound base URL at agent·shield rather than at the tool endpoint directly, and nothing about the agent or the MCP setup has to change. No SDK, no wrapping each tool with a confirmation step, no fork of the server. The gate is infrastructure in front of the tools, which means it covers every tool the traffic flows through, including ones you add later.

When an agent has a pile of connected tools, the scariest question is the vague one: what has it actually been doing with them? agent·shield answers it concretely. Every tool call — forwarded, blocked, held, approved, denied — is written to an append-only audit log with the full request, the policy it matched, who decided, and when. You can reconstruct precisely which tools were invoked, with what arguments, and what was allowed.

That record also makes it safe to expose more capability over time. Start by holding any call that looks destructive, watch the queue and the log, and relax the policies for tool calls that prove routine — tightening if something surprising shows up. To be exact about scope: agent·shield governs the MCP and tool traffic you route through it, so point those calls at the proxy and that's the set it protects. It's a control layer on tool use, not a replacement for the server's own auth.