MCP Server Security: The Gap Nobody's Patching

MCP server security is the practice of vetting and authorizing every tool an agent discovers through the Model Context Protocol before that tool's call is allowed to execute, rather than trusting whatever name and description the server happens to advertise. The Model Context Protocol gave agents a standard way to call tools, whether that means reading a file, hitting an API, or querying a database, without every integration turning into a bespoke, hand-wired mess. It has also quietly become the default path most agent actions now take to reach the outside world, and almost nobody has threat-modeled it. The risk isn't hypothetical: as MCP adoption accelerates, more of what an agent is capable of doing routes through servers an organization did not build and cannot fully audit, and the protocol's ease of integration has outpaced any equivalent review process for what actually gets connected to it.

An integration layer, treated like plumbing

MCP servers get adopted the way internal tools always do. Someone stands one up to solve a real problem, it works, and it spreads. What tends not to happen is the review that every other trust boundary in the stack already receives: who can register a server, what that server is actually allowed to do once an agent trusts it, and what happens when its tool definitions change after the fact.

That last point is where the risk concentrates. A tool's name and description are exactly that, a name and a description, supplied by whoever runs the server. Nothing stops a compromised or malicious MCP server from advertising a helpful-sounding tool and then doing something else with the arguments it receives, or from silently changing its own tool schema between the moment an agent discovers it and the moment it is called.

A tool you didn't vet is a command you didn't read, running with your agent's authority.

What's actually crossing the boundary

Every MCP call carries three things worth inspecting, regardless of the transport it travels over (stdio, SSE, or HTTP): the tool name being invoked, the schema it claims to implement, and the actual arguments being passed. Most agent frameworks log this after the fact, if they log it at all. Almost none of them evaluate it before the call leaves the agent, which is the only point where a bad call can still be stopped rather than merely noticed.

Deny by default, not detect after

The answer is not a smarter classifier for suspicious tool calls. That is a detection problem, and detection means the call has already happened. The answer is authorization: every outgoing MCP call is checked against policy before it leaves the agent, and only explicitly approved tools are allowed through. Unapproved servers and unvetted tools are denied by default, in the same way you would not let an unreviewed binary run in production simply because it asked.

MCP made agent-to-tool integration easy. It did not make it safe by default. That part still has to be built in, at the transport layer, rather than assumed.

Sources

• Tools. Model Context Protocol specification, version 2026-07-28. The set of tools a server exposes may change over time, servers can announce changes with a list-changed notification, and clients must treat tool annotations as untrusted unless they come from trusted servers.
• Security Best Practices. Model Context Protocol documentation, version 2026-07-28. MCP's own guidance on confused-deputy attacks, token passthrough and scope minimization.
• MCP Security Notification: Tool Poisoning Attacks. Invariant Labs, April 2025. Describes tool poisoning and "rug pull" attacks, where a malicious server changes a tool's description after the client has approved it.