MCP Gateway Security: Controls That Actually Matter

MCP gateway security comes down to five controls: a separate scoped key per caller, a deny-by-default tool allowlist, human approval for side effects, upstream credentials kept server-side, and a log of every call. A gateway enforces these well, but it cannot stop a model from misusing tools it is legitimately allowed to call.

Start from the threat model

Before choosing controls, name what can go wrong. With a gateway in the middle, there are six recurring failure modes. BusinessMCP’s MCP security best practices guide frames them as a threat-to-mitigation table, and they map well onto any gateway.

Threat	What it looks like	Primary mitigation
Leaked key	A Bearer token pasted into a repo or chat	Per-caller keys, rotation, secrets manager
Misused tool	A permitted tool called with harmful arguments	Least privilege, small tool set
Irreversible action	Email sent, money spent, record deleted	Human approval, cost caps
Cross-tenant access	One customer reading another’s data	Workspace-scoped keys, database row-level security
Credential exfiltration	Upstream token reaches the model	Server-side vault, never in tool output
Silent misbehaviour	Wrong calls nobody notices	Full call logging and alerting

Control 1: one key per caller, scoped narrowly

A shared key is the weakest design, because revoking it breaks everyone and you cannot tell who did what. Issue a key per agent, machine or integration, and attach the smallest policy that lets it do its job. BusinessMCP’s documentation for exposing an MCP endpoint recommends exactly this: separate keys per agent so each can be revoked independently, rotation of unused keys, and keeping mcph_ keys out of source control.

Treat the key like a database password. Anyone who holds it can act as the workspace it belongs to.

Control 2: deny by default, then add tools

The default posture should be everything closed. Enable the capabilities a key needs and nothing more, keep write, delete and send tools off unless required, and remove tools nobody uses. A smaller catalogue also helps the model choose correctly. We cover the mechanics in the tool allowlist article.

Key takeaway: every tool you expose is an action an injected instruction might trigger. The cheapest security control is exposing fewer tools.

Control 3: approval gates for consequential actions

For actions that are irreversible or visible outside your organisation, let the agent propose and a human decide. The BusinessMCP tool catalogue states that tools marked as needing approval never act on their own, and that sending email is one of them. Its tool reference also describes per-run cost ceilings as a second limit. Whichever product you use, check that approval is enforced in the execution layer and not only suggested in the interface, since a model can be talked around a UI prompt but not around a code-level permission check.

Control 4: keep upstream secrets off the model’s side

OAuth tokens and API keys for connected systems should sit in an encrypted store and be resolved by the gateway on the server. They must not appear in tool arguments, tool results or logs. The same principle applies to the gateway’s own hardening: for example, anything that fetches user-supplied URLs needs a guard against server-side request forgery. BusinessMCP publishes MIT-licensed hardening helpers, extracted from its production gateway, that include such an SSRF guard and tool-name namespacing; the repository itself says it has had no external audit and lists a remaining DNS-rebinding window, which is a good example of a vendor stating limits plainly.

Control 5: log every call

Without a record you cannot investigate or prove anything. Log the tool, arguments, result summary, caller identity and time, and protect the log from tampering. See MCP audit logging for what to capture and what to leave out.

The threats a gateway cannot close

Be honest about the limits.

• Tool poisoning. A malicious server can hide instructions in a tool description. Models read descriptions as if they were guidance. BusinessMCP’s guide to MCP prompt injection summarises mitigations: vet servers, pin versions and require re-consent when descriptions change.
• Rug pulls. A server behaves, then changes after approval. Only version pinning and hash checks help.
• Indirect injection. Text in a web page, ticket or database row can instruct the model. Treat all tool output as untrusted data.
• Excessive agency. OWASP lists this among its top risks for LLM applications. The fix is permission design, not a bigger firewall.

Authentication choices

The MCP authorization specification builds on OAuth, and a remote gateway has to decide how callers prove who they are. In practice you will meet two patterns.

Pattern	Good for	Watch out for
Bearer API key per caller	Servers, scripts, desktop clients that accept a header	Keys are long-lived by default and easy to paste into the wrong place
OAuth with consent	Hosted assistants and custom connectors that sign users in	A proxy that uses one static client ID for everyone can let an attacker skip consent (the confused deputy problem)

BusinessMCP’s description of its hosted endpoint mentions both: Bearer keys with access policies for most clients and an OAuth 2.1 server with PKCE for Claude.ai custom connectors. Whatever you pick, ask whether tokens are bound to a user or workspace, whether they can be revoked individually, and whether the gateway ever passes a client’s token straight through to an upstream service. The protocol guidance forbids that passthrough.

Tenant isolation and data classes

If the gateway serves more than one team or customer, isolation has to hold below the application. Workspace-scoped keys are one layer. The database should also enforce row-level security so that a bug in a tool handler cannot return another tenant’s rows. BusinessMCP’s security guide states that its tables are workspace-scoped with row-level security and that source credentials sit in a vault with deny-all policies; those are vendor statements, so treat them as claims to verify during procurement, not as proof.

A second useful idea is classifying the data each tool touches. The same guide describes access policies built from data classes such as revenue, contact PII, enrichment, behaviour and messaging, so that a restricted key advertises fewer tools and has output redacted. Classification makes reviews faster: instead of reading forty tool descriptions, a reviewer asks which classes a key can reach.

A hardening checklist

1. Inventory every tool, and label each read, write or irreversible.
2. Issue one key per caller, and write down what each is for.
3. Start each policy with no tools, then add only what is needed.
4. Require approval for anything irreversible or external.
5. Set per-run cost or call ceilings.
6. Keep upstream credentials in an encrypted store, never in client config.
7. Pin or hash third-party tool descriptions, and review changes.
8. Log calls centrally and alert on unusual patterns, such as a read-only key attempting a write.
9. Test the controls: try calling a hidden tool by name, and confirm it is refused.
10. Review the whole list when you add a server.

Where to go next

If you are choosing a product, run these questions through our evaluation checklist. If you are in a regulated setting, read the notes on enterprise MCP gateways. And whatever you adopt, verify claims by testing. A security feature that exists only on a features page protects nobody.