MCP Is the New Perimeter: Securing the Tools an Agent Can Reach
For twenty years, the security perimeter was a network. Then it was an identity. Now, when an autonomous agent can speak natural-language wishes into a tool registry, the perimeter is the tool registry itself — and most teams have not inventoried theirs.
Model Context Protocol is the standard that finally makes this concrete. An MCP server exposes a typed list of tools, each with a schema, each callable by an agent that has been granted access. Done well, MCP is the sharpest security boundary you have ever had: typed, audited, scoped per role, reversible. Done badly, it is the connector layer of 1998 — except the thing on the other end is not waiting for a human click.
The three rules we apply to every MCP rollout
Rule one: every tool is a permission. A tool is not “a function the agent can call.” A tool is capability that escapes your permission model the moment you expose it. Treat every MCP tool with the same scrutiny you treat a new endpoint on your API gateway. Who can call it? Under what role? With what rate limit? When the agent’s prompt context shifts, does the tool’s caller still match what your policy says?
Rule two: scope per agent, not per server. A single MCP server exposing thirty tools to four different agents is four different attack surfaces stacked into one configuration. We always split: each agent gets its own MCP namespace with the minimum tool set its job requires. A fraud agent does not see the commissions tools. A scheduling agent does not see the compliance log writer. Less surface, fewer footholds.
Rule three: prove the boundary holds. Before an MCP-backed agent ships to production, we run an adversarial pass. Prompt-injection attempts. Role-confusion. Tool-chaining to reach data the agent should not see. If the boundary breaks under that pressure, the boundary was theater.
MCP turns “what an agent can do” into a typed, enumerable, auditable list. That is a gift to security teams. It is also a gift to attackers who know to ask for it.
Why type-safe agent frameworks matter here
The reason we land most agent work on a type-safe framework is not hype — it is the type system. Every tool input and output has a validated schema. Every response is checked. Every trajectory is replayable. When an auditor asks “prove the agent could not have returned this customer’s SSN,” you answer that question with code, not paperwork.
The same property makes MCP boundaries enforceable. If a tool’s response schema does not include a field, the agent literally cannot leak it through that tool — the typed boundary holds whether or not the prompt is adversarial.
What we’d do
If you have stood up MCP and not yet asked these questions, this is the short list we run on day one of a security engagement:
- Inventory every MCP server reachable from any agent, in any environment.
- For each tool, document the schema, the caller agents, and the allowed roles. Anything undocumented gets revoked until it is.
- Replay the last 30 days of agent trajectories. Look for tool calls that should have been blocked. The pattern almost always exists.
- Run an adversarial audit. We do this with a prompt-injection playbook and a fuzzer over tool argument shapes. The findings tell you whether your perimeter is real or aspirational.
If MCP is sitting in your stack without an inventory yet, that is the first conversation we have on a discovery call. Book one →