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.

Open checklist View questionnaire items Review MCP basics Map MCP risks

Gateway review snapshot20 point score

GatewayPolicy enforcement and audit capture

ProxyRouting is not proof of control

Score0 to 20 production-readiness triage

EvidenceRBAC, token flow, logs, tenant isolation

What this gateway checklist produces

Use it to turn MCP gateway claims into reviewable evidence before customer questionnaires.

Gateway vs proxy clarityA short distinction that prevents teams from treating basic routing as complete security evidence.

20-point checklistA scored review across identity, RBAC, token handling, approvals, audit logs, isolation, secrets, and fail-closed behavior.

Customer questionsReusable questionnaire prompts for AI vendor security, agent governance, and third-party risk review.

Evidence trailOfficial MCP references plus concrete records to keep for customer and internal review.

Keep the gateway page tied to customer evidence

Direct answer: an MCP gateway is useful in a security review only when it can prove identity, permissions, token handling, approvals, audit logs, tenant boundaries, and fail-closed behavior.

mcp gateway securityUse this page when the buyer asks whether an MCP gateway actually controls agent-to-tool access, not when they only need MCP basics.

customer questionnaire evidenceAnswer with reviewable artifacts: identity map, tool allowlist, OAuth scope sheet, token custody note, approval policy, and audit logs.

agent tool access reviewKeep the focus on who can call tools, what data can move, what is logged, and how unsafe actions are blocked.

Do not expand this page into generic MCP theoryRoute broad MCP concepts to the best-practices page and keep this page focused on gateway controls and evidence.

Route broad MCP basics Add evidence to AI vendor questionnaire

What customer reviewers expect from an MCP gateway

Direct answer: a gateway only helps the security review when it produces inspectable evidence for identity, permissions, tokens, approvals, logs, and isolation.

What reviewers wantThey want proof of who or what can call tools, which data can move, what scopes exist, how tokens are revoked, and where audit logs live.

What is not enoughA gateway diagram, proxy name, or OAuth claim is not enough unless policies, approvals, logs, tenant boundaries, and failure behavior are reviewable.

Minimum evidence packetKeep an identity map, tool allowlist, OAuth scope sheet, token custody note, approval policy, audit-log sample, and emergency disable runbook.

Where this fitsUse this page for MCP gateway controls; use the broader MCP security page for risks and the AI vendor template for customer questionnaire rows.

Add to AI vendor questionnaire Store reusable answers

MCP gateway vs MCP proxy

Use this distinction before treating a routing layer as customer-ready security evidence.

MCP gatewayCentral policy layer that can broker MCP traffic, enforce access rules, collect audit logs, and give reviewers one place to inspect agent-to-tool access.

MCP proxyA pass-through or routing layer that may help connect clients and servers, but does not automatically prove RBAC, approvals, tenant isolation, or audit evidence.

Security review boundaryTreat the gateway as evidence only when policies, logs, ownership, and failure behavior are documented and testable.

Questionnaire angleCustomers are not asking for MCP theory. They want to know who can call tools, what data can move, what gets logged, and how unsafe actions are blocked.

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

MCP safe-to-connect evidence matrix

Use this matrix when a reviewer asks whether an MCP server, gateway, or connected tool is safe enough for customer or production data.

Where is data going?List every MCP server, external API, model provider, log sink, and storage path that can receive prompts, tool inputs, outputs, or metadata.

What can the tool do?Separate read, write, export, admin, delete, code execution, browser action, and production-change permissions before approval.

Could prompt injection trigger it?Show how untrusted content, retrieved documents, tool descriptions, and tool output are handled before sensitive actions run.

Can access be revoked quickly?Document token custody, refresh-token storage, scope reduction, emergency disablement, and the owner who can revoke access.

What evidence can a reviewer inspect?Keep tool allowlists, denied-action logs, policy decisions, approval records, change reviews, and incident investigation logs.

Review MCP risks Store MCP answers

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.

Token lifecycle driftAgents can run longer than a normal user session, so reviewers need to see refresh, expiry, and revocation paths instead of assuming OAuth solved them.

Per-action policyA read or write scope does not decide whether this exact tool call should be allowed right now. Keep runtime policy gates and approval rules visible.

Authorization evidenceStore policy decisions, denied actions, scope sheets, and gateway logs so customers can review the control path after an incident or questionnaire request.

Agentic identity gateway review

Use this when a customer asks how the gateway controls agentic identity, non-human identity, or endpoint-like AI agent access.

Agent or workflowName the agent, automation, MCP client, workflow owner, and business purpose before it receives gateway access.

Credential modelRecord whether the agent uses end-user OAuth, workload identity, service credentials, delegated scopes, or gateway-issued tokens.

Policy boundaryMap the allowed tools, denied actions, data classes, environments, tenant boundaries, and approval requirements.

Endpoint-like monitoringCapture runtime, network, file, browser, code execution, SaaS, and production access events when the agent can behave like an unmanaged endpoint.

Revocation and disablementKeep a tested path to revoke tokens, disable gateway routes, block tools, rotate credentials, and notify owners.

Add agent access questions Map evidence

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.

Store EU AI Act answers + owners Add AI vendor evidence fields

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.

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.

Request a shortlist