Enterprise MCP Gateway Security: What It Actually Has to Do

A few weeks ago we wrote about what enterprises actually ask for when they sit down to govern MCP: one endpoint per workflow, per-tool audit, profile-based access, traces that land in their SIEM. That article was about governance: the control-plane shape security teams want.

This one is the implementation-level companion. Once you decide to put a gateway in front of every AI client, that gateway becomes the single path all tool-calling traffic flows through. That is the entire value proposition. It is also a concentration of risk that has to earn its place. So this is the other half of the conversation: the concrete security primitives an enterprise-grade MCP gateway has to ship, why each one matters, and what breaks without it.

One honesty note up front, because the rest of the article depends on it. We do not have a paid enterprise deployment yet. What follows is the security baseline we scoped as the bar to clear before our first one: the list our engineering, sales, and security thinking converged on when we asked what would have to be true before we'd let a regulated customer route real traffic through this. Field notes from building toward a deployment, not a victory lap after one.

Start with why the gateway exists at all. Without one, every developer and every non-developer role wires their own AI client into their own set of MCP servers, each with its own credentials, on their own machine. Nobody can answer who can reach what. That is the N×M problem every enterprise hits.

Our sales and positioning lead, Matyáš Křeček, framed the value the way a security buyer hears it:

That is the deal. You collapse a sprawl of unaudited local configurations into one path you can see, log, and control. But the same sentence read by a security architect says something sharper: you have just built a single component that every AI-to-tool call depends on. If that component leaks credentials, fails open, or can't tell you what passed through it, you haven't governed the risk; you've centralised it. Everything below is about making the central path safe enough to be worth concentrating onto.

When our team — Miloš Halda on implementation, Matyáš on positioning, Prokop Simek on the compliance posture — scoped the baseline, it came down to five primitives. None are exotic. All are uncomfortable to retrofit.

The gateway holds credentials for every downstream tool: GitHub tokens, database passwords, CRM API keys. The moment those sit in plaintext in a config file or, worse, get pasted into a chat prompt, the gateway's central position works against you. One leaked config is every tool compromised at once.

On how we handle it, Miloš was specific in the same breath as the honesty note:

It's authenticated encryption: you get confidentiality and tamper detection, so a modified ciphertext fails to decrypt rather than silently returning garbage. Reaching for vetted, standard cryptographic primitives rather than a hand-rolled scheme is the boring, correct choice. What breaks without it is not subtle: credentials in the clear are the first thing any audit flags and the first thing any attacker reads.

Access tokens expire. In a sprawl of local configs, that means tokens get regenerated by hand, copied around, and occasionally pasted somewhere they shouldn't be. Centralising auth at the gateway lets you refresh tokens before they expire and keep them out of prompts entirely. The gateway holds the long-lived credential, the AI client never sees it.

This is also where we are honest about the state of the ecosystem. As we noted in the governance article, the MCP authorisation model — OAuth 2.1, PKCE, dynamic client registration, the late-2025 spec changes — is converging, but real-world MCP servers sit at very different points on that curve. We can centralise and refresh credentials at the gateway; integrating servers that still ship pre-spec auth is per-server work, not a solved switch.

An AI client in an agent loop is not a human clicking buttons. A poorly scoped autonomous task can call a downstream tool hundreds of times in a minute, and the tool on the other end — a production database, a payments API — was sized for human traffic. Throttling at the gateway protects downstream systems from a runaway agent and gives you a choke point to contain abuse. Without it, the blast radius of one bad agent run is whatever your slowest downstream dependency can survive.

This is the primitive security teams care about most, and it is the one most platforms get wrong by logging at the wrong altitude. Prokop put the architectural intent plainly:

The atomic unit has to be the tool call: who called which tool, with what arguments, what came back, status, duration. "This server was contacted" is not an audit trail. As we covered in the governance piece, the structured trace store and a filterable viewer are shipped today; the OpenTelemetry export that pipes those traces into Splunk, Sentinel, or Elastic is on the roadmap, not in customers' hands yet. We say that in POCs and we'll say it here: the store exists, the SIEM pipe is the next milestone.

The fifth primitive is the one engineers underrate: documentation of the data flow, the authentication model, and the audit trail, written so a security reviewer who has never seen your code can follow what happens to a request. In a regulated procurement, the security questionnaire is part of the product. A gateway with great internals and no documented data-flow diagram fails the review it should pass. We treat the security documentation as a deliverable, not an afterthought, because for the buyer it is the part they can actually inspect.

Primitives are the answer; it helps to be precise about the question. Prokop named the threat model that regulated clients keep raising:

Two things worth separating there. First, prompt injection and the broader OWASP Top 10 for LLM applications are a genuine attack surface, and a gateway is a natural place to inspect tool-call parameters and responses for known patterns. We are honest that pattern-based prompt-injection detection is on our roadmap, not shipped. Even when it ships, it's defence-in-depth, one layer alongside tool-capability minimisation and human approval on destructive calls, never a guarantee.

Second, data egress. Stopping sensitive or GDPR-relevant data from flowing into a third-party model is a real enterprise requirement. Whether the gateway should anonymise or obfuscate that data in flight is, honestly, an open design question for us rather than a feature we claim. Naming it as open is the point: a gateway that pretends to solve data anonymisation it hasn't built is exactly the kind of overclaim a security review exists to catch.

Enterprise buyers in finance and the public sector ask about ISO 27001 and, in the Czech market, the cyber-security law. Prokop frames it as a question of behaviour, not just certificates:

It's the right instinct. Compliance is a behaviour before it's a certificate. The architecture is oriented around the things a certificate would later check: encryption, logging, audit trail, knowing what flows where. The ISO 27001 plus Czech cyber-security law research is underway, not finished. The structural advantage we lean on in the meantime is deployment topology.

Local MCP Gateway runs entirely on the customer's infrastructure: configuration, traces, and credentials all stay in a local database. No external SaaS dependency, no telemetry callback, nothing leaving the perimeter unless the customer explicitly connects to a remote server they chose. For a Schrems II conversation or a "the data does not leave our perimeter" requirement, local-first turns a long third-party-data-flow explanation into a short one. There isn't one to explain.

Same honesty section as the governance article, because the gaps are real and naming them is part of the pitch.

The honest framing is that none of this is shipped against a paying customer yet. These are pre-deployment requirements: the list we're working through precisely so the first paid deployment isn't where we discover what was missing.

If you're standing up AI clients against internal systems and trying to decide what "secure enough" means for the path between them, the short version is: encryption with authenticated ciphers, centralised credential and refresh handling, throttling, per-tool audit that reaches your SIEM, and documentation a reviewer can actually read, with deployment topology doing a lot of the compliance work. The governance article covers the control-plane shape around these primitives; if security and governance is something your teams need to get fluent in, our AI Security & Governance workshop walks through secure MCP development, prompt injection, and OWASP for LLMs directly. And if you're weighing which AI coding tools sit on top of this layer, the Claude Code vs Cursor vs Copilot field report covers where each one's governance posture breaks down.

If you're scoping a POC, the place we most want input is the roadmap above: the order security teams push for. We package the supported product layer as MCP Gateway Enterprise; if you want to see Local MCP Gateway running against a real workflow, get in touch. We'll bring the gateway, the security questions enterprises have actually asked us, and an honest read on which primitives are shipped and which are still ahead of us.