MCP Gateway Security: What Actually Matters
MCP gateway security comes down to one trade: you hand a single service the credentials for every tool your agent touches. Get that trade right and a gateway makes your setup safer than a folder full of config files with API keys in them. Get it wrong and you have built a single point of failure with working access to your CRM, your helpdesk, and your codebase.
This post assumes you know the basics: what OAuth does, why long-lived personal tokens pasted into config files are a bad idea. If that part is fuzzy, start with our [MCP security basics](/blog/mcp-security-basics) post and come back. Here we cover what changes once a gateway enters the picture, and the questions worth asking any vendor before you connect anything real.
What a gateway centralizes, for better and worse
An [MCP gateway](/blog/what-is-an-mcp-gateway) sits between your agent and your MCP servers. The agent authenticates once, to the gateway. The gateway holds the credentials for every downstream connection and forwards calls on the agent's behalf.
That centralization is the whole appeal, and it cuts both ways.
The good version: credentials live in one place instead of being scattered across laptops, CI configs, and agent config files. Rotating a key means updating one record. Revoking access means one click, not a hunt through every machine that ever saw the token.
The bad version: the gateway becomes the most valuable target in your stack. Whoever compromises it holds live credentials for everything behind it. So the real question is not "is a gateway secure", it is "does this specific gateway handle concentrated risk properly".
That question splits into five smaller ones.
The MCP gateway security checklist: five questions for any vendor
Ask these before you connect a single production tool. A vendor with good answers will give them quickly and in plain language. Vague answers are answers too.
How are credentials stored at rest?
The answer you want: encrypted per secret, decrypted only at the moment a call actually needs them. The answer you do not want: a database column that happens to be "internal", or one master key wrapping every customer's secrets in a shared blob. Per-secret encryption limits the blast radius if any single layer fails. If the vendor cannot describe where secrets live and when they are decrypted, that is your answer.
Can I revoke one connection without touching the rest?
Per-connection revocation sounds obvious and often is not there. If disconnecting one tool means rotating a shared secret or re-authenticating every other connection, you will hesitate before revoking. Hesitation is exactly the failure mode: the moment something looks off, you want one connection dead in seconds while everything else keeps running.
Are tokens scoped to what the agent actually needs?
A gateway that requests full account access "so everything works" is trading your risk for its convenience. If the agent only reads tickets, the token should only read tickets. Look for OAuth scopes requested per connection, not a blanket grant, and check whether you can see what each connection is allowed to do after the fact.
Is there an audit trail of every call?
When something looks odd (not if, when), you need to answer three questions fast: which agent called which tool, when, and through which connection. Without a per-call log you are reconstructing agent behavior from downstream side effects, which is slow and often impossible. We wrote up why this matters for agents specifically in [why AI agents need an audit trail](/blog/ai-agent-audit-trail). For a gateway it is table stakes: every call it forwards should leave a record you can read.
Do tokens ever appear in URLs?
URLs get logged everywhere: reverse proxies, server access logs, browser history, analytics tools. A token in a query string is a token copied into a dozen log files you do not control and cannot purge. Credentials belong in headers or in the encrypted store, never in the address bar. This sounds too basic to ask about. Ask anyway, because it remains one of the most common ways secrets leak.
Where Tulimoa stands on each point
Tulimoa is our product, so read this section as a vendor answering its own checklist.
The [Tulimoa gateway](/gateway) stores secrets in an encrypted per-secret vault, and they are used only at the moment of a call. Every connection is revocable on its own, at any time, without touching the others. Every call the gateway routes leaves an audit trail. Connections use OAuth where the upstream tool supports it, API keys where it does not. The whole thing runs in the EU, hosted in Frankfurt.
And the honest part: the gateway is in early beta and not self-serve yet, and we have no certifications to point at. So when access opens up for you, ask us the same five questions and judge the answers the same way you would judge anyone else's.
Frequently asked questions
Is an MCP gateway more secure than connecting servers directly?
It can be, but it is not automatic. Direct connections scatter credentials across configs; a gateway concentrates them in one place. Concentration wins only if that place has encrypted storage, per-connection revocation, and an audit trail. A gateway without those is just a bigger target.
What are the biggest MCP security risks?
The recurring ones: credential sprawl (keys pasted into config files), over-scoped tokens, no record of what an agent actually called, secrets leaking through URLs and logs, and connecting unvetted servers. A good gateway addresses the first four. Vetting which servers you trust stays your job either way.
What does a secure MCP setup look like for a small team?
Keep the server list short and vetted, prefer OAuth over static API keys wherever the tool offers it, scope every token to what the agent needs, and make sure you can revoke any single connection fast. Then check that someone can answer "what did the agent do yesterday" from a log rather than from memory.