MCP gateway security checklist
Evaluate MCP gateways for AI vendor security reviews, customer questionnaires, and agent governance. Focus on authentication, RBAC, OAuth scopes, token custody, approvals, audit logs, tenant isolation, secrets, and prompt injection.
What this gateway checklist produces
Use it to turn MCP gateway claims into reviewable evidence before customer questionnaires.
MCP gateway vs MCP proxy
Use this distinction before treating a routing layer as customer-ready security evidence.
OAuth scope sheet (agent tool access evidence)
For AI agent vendors, reviewers often care more about the integration scope sheet than a long questionnaire. If you can show minimum scopes, refresh token custody, and revocation drills, buyers can trust your controls faster.
| Integration | Minimum scopes | Credential type | Where stored | Revocation evidence |
|---|---|---|---|---|
| Google Workspace | gmail.readonly (only the mailbox labels needed) | OAuth refresh token | Secrets manager + least-privileged service | Doc + drill log |
| Slack | channels:history for specific workspaces | OAuth refresh token | Secrets manager + allowlisted workspace IDs | Doc + drill log |
| Salesforce | api for approved objects only | OAuth refresh token | Secrets manager + object allowlist | Doc + drill log |
| Internal database | read-only reporting role | Short-lived token | DB IAM + mTLS | Runbook + break-glass owner |
Why OAuth alone is not enough for agents
Production MCP reviews increasingly ask for a second layer beyond authentication: runtime authorization, token lifecycle handling, and evidence of what was allowed when.
MCP gateway security checklist
Score each item 0, 1, or 2 based on whether the control is missing, partial, or reviewable.
| Area | Security check | Evidence to keep |
|---|---|---|
| Authentication | Require explicit user or workload identity before a client can reach gateway-controlled MCP tools. | Identity provider config, allowed client list, token lifetime, and revocation path. |
| RBAC | Map teams, agents, tools, environments, and data classes to least-privilege access policies. | Role matrix, tool allowlist, deny rules, and exception owner. |
| OAuth scopes | Maintain an integration scope sheet that shows minimum OAuth scopes per tool and blocks scope creep. | Integration list, minimum scopes, justification, approval owner, and re-review cadence. |
| Token passthrough | Document whether the gateway forwards end-user tokens, exchanges tokens, or uses service credentials. | Token flow diagram, scopes, storage rules, and rotation process. |
| Token custody | Define where refresh tokens and service credentials are stored, who can use them, and how revocation is tested. | Secrets manager policy, token access logs, revocation runbook, and a recent revocation drill record. |
| Tool approval | Require approval before high-impact tools can export data, write records, change admin settings, or call external systems. | Approval policy, reviewer role, sample approval log, and emergency disable process. |
| Audit logs | Log tool calls, denied actions, policy decisions, config changes, token use, and gateway errors. | SIEM destination, retention period, event schema, and incident-response runbook. |
| Tenant isolation | Prevent cross-tenant tool discovery, data access, log leakage, prompt context sharing, and policy inheritance mistakes. | Tenant boundary design, test results, and isolation controls. |
| Secret handling | Keep API keys out of prompts, tool descriptions, local config, logs, and agent-visible context. | Secrets manager policy, redaction rules, and access review. |
| Prompt injection | Treat retrieved content and tool output as untrusted input before the gateway allows sensitive follow-up actions. | Filtering rules, action gating, allowlists, and human review path. |
| Tool poisoning | Review tool names, descriptions, schemas, package provenance, and server updates before they are exposed through the gateway. | Change review, package source, version pinning, and rollback plan. |
| Fail closed | Define what happens when policy lookup, logging, identity verification, or approval services are unavailable. | Failure-mode test, default deny rule, alert path, and business exception process. |
Risk scoring
The score is a triage tool for vendor review and internal approval, not a compliance certification.
0-8: Do not approve
The gateway is routing traffic, but the reviewable controls are missing or mostly assumed.
9-15: Limited pilot
Some evidence exists, but sensitive tools or customer data should stay restricted until gaps close.
16-20: Production candidate
Core controls are documented, owned, monitored, and ready for customer security review.
AI governance evidence (human oversight + logs)
If a customer questionnaire asks for AI governance, ADMT controls, or EU AI Act readiness, reviewers usually expect evidence for oversight, auditability, and emergency disable paths.
- Human oversight: which actions require approval, who can override, and how decisions are recorded.
- Audit logging: tool calls, denied actions, policy decisions, and admin changes with retention and access controls.
- Emergency disable: token revocation runbook, last drill date, and fail-closed behavior.
- Data flow: what the gateway can send to tools/external systems, with scope minimization and tenant boundaries.
- Vendor/subprocessor evidence: which external services touch prompts, tool input/output, or logs.
Questionnaire items
Turn gateway review into reusable answer-library questions instead of one-off AI security claims.
| Customer question | Answer should include |
|---|---|
| How do you authenticate AI agents and users before they can access MCP tools? | Describe identity provider integration, token lifetime, client registration, and revocation. |
| How are MCP tool permissions approved and enforced? | Explain RBAC, tool allowlists, high-impact action approval, and default-deny behavior. |
| Can you provide an OAuth scope sheet for every integration the agent can access? | List each integration, the minimum scopes, where refresh tokens live, and how scope changes are reviewed. |
| Do you pass end-user tokens through the MCP gateway? | State whether tokens are passed through, exchanged, scoped, stored, rotated, and logged. |
| How do you revoke agent access and credentials quickly? | Describe token revocation paths, emergency disable switches, refresh token rotation, and a recent test or drill. |
| How do you prevent prompt injection from triggering unsafe tool calls? | Describe untrusted content handling, policy checks, sensitive action gating, and human approval. |
| What audit logs are available for MCP gateway activity? | List tool calls, denied actions, policy decisions, config changes, retention, and SIEM destination. |
| How do you maintain tenant isolation across MCP clients and servers? | Document data boundaries, log separation, tool discovery limits, and testing evidence. |
Evidence and source trail
These references and implementation docs support the security review areas above.
NSA MCP security design considerations
ReferenceNSA's May 2026 MCP guidance supports asking for access control, token lifecycle, approval, gateway, and context-sharing evidence before production use.
Docker MCP Gateway documentation
ReferenceDocker's MCP Gateway docs describe a gateway running MCP servers in containers, injecting credentials, and applying security restrictions before forwarding requests.
Traefik MCP gateway best practices
ReferenceTraefik's MCP gateway guidance highlights upstream controls like authN/authZ before prompts reach the LLM, PII filtering/redaction, jailbreak detection, and observability for audit trails.
OWASP MCP Tool Poisoning
ReferenceOWASP's MCP tool poisoning entry supports reviewing tool metadata, schema changes, hidden instructions, and rug-pull style changes.
MCP authorization specification
ReferenceThe official MCP authorization specification describes authorization responsibilities for HTTP-based MCP servers and OAuth-based flows.
MCP security best practices
ReferenceThe official guidance covers consent, authorization, confused-deputy risks, token passthrough, and session hijacking considerations.
MCP client security
ReferenceClient guidance reinforces explicit user consent, tool-call authorization, and clear control over what agents can access.
MCP gateway security FAQ
Short answers for teams adding gateway review to AI security questionnaires.
What is an MCP gateway?
An MCP gateway is a control layer that can sit between MCP clients and MCP servers to centralize policy, routing, approvals, logging, and enforcement for agent-to-tool access.
Is an MCP gateway the same as an MCP proxy?
Not always. A proxy may primarily forward traffic, while a security-oriented gateway should provide reviewable controls such as identity, RBAC, approval rules, tenant isolation, and audit logs.
Why do buyers ask for OAuth scopes and token revocation evidence?
Because paperwork does not show real access. The fastest way to understand agent risk is to see which integrations exist, the minimum OAuth scopes, where refresh tokens are stored, and how quickly access can be revoked.
Why does MCP gateway security belong in vendor questionnaires?
Customers reviewing AI-enabled vendors need evidence for how agents access tools, what credentials are used, how sensitive actions are approved, and whether logs exist for incident review.
Should teams buy an MCP gateway before writing answers?
No. Start by documenting current tool access, identity, approvals, logs, and risks. That evidence will show whether a gateway is needed and which controls it must provide.
Need a shortlist for your workflow?
Send the formats you receive, your current answer-library setup, and whether you need portal support. We will use those signals to prioritize the next comparison updates.