MCP Gateway Security: Controls and Failure Tests
Secure an MCP gateway against token confusion, tool poisoning, argument mutation, prompt injection, replay, tenant crossover and enforcement bypass.
MCP gateway security depends on enforced identity, server provenance, tool policy, argument authorization, credential isolation and bypass resistance. Sanitizing a prompt or hiding a tool from discovery does not stop a client from calling it directly. The protected server must still reject unauthorized requests.
The MCP gateway guide describes the category and product choices. The test plan below assumes a gateway has already been selected and asks whether its controls hold under hostile inputs and broken dependencies.
Build the threat map
| Threat | Preventive control | Test |
|---|---|---|
| token used at wrong server | resource and audience validation | replay server A token at server B |
| malicious server registration | owner, allowlist, provenance and review | register unapproved endpoint |
| tool description changes | signed or pinned metadata digest | alter description after approval |
| argument substitution | canonical request digest | change amount before dispatch |
| prompt injection triggers tool | external deterministic policy | embed instruction in retrieved document |
| credential disclosure | brokered upstream credentials | inspect model and client context |
| duplicate side effect | replay claim plus domain idempotency | race two identical calls |
| tenant crossover | tenant-bound routing and storage | reuse IDs across two tenants |
| gateway bypass | network policy and service identity | call upstream directly |
OWASP's Agentic Security Initiative covers tool misuse, privilege abuse and agent supply-chain risks. The gateway can mitigate some of these risks, but only if it is the mandatory execution path.
Validate tokens and metadata
For HTTP transport, follow the MCP authorization specification. Fetch protected-resource metadata through controlled HTTP behavior, validate HTTPS and issuer policy, and cache with bounded staleness. Never accept an authorization server solely because an untrusted MCP server named it.
function validateMcpAccess(ctx: RequestContext) {
assertApprovedServer(ctx.serverUri);
assertTrustedIssuer(ctx.token.issuer, ctx.serverUri);
assertAudience(ctx.token, ctx.serverUri);
assertNotExpired(ctx.token);
assertScopes(ctx.token, ctx.requiredScopes);
assertTenantBinding(ctx.token, ctx.tenantId);
}
RFC 9728 also describes security considerations for protected-resource metadata. Treat metadata as security input, not harmless discovery text.
Authorize exact tool arguments
Parse the JSON-RPC request against the declared schema, reject unexpected fields where possible, normalize values and hash the full protected envelope. The envelope should include server audience, tool name, arguments, principal, agent, grant, transaction ID, nonce and expiry.
A tool called send_email may be low risk for one destination and high risk for a bulk external list. execute_sql cannot be governed safely by its name alone. Resolve domain identifiers and current state before policy returns allow.
Test approval drift:
{
"approved": { "tool": "issue_refund", "order": "9182", "amount_minor": 4500 },
"submitted": { "tool": "issue_refund", "order": "9182", "amount_minor": 45000 },
"expected": "REQUEST_DIGEST_MISMATCH"
}
Rehearse component failure
Do not give the entire gateway one failOpen switch. Define behavior by action risk and missing dependency. A public read may use a bounded-stale policy bundle. A supplier payment should stop if revocation, replay reservation or current supplier state cannot be established.
Record at least authorization result, reason code, request digest, server, tool, policy digest, trace ID, dispatch status and upstream reference. Keep tokens, secrets and raw sensitive documents out of portable evidence.
Review the MCP gateway architecture and MCP tool-call authorization for implementation detail. The live Intelliger platform overview is the relevant product path.
Intelliger's public gateway and OATI components remain developer-preview technology. This article does not claim that the reference design has passed an independent assessment in a customer production environment.
Security review questions
Is tool-list filtering a security control?
It reduces exposure and helps clients avoid accidental calls, but it is not sufficient authorization. A malicious or modified client can send tools/call directly. Enforce the same tenant, tool and argument policy in the call path and again at the protected service where practical. Test a call to a hidden tool without performing discovery first.
How should tool metadata be trusted?
Treat names, descriptions and schemas as supply-chain input. Bind admission to server identity, endpoint and reviewed metadata digest. Decide which changes require quarantine. A description-only change can still manipulate a model even when the input schema stays constant, so review semantic drift as well as structural drift.
What protects against confused deputies?
Bind caller, represented principal, tenant, target server and exact action. Never let one client present a token for another server or ask the gateway to forward its own broad service credential without downstream policy. The protected server validates audience and authenticated gateway identity, then checks the request-bound decision or its own domain policy.
How are outputs controlled?
Apply size, type and sensitivity rules to tool responses. Prevent credentials and internal errors from returning to model context. Mark untrusted content before it re-enters planning so it cannot masquerade as a system instruction. Output controls do not make the content true; maintain source and server provenance for later decisions.
Which denial events deserve alerts?
Alert on wrong-audience tokens, repeated hidden-tool calls, cross-tenant identifiers, approval digest mismatches, replay conflicts, metadata drift and direct-route attempts. A normal policy denial may be expected and useful for product feedback. Separate attack-like signals from ordinary business constraints so operators do not disable noisy controls.
What does a gateway receipt prove?
It can attest that the gateway evaluated a named request and observed a dispatch or response under a stated policy version. It cannot prove that the server had no alternate route, that an upstream response was truthful or that later business outcome completed. Preserve assurance labels and link stronger provider or system-of-record evidence when available.
Keep one malicious fixture intentionally boring. Use a valid user, approved server, ordinary tool name and plausible arguments, but change one protected destination or tenant identifier. Security demonstrations often focus on obvious injection strings while the most expensive failure is a well-formed request that crosses a business boundary. The expected result should name the failed constraint and prove that the upstream received no call.
Run the same fixture against every gateway replica and the upstream service. One permissive region or forgotten direct endpoint is enough to make the policy optional. Preserve the request ID and denial evidence from each path.