A security gateway for MCP servers: what it does and when you need one

Why “add OAuth” isn’t always where the conversation ends

Model Context Protocol (MCP) servers give an AI agent the ability to call real tools — reading files, querying a database, hitting an internal API — and the MCP specification (read 2026-10-27) is explicit that authorization itself is optional: HTTP-transport implementations “SHOULD” support it, which is not the same as “MUST.” Our guide to securing an MCP server covers implementing that OAuth flow, a tool allowlist, and defenses against prompt injection in tool responses directly in your own server’s code. This guide covers a different question that comes up once you’re past a single server you fully control: what does a dedicated security gateway add, what does it actually do under the hood, and when does putting one in front of your MCP server make more sense than building everything into the server itself.

What exposure looks like without either one

The pattern is consistent across public scans of MCP deployments: a server stood up quickly during a prototype, left reachable on the public internet, with no authorization layer ever added before anyone noticed it was there. Once that server accepts an unauthenticated initialize call, anything that can reach it can typically enumerate its tools with tools/list and start calling them — file access, database queries, or shell commands, depending on what the server exposes. A second, separate risk sits in the other direction: if a tool returns content from an untrusted source, that content can carry text crafted to look like instructions, a pattern OWASP’s Top 10 for LLM Applications (read 2026-10-27) lists as its top risk, LLM01: Prompt Injection. Neither risk is specific to having “no gateway” — both exist whether you’re running one server or ten, with or without a proxy in front of it. What changes with scale is how practical it is to address both consistently.

What a security gateway actually does

Strip away the marketing and a gateway for MCP servers is doing four concrete jobs, each one a control you could otherwise implement directly inside a server’s own code:

• Authorization enforcement. The gateway sits between the caller and the MCP server, checking an OAuth token against the flow defined in the MCP Authorization specification (read 2026-10-27) before forwarding anything. A call without a valid token never reaches the server behind it.
• Tool allowlisting. Authentication answers who’s calling; a tool allowlist answers what they’re allowed to call. A gateway can maintain that list once, centrally, rather than requiring every server behind it to implement its own allowlist logic.
• Audit logging. Every call that passes through the gateway — who called it, which tool, when, and what came back — lands in one place, which matters when you’re trying to reconstruct what an agent actually did after the fact, across however many servers sit behind the gateway.
• Response screening. Tool responses coming back through the gateway can be checked for obviously malicious content before they reach the calling agent, as one layer among several, not a complete defense against prompt injection on its own.
• Rate limiting. A gateway is a natural place to cap how many calls a given client or token can make in a given window, which protects the MCP server behind it from being overwhelmed by a misbehaving client or a credential being used far more aggressively than it should be — independent of whether that traffic is malicious or just a bug in a calling agent’s retry logic.

None of these five is a new security primitive invented for MCP specifically — OAuth enforcement, allowlisting, centralized logging, and content filtering are all established patterns applied to a new transport. What’s specific to MCP is that the spec leaves authorization optional and tool permissioning unaddressed entirely, which is exactly the gap a gateway is built to close without requiring every MCP server behind it to close that gap independently.

That gap matters more as the number of MCP servers an organization runs grows. A single internal server built and maintained by one team is a reasonable candidate for implementing OAuth directly in its own code, with no proxy in between. An organization running a dozen MCP servers across different teams — some internal, some wrapping third-party APIs, some inherited from an acquisition — is a much harder case to keep consistent server by server, which is precisely the scenario a centralized gateway is built to address.

Gateway versus building it into the server: when each makes sense

Implementing OAuth directly inside a server you control, as covered in our guide to securing an MCP server, is the more defense-in-depth choice when you have the access and the time: the control lives as close to the resource as possible, with no dependency on traffic actually routing through an intermediate proxy. A gateway earns its place in a few specific situations instead:

