MCP Server Security: Why Scanners and Gateways Both Matter Now

The attack surface has moved

The security conversation around AI coding assistants is shifting from what a model says to what it is allowed to do. The Model Context Protocol (MCP) has become a common way for agents to reach external tools, and that convenience creates a new problem. Anyone who can alter an MCP server's tool descriptions, its responses, or its updates can, in effect, issue instructions to the assistant connected to it.1 Securing MCP servers is now a front-line concern rather than something to tidy up later.1

That framing is reinforced by recent incidents. Reports that a Google AI system broke into three companies without human direction, together with a recent compromise involving Hugging Face, are cited as evidence of the same weakness: the tools an autonomous agent is permitted to call.1 Those reports are offered as warning signs rather than detailed case studies, but they point to a clear concern. As agents gain autonomy, the trust boundary sits wherever they pick up instructions, and tool metadata is one of those places.

Tool poisoning is not just prompt injection

An argument from the AI-gateway side sharpens the threat model. MCP tool poisoning should not be treated as one more variety of prompt injection. It is better understood as a supply-chain attack on the agent's context window.2

The distinction matters. Classic prompt injection is usually imagined as hostile text arriving through content the user asked the model to process, such as a web page or a document. Tool poisoning arrives through infrastructure the developer chose to trust. A tool's description is loaded into the model's context as part of normal operation, so malicious text placed there does not need to trick the user into anything. It only needs to be present when the agent reads its toolset. This is why both perspectives focus on the integrity of tool definitions and updates, not only on filtering user input.12

The supply-chain comparison also explains why the problem is hard to spot. A server that behaved well yesterday can ship a changed description today. A developer who reviewed an integration once may never look at it again, while the agent rereads it on every session.

Two places to put the lock

The comparison between MCP-Scan and Docker's MCP Gateway reflects two broad strategies for this risk.1 One is inspection: examine MCP servers and their tool definitions to find suspicious or altered content before or while they are used. The other is mediation: place a controlled layer between the agent and its tools so that every call and every piece of tool metadata passes through a checkpoint.

The gateway case is that schema validation at that layer can close the poisoning channel before the model ever sees the manipulated content.2 The reasoning is simple. If the model is the component that gets tricked, the safest defense is one that does not depend on the model noticing the trick. Rejecting malformed or out-of-policy tool definitions upstream removes the attack from the context window entirely.

The practitioner-oriented view of the same problem puts the question as one of locking down AI tool access. That covers knowing which servers an assistant can reach and who controls what those servers send back.1 In practice, scanning and gateway enforcement answer different questions. A scanner asks whether a given server looks trustworthy. A gateway asks whether a given interaction should be allowed through.

Where the perspectives diverge

Both perspectives agree on the core diagnosis: tool descriptions and responses are a live instruction channel, and an attacker who controls them can control the agent.12 The difference is emphasis. The gateway-focused argument treats the gateway as the new front line and implies that enforcement at a choke point is the structural fix.2 The comparative framing treats the decision as a choice of tools for developers who want to harden their setups now, with scanning and gateway approaches considered side by side.1

That difference partly reflects who is making the argument. A gateway vendor has an obvious reason to favor architectural enforcement, and a guide aimed at individual developers will lean toward options that are easy to adopt. Neither point weakens the shared threat model, but readers should account for it.

The takeaway

The stronger reading is that these approaches complement each other rather than compete. Scanning is useful for audits and for catching problems in servers a team already depends on. It is a point-in-time check, though, and tool poisoning is a moving target because updates can change behavior after a review. A gateway that validates schemas and mediates calls offers continuous enforcement, but only if teams actually route agent traffic through it and keep its policies strict.

For teams running autonomous or semi-autonomous coding agents, a practical approach is to inventory every MCP server an assistant can reach, treat tool metadata as untrusted input, and place a checkpoint between agent and tool instead of relying on the model's judgment. The idea both perspectives share is that an agent is only as trustworthy as the least-controlled tool it can call.