MCP gateway vs MCP security: what a gateway covers
A gateway checks access and records the agent requests it receives. See which MCP security risks it handles and which still need other controls.
The decision in brief
A gateway for MCP is a checkpoint on the path between AI clients and the tools they use. For the requests it receives, it can check who is asking, apply access rules, keep credentials separate, hold back unreviewed tools, route sensitive changes for review and record what happened. MCP security is the wider job: it also covers prompt injection, the code of each server, local servers on laptops and every route that bypasses the gateway. Most teams need a gateway and those other controls together.
The short answer
The Model Context Protocol (MCP) connects AI clients, such as Claude Code or Cursor, to servers that offer tools: search a ticket queue, read a file, update a customer record. A gateway sits between those clients and servers. Clients connect to one governed endpoint, and the gateway checks each request before passing it on.
MCP security is broader. It covers every way agent tool use can go wrong: the model following instructions hidden in content, a server whose tools are not what they claim, a token used where it should not be, an agent with more access than its task needs, or a connection nobody knew existed.
So the comparison is less about two products than about scope. A gateway is one control within MCP security, and a strong one for the requests it receives. The question is which risks it handles in your deployment and who owns the rest.
Where each MCP security risk is handled
Two sources give a good starting list. The MCP security best practices describe attacks specific to the protocol, such as token passthrough and confused deputy problems. OWASP’s MCP Top 10, a beta project at the time of writing, groups the main risks into ten categories.
The table maps those ten categories to what a gateway can contribute and what has to come from elsewhere. It is a starting point for your own review rather than a description of any particular product, so ask for a demonstration of each row you depend on.
| Risk | What a gateway can do | What else is needed |
|---|---|---|
| Token mismanagement and secret exposure | Keep upstream credentials off devices and out of prompts, though this makes the gateway a valuable target | Secret stores and short-lived, narrowly scoped tokens |
| Privilege escalation through scope creep | Limit tools, resources and actions per team, and review new access | Narrow OAuth scopes and regular access reviews |
| Tool poisoning | Block tools until they are reviewed and treat changed definitions as new reviews | Vetting servers before approval and clients that flag changes |
| Supply chain attacks and dependency tampering | Little: it cannot inspect server code, only limit which servers are connected | Provenance checks, pinned versions and software bills of materials |
| Command injection and execution | Partly: it can reject arguments that fall outside the reviewed schema | Input validation and safe command handling in the server, plus sandboxing |
| Prompt injection through content the agent reads | Limit what a misled agent can reach and hold consequential changes for review | Model and client defenses and confirmation prompts |
| Insufficient authentication and authorization | Check identity and access on every request it receives | Each server still enforces its own access control |
| Lack of audit and telemetry | Record decisions and outcomes for routed requests | Client, server and endpoint logs for everything else |
| Shadow MCP servers | Nothing for requests it never receives | Discovery, endpoint inventory, network controls and an easy approved path |
| Context injection and over-sharing | Limit what tools can read and inspect responses where configured | Data classification and the model provider’s data terms |
What a gateway does well
A gateway is valuable because every request it receives passes through the same checks, whichever client sent it. It can confirm who is asking, whether they still belong to the team, and whether they may use this connection, tool and resource. Those decisions sit in one place instead of being repeated, inconsistently, in every client and server.
It can keep credentials apart. People sign in to the gateway, and the gateway calls the upstream system with a credential issued for that system. The MCP specification forbids passing a client’s token straight through, because doing so bypasses the upstream system’s controls and leaves no clear record of who acted.
It can treat tools as things to review. Tool names and descriptions are text the model reads and acts on, so a gateway that holds back unreviewed tools, and treats a changed definition as a new review, closes a gap the protocol leaves open. It can also route sensitive changes to a reviewer and record both the decision and the result.
A gateway brings security duties of its own
A gateway concentrates access, so it deserves the same scrutiny as any system that holds credentials for many others. In the MCP security best practices, a server that connects clients to third-party APIs is called a proxy server, and it has specific obligations.
Such a proxy must ask for consent for each client before forwarding to a third-party authorization server, match redirect addresses exactly and validate the OAuth state parameter. Without them, an attacker can exploit a user’s earlier consent to obtain access the user never granted, which the specification calls a confused deputy attack.
A gateway also fetches metadata and calls upstream servers on people’s behalf. The specification expects clients deployed on servers to guard against server-side request forgery, for example by requiring HTTPS, blocking private address ranges and checking redirects. Ask how a gateway handles these flows and what happens to the credentials it stores if it is compromised.
What sits outside a gateway
A gateway sees requests, not the reasoning behind them. If a document tells the model to send data somewhere, and the request is one the person is allowed to make, a policy check alone cannot tell intent from instruction. Anthropic describes prompt injection as far from a solved problem. Narrow permissions and review of consequential actions limit the harm; they do not make content trustworthy.
Local servers are outside it too. A server launched on a laptop runs with the user’s privileges, and its traffic never reaches a remote gateway. The MCP project’s guidance treats these as ordinary software that needs endpoint and software governance.
Tool annotations, such as a hint that a tool only reads data, are not enforcement either. The MCP maintainers recommend keeping safety guarantees in deterministic controls. Finally, a gateway’s rules do not apply when the same credentials are used through another route, and it cannot see what a client sends to its model provider.
An example: a support ticket with hidden instructions
Consider an illustrative support agent that reads tickets and can look up customer records. A ticket arrives containing text that tells the agent to export the full customer list and attach it to a reply.
The model may or may not follow the instruction; that depends on the model and client. If it tries, the gateway checks whether this person may use an export tool on that resource. If the tool was never enabled for support, the request is refused. If it was enabled and the team requires review for exports, a reviewer sees the exact request before anything runs.
If the export is permitted and needs no review, the gateway has nothing to object to: the request is allowed by the rules it was given. That is why tool design and access choices matter as much as the checkpoint itself.
How MCP security tools fit alongside
Products sold as MCP security often do different jobs from a gateway. Scanners inspect server packages and tool descriptions for hidden instructions before you approve them. Runtime monitors inspect content and behavior as agents work. Discovery tools look for MCP servers configured on devices.
These complement a gateway rather than replace it. Scanning informs which servers you approve, inspection adds a content check that policy alone cannot provide, and discovery shows which routes still bypass your controls. When you evaluate a gateway, these questions show what it enforces in your deployment:
- Which requests will the gateway actually see, and which routes bypass it?
- How are client sign-in and upstream credentials kept separate?
- How are tool definitions reviewed, and what happens when one changes?
- Can access be limited by tool, resource and type of action, not just by connection?
- How does review of a proposed change work, and what does a reviewer see?
- Does the record separate the access decision from the result of the action?
Where Durin fits
Durin provides MCP Governance through a gateway, for teams that need consistent rules and evidence for agent requests. For requests routed through it, each call must pass current identity, membership, team, connection, credential, reviewed tool, resource and inspection checks. Tools stay blocked until they are reviewed, and a changed tool definition needs fresh review. Durin calls the provider with the connection’s own credential and does not pass its own token upstream.
Reviewed requests can proceed by default after those checks. Teams can deny access by default or require another administrator to review proposed changes; the requester then sends the same request again before the permission expires. Durin records the decision and the outcome separately, and an uncertain result is never automatically repeated.
Durin does not prevent prompt injection and cannot govern requests that bypass it. Its Shadow MCP discovery reports MCP servers configured on enrolled devices, which helps you find those routes; it does not block them. Model, client, endpoint and server controls remain part of the plan.