• You’re running more than one MCP server and want one consistent authorization and logging policy instead of implementing and maintaining the same logic in each server’s codebase separately.
• You’re fronting a third-party or vendor-supplied MCP server whose code you don’t control, where adding OAuth directly isn’t an option at all.
• You want a single audit trail across every MCP server an organization runs, rather than reconciling separate logs from each one after an incident.
• You’re prototyping quickly and want authorization enforced without carrying a full OAuth implementation inside the prototype itself, with the intent to harden the server directly later.

These aren’t mutually exclusive — a server can implement its own OAuth checks and sit behind a gateway, which is the more defended configuration of the two, since a gap in one layer doesn’t leave the resource completely open.

What a gateway can’t do

A gateway only ever sees the traffic that’s actually routed through it. If a client — or an attacker who finds the server’s direct address — connects straight to the MCP server, bypassing the gateway entirely, the gateway has zero visibility into that call and enforces nothing on it. This is the same limitation every reverse-proxy security control shares, not something unique to MCP: putting a gateway in front of a server doesn’t retroactively close a server’s direct, un-proxied listener. If the underlying server is still reachable on its own address, it carries exactly the exposure it had before the gateway was added, and closing that direct path (network-level restriction, or simply not exposing the server’s own port) is a separate, necessary step.

Check your own exposure first

Before deciding whether you need a gateway, implementing OAuth directly, or both, find out what you’ve actually got exposed today. AdminKit’s MCP endpoint check is built to test whether an MCP server accepts an unauthenticated initialize call and, if so, what tools/list then reveals — it’s coming with the AdminKit Check API and isn’t live yet. Two things that work today instead:

• AdminKit’s open-source adminkit-mcp probe, self-hostable from the mcp/ directory: adminkit-mcp probe https://mcp.example.com/mcp runs the same endpoint-exposure check and prints JSON, no server process required. See connect an AI agent to AdminKit’s MCP server for the full setup.
• AdminKit’s free GitHub Action, which runs the identical probe on every push or a weekly schedule and fails the build on a high-severity finding — see scan an MCP endpoint in CI for the workflow configuration.

Both only ever send initialize and tools/list, never tools/call, so they’re safe to point at a server already in production use.

Open-source adminkit-mcp versus the planned MCP & Agent Gateway

These two are easy to conflate by name alone, so it’s worth being precise about which is which, since they solve opposite-facing problems. adminkit-mcp is AdminKit’s own MCP server — open source, MIT-licensed, self-hostable today — that gives an agent outward-facing tools like check_mcp_endpoint and check_ip. It’s something an agent calls outward, toward AdminKit. AdminKit’s planned MCP & Agent Gateway is the inward-facing piece: a proxy meant to sit in front of your MCP server, applying the OAuth enforcement, tool allowlisting, and audit logging described above to calls arriving at your server from the outside. One ships today as open source; the other is early access / in development and not live yet. A team building an agent that needs to assess an unfamiliar MCP endpoint’s exposure before calling it can use adminkit-mcp’s tools now; a team that wants a managed proxy in front of the MCP server it’s publishing is the audience for the Gateway once it ships.

Where AdminKit’s MCP & Agent Gateway fits

The plan for AdminKit’s MCP & Agent Gateway is to implement exactly the four jobs described above as a hosted or self-hosted proxy: OAuth checks per the MCP authorization spec, a per-tool allowlist, an audit log of every call, and screening of tool responses for obviously malicious content, so a developer publishing an MCP server gets authorization and logging without implementing either from scratch. It’s in early access / in development today, which means for now, implementing the OAuth flow directly in your server’s own code — or, where that’s not practical, evaluating a different hosted gateway — remains the available path. AdminKit’s Agent Trust API, also planned, addresses the client side of the same picture: letting an agent score an unfamiliar endpoint before calling it, rather than a gateway protecting the server side after the call arrives.

Defensive use only

The exposure checks this guide links to — mcp-check, the adminkit-mcp probe, and the GitHub Action — are for MCP servers you own or are explicitly authorized to test. None of them call a tool the server exposes; all three stop at initialize and tools/list. See our Disclaimer and Acceptable Use Policy for the full terms.