MCP gateway vs runtime security
An MCP gateway decides who may call which tool, before the call happens. Runtime security inspects what the call carries and returns, while it happens. A gateway stops an unauthorized user; it does not notice a poisoned tool description or an injected instruction in a response from an allowed tool. Runtime detection notices those, but without a gateway it cannot say whose agent it was or stop that identity. Any agent that reads untrusted content and holds write access needs both.
Side by side
Marks follow the shared criteria. MCP gateway and Runtime security are in the main comparison table.
| Dimension | MCP gateway | Runtime security |
|---|---|---|
| When it acts | At access time: connecting, listing tools, authorizing each call. | During the call: tool definitions, arguments, outputs, the session. |
| Question it answers | May this user's agent call this tool? | Is this call doing what the user asked, and is anything hostile in it? |
| Visibility | Partial: every call routed through it. | Partial: every session it is wired into. |
| Authentication | Strong: SSO and OAuth per the MCP authorization spec. | None of its own. |
| Credential handling | Strong: holds upstream tokens, no passthrough. | Partial: can mask secrets in outputs. |
| Policy depth | Partial to strong: tool allowlists, argument rules in some products. | Partial: block, mask or alert on detections. |
| Tool poisoning | Partial: only by allowlisting vetted servers. | Strong: scans tool descriptions and changes to them. |
| Prompt injection | Partial: least privilege limits the blast radius. | Strong: inspects inputs and outputs. |
| Exfiltration | Partial: can deny outbound tools. | Strong: reads what leaves in arguments and outputs. |
| Audit | Strong: one choke point, one complete log. | Partial: detections and context. |
| Deployment effort | Medium: clients pointed at it, servers registered. | Medium: needs a place in the call path, then tuning. |
What a gateway enforces
A gateway sits between AI clients and MCP servers. It authenticates the person behind the client through your identity provider, holds the credentials for upstream servers so the client never sees them, and decides which servers and tools each user, group or agent may use.
The MCP specification's security guidance explains why that position matters: a server that passes a client's token straight through to an upstream API breaks audit and lets one token reach places it was never meant for. A gateway that brokers credentials removes that path by design.
What runtime detection catches
Tool poisoning hides instructions in a tool's description, which the model reads in full and the user usually never sees. Indirect prompt injection hides them in content the agent reads: an email, a ticket, a page. Both arrive through tools that are allowed, from identities that are authenticated. Only something that reads the content can catch them.
Runtime scanners compare what the agent is doing with what it was asked to do (intent drift), and watch arguments and outputs for private data heading somewhere it should not.
When you need both
Simon Willison's "lethal trifecta" is a useful test: an agent with access to private data, exposure to untrusted content and a way to send data out can be made to leak. The gateway removes legs of the trifecta by scoping tools and credentials; runtime detection watches the legs that remain.
Running them as one layer means a detection can act on the identity the gateway already knows: block that agent's next call, require approval for that user, record both in the same audit log. That is how Runlayer is built: its gateway and its runtime scanners share one policy engine and one audit trail.
Which suits whom
- You know which MCP servers you run and your first gap is identity and credentialsStart with a gateway, and add runtime scanning before agents read untrusted content.
- Your agents read email, tickets or the web and can also write to systems that matterYou need both. Runlayer combines them in one call path.
- You build your own LLM application and control every promptRuntime detection or a prompt guardrail API in your code; a gateway once you expose MCP servers to other teams.
Sources
- Security Best Practices (confused deputy, token passthrough, SSRF, session hijacking, local server compromise, scope minimization) · Model Context Protocol specification, 2025-11-25
- Authorization · Model Context Protocol specification, 2025-11-25
- MCP Security Notification: Tool Poisoning Attacks · Invariant Labs
- LLM01:2025 Prompt Injection · OWASP Gen AI Security Project
- The lethal trifecta for AI agents: private data, untrusted content, and external communication · Simon Willison
- ToolGuard (tool definition, output and intent-drift scanning) · Runlayer documentation
- Policies (users, groups, agent accounts, tools, payload conditions, approvals) · Runlayer documentation