MCP solved a real, boring problem
Before MCP, every agent-to-tool integration was its own bespoke wiring job: a custom function schema, a custom auth flow, a custom error format, repeated for every tool and every framework. MCP standardizes that connection - one protocol an agent can speak to any MCP server and one protocol a tool can expose to any MCP client. That's a genuinely good idea and it's why adoption has moved fast.
Standardizing the connection also means standardizing the blast radius. An MCP server that exposes a "run query" tool, a "send email" tool and a "deploy" tool is now reachable by any agent that can speak the protocol - which, by design, is supposed to be easy.
The boundary that matters isn't the wire protocol
A lot of early "MCP security" conversation focuses on transport-level concerns: is the connection authenticated, is it encrypted, is the server who it claims to be. Those matter, but they're not the interesting boundary. The interesting boundary is: once an authenticated agent is talking to an authenticated MCP server, what is it actually allowed to do?
An MCP server doesn't know why an agent is calling a tool, whether the action fits the agent's actual job, or whether a human should see it first. It knows the call is well-formed. That's a protocol-level guarantee, not a policy-level one - and the two get confused constantly.
Three questions an MCP deployment should be able to answer
Which agent, on whose behalf? MCP servers are commonly deployed with a single shared credential for every client that connects. That collapses agent identity, workload identity and human identity into one undifferentiated caller. If something goes wrong, "the MCP server did it" is not an audit trail.
Which tools, against which targets? "This agent can use this MCP server" is a much coarser grant than most teams realize - it usually means every tool the server exposes, against every target it can reach. A policy layer should be able to say yes to search and no to delete without needing two separate servers.
What gets logged when a tool call happens? If the answer is "whatever the MCP server's own logs happen to capture," that's not a security control, it's a debugging aid. An authorization decision - allowed, held, denied - is a different kind of record than a request log and it needs to exist independent of any one server's implementation.
Where the control belongs
None of this is an argument against MCP - it's an argument for putting the same authorization layer in front of MCP that you'd want in front of any other path an agent can use to reach production systems. The protocol standardizes how agents and tools talk to each other. It was never meant to be the place where you decide what's allowed.
That decision belongs at the boundary between the agent and everything it can reach - MCP servers included, alongside internal APIs, cloud infrastructure and everything else. One policy, one identity model, one audit trail, regardless of which protocol the agent happened to use to get there.
