MCP Gateway Buyer's Guide: Access Control, SOC 2 and Tenancy
An MCP gateway demo usually starts with a client listing tools and making a successful call. That’s useful, but it leaves the harder purchasing questions unanswered. Who can call the same tool with different credentials? What happens after access is revoked? Who can read the resulting logs?
Those questions matter once several teams share a gateway, especially when tools can change production data. A product can route MCP traffic correctly and still leave you with substantial authorization and operational work.
This guide compares six options, then explains how to assess access controls, SOC 2 scope and tenant isolation. The comparison uses public documentation reviewed on October 6, 2026. It isn’t a hands-on benchmark or a review of vendors’ private audit reports.
ASCENDING publishes this blog and builds Jarvis Registry, an open source project included below. We describe its limitations alongside the other options.
Proxy and gateway names won’t tell you where policy is enforced
The distinction is less tidy than product comparisons suggest. A transport bridge can expose a local stdio server over HTTP. Another product called a proxy may authenticate users, filter tool lists and reject individual calls.
Kong is an example: its AI MCP Proxy documentation describes tool-level access rules and audit logging. Calling it a proxy doesn’t make those controls less useful.
For procurement, identify which component checks each request and which component owns the upstream credential. If authorization lives in the MCP server, evaluate that arrangement explicitly. You may not need a second policy engine at the gateway, but you do need a consistent way to administer and verify access.
Check tool execution separately from tool discovery
Suppose a service-desk server exposes search_tickets and close_ticket. A support analyst should be able to search; a supervisor may also close tickets.
Sign in as both users and inspect tools/list. Then, as the analyst, submit a direct call to close_ticket. A hidden tool must still be denied when called by name. Filtering the list only changes what the client can discover.
Next, remove the supervisor’s permission and repeat the call using an existing session. Measure how long the change takes to apply. Cached policy, group claims and token lifetimes can all affect revocation.
Ask the vendor to show the record for each attempt, including the denied one. Useful fields include the authenticated subject, client or workload identity, server, tool, policy decision, timestamp and correlation ID. Record credential identifiers when needed; never put bearer tokens or secret values in the audit trail.
Ask how credentials cross the gateway
A gateway may use a service account, maintain a user’s upstream OAuth grant, or exchange a token for one accepted by the destination. Each approach has consequences.
A service account is simpler to operate, but the downstream system may see every user as that account. Per-user grants preserve downstream permissions but add consent, refresh and revocation work. Token exchange depends on the identity systems involved.
The MCP security guidance prohibits accepting tokens intended for another resource and passing them through without the required validation. It doesn’t require every gateway to implement RFC 8693 token exchange.
For each backend, document the token audience, scopes, owner and revocation path. Also establish where user identity is lost, if a shared upstream credential replaces it.
Include protocol compatibility in the evaluation
The 2026-07-28 Streamable HTTP specification adds request metadata headers, including Mcp-Method and, for named operations, Mcp-Name. These make routing and inspection easier.
They don’t authenticate the caller. Components that inspect these headers also need to handle encoding and header/body validation correctly. Older clients may use different initialization and session behavior.
Test the actual client and server versions you intend to deploy. A vendor’s claim to support Streamable HTTP doesn’t establish compatibility with every MCP revision or optional capability.
Six MCP gateways worth comparing
Start with a shortlist your team can operate. If you already manage an API gateway, extending it may cost less than introducing another platform. If your servers run across several clouds, the existing gateway may impose awkward network or identity dependencies.
The table highlights a reason to evaluate each option and a limitation to investigate. It doesn’t rank them.
| Option | Deployment and documented controls | What to investigate |
|---|---|---|
| Amazon Bedrock AgentCore Gateway | Managed AWS service for connecting agents to tools and APIs, with authentication and policy controls | Backend connectivity, identity mapping and logging configuration; the gateway remains an AWS service |
| Azure API Management | Exposes REST operations as tools or fronts existing MCP servers; integrates with APIM policies and monitoring | Microsoft documents server-wide policy scope and no MCP support in APIM workspaces; check required resources and prompts support too |
| Kong AI MCP Proxy | Extends Kong with MCP routing, tool ACLs and optional audit logging | AI Gateway Enterprise licensing, exact release behavior and compatibility with your clients |
| TrueFoundry MCP Gateway | SaaS and self-hosted options, with identity integration and server/tool access controls | Which control-plane services stay vendor-hosted, and which audit and isolation commitments apply to your deployment |
| IBM ContextForge | Self-hosted gateway with team membership, roles and private/team/public resource visibility | Default visibility, administrator privileges, upgrades and operating responsibility |
| Jarvis Registry | ASCENDING’s self-hosted registry and gateway, with identity integration, tool permissions and OpenTelemetry | Deployment support, audit exports and tenant boundaries; see the Jarvis section below |
Two details deserve attention during a trial. AWS says Gateway CloudTrail data events must be enabled explicitly. A successful call won’t necessarily produce the event you expect with default settings.
Kong’s current documentation says ACL denials return HTTP 403 starting in AI Gateway 3.14. Earlier releases returned a JSON-RPC invalid-parameters error. If monitoring rules depend on status codes, test the release you’re buying.
For a broader test plan, use our MCP gateway evaluation criteria. If you’re replacing Docker’s local gateway, the Docker alternatives guide covers the runtime and migration questions.
Read the SOC 2 scope before comparing badges
A SOC 2 report describes an examination of controls for a defined system. Its usefulness depends on whether that system includes the service and operating model you’re buying.
AWS lists Amazon Bedrock AgentCore on its SOC services-in-scope page. Microsoft’s Azure SOC 2 documentation directs customers to reports and service-scope material. These are starting points for review; neither replaces reading the applicable report.
Deployment matters here. With SaaS, the provider operates more of the system. With a self-hosted gateway, your team usually owns deployment, network access, identity configuration, backups and log retention.
TrueFoundry makes that distinction in its SaaS security documentation: its SaaS compliance coverage doesn’t transfer automatically to a customer-hosted deployment.
A vendor report can still provide relevant evidence about software development, support or a hosted control plane. The mistake is assuming that evidence also attests to how your own installation is configured and operated.
What to request from the vendor
Ask for the report and read these parts with security or GRC:
- System description: the services, infrastructure, regions and operating responsibilities included in the examination.
- Report type and period: Type 1 addresses controls at a point in time; Type 2 also evaluates operation over a period.
- Exceptions and exclusions: which controls had findings, and which dependencies fall outside the examination.
- Customer responsibilities: controls you must implement for the service to work as described.
- Changes since the period ended: a bridge letter can provide management’s update, but doesn’t extend the auditor’s testing period.
Decide which trust services categories your review requires. A report covering security and availability doesn’t necessarily cover privacy. For a new gateway feature, ask whether it was included during the audit period.
HIPAA and other regulated workloads need their own review
If tool calls contain electronic protected health information, trace where that information travels and where it is stored. Include gateway logs, traces, backups and support access.
HHS cloud guidance explains when a cloud provider is a business associate and requires a business associate agreement. A signed BAA is part of the arrangement; it doesn’t establish that your configuration meets every HIPAA requirement.
For FedRAMP or other requirements, verify the applicable service, deployment and authorization boundary. A company’s general compliance page isn’t enough to establish coverage for a specific MCP service.
Define the tenant boundary before testing multi-tenancy
An internal department, an external customer and a production environment need different kinds of separation. Write down which one you mean by tenant.
Team-based permissions may be sufficient for departments that share administrators. A SaaS product serving unrelated customers usually needs stronger guarantees around credentials, logs and administration. Separate deployments may simplify that boundary, but they add upgrades, monitoring and configuration work.
ContextForge documents team-scoped resources. TrueFoundry documents tenant-scoped queries, secrets and configuration for its SaaS service. Those descriptions are useful, but test the boundaries that matter to your application.
| Boundary | A practical check |
|---|---|
| Catalog and execution | Tenant A can’t discover or invoke tenant B’s private tool, including by a known tool name or identifier |
| Credentials | Calls from A never use B’s upstream account or token |
| Administration | A’s administrator can’t read or change B’s policies, users or server definitions |
| Logs and exports | A’s reviewers can’t retrieve B’s events through the UI, API or exported files |
| Caches | A response generated for one user or tenant isn’t reused for an unauthorized caller |
| Capacity | A burst from A doesn’t consume B’s reserved quota or make B’s service unavailable beyond the agreed limits |
| Residency and retention | Each tenant’s credentials, logs and backups follow its agreed storage and deletion rules |
Don’t assume a separate subdomain implies a separate database or encryption boundary. Conversely, shared infrastructure can provide effective isolation when authorization and data partitioning are correctly implemented. Ask for the design, then test cross-tenant access.
Run a trial that includes failure
Use one read tool and one write tool from a real workflow, preferably against a test backend. Include a user who should have access and one who shouldn’t.
A useful trial produces evidence for five situations:
- An authorized call succeeds with the intended upstream permissions.
- A direct call to a forbidden tool fails, even if the client knows its name.
- Revocation takes effect within the agreed interval for an existing session.
- A backend timeout or expired credential produces an understandable error and a traceable event.
- An attempt to bypass the gateway fails wherever your architecture requires all calls to pass through it.
Also export the catalog and policy configuration. Find out what it would take to leave: which formats are portable, which credentials require reauthorization, and which parts need rebuilding.
Before sizing the trial, inventory the MCP servers already in use. That will reveal local stdio servers, remote endpoints and client versions a polished demo may never exercise.
Where Jarvis Registry fits
Jarvis Registry combines a registry and MCP gateway in an Apache 2.0 project built and maintained by ASCENDING. It is a candidate for teams that want to operate that layer themselves.
Our MCP gateway product page describes identity federation, tool-level permissions, token exchange and per-call telemetry. Those are product claims to validate in your trial. Ask for a sample denial record, the supported protocol revisions and the deployment documentation for your environment.
The public README describes SSE and Streamable HTTP connectivity. If you depend on local stdio servers, establish how they will be hosted and exposed before choosing it. The gateway’s access controls don’t replace the security controls around those server processes.
The public materials reviewed for this guide don’t establish a SOC 2 report for Jarvis Registry or a complete customer-tenant isolation contract. Ask us for evidence if either is a requirement. Running it yourself also means assigning responsibility for upgrades, availability and audit retention.
References
- MCP Streamable HTTP specification, revision 2026-07-28
- MCP Security Best Practices
- AWS services in SOC scope
- Azure SOC 2 Type 2 documentation
- HHS guidance on HIPAA and cloud computing
Documentation reviewed October 6, 2026. Product links in the comparison table lead to the sources used for that option.
MCP gateway procurement questions
What is the difference between an MCP proxy and an MCP gateway?
The names overlap. Some proxies only bridge transports; others authenticate callers and enforce tool permissions. Compare the actual controls: authentication, authorization on tool calls, upstream credential handling and audit records. Token exchange is one credential strategy, not a requirement for using the gateway label.
Which MCP gateway should an enterprise evaluate first?
Start with the platform you already operate, provided its controls meet your requirements. AgentCore Gateway is an AWS option; API Management is an Azure option; Kong has an AI MCP Proxy plugin. Self-hosted candidates include TrueFoundry, IBM ContextForge and Jarvis Registry. ASCENDING builds Jarvis Registry and publishes this guide.
Does a vendor's SOC 2 report cover a self-hosted gateway?
It doesn't automatically cover your installation. Read the report's system description and responsibility boundaries. A vendor's development or support controls may be relevant, while your deployment, access rules, logging and operations remain your responsibility.
What should we test for multi-tenant use?
Test catalog visibility, tool execution, credential selection, administration, logs and caches with accounts from two tenants. Quotas should also prevent one tenant from consuming the other's allocation. Team labels or separate subdomains alone don't establish all of these boundaries.
What does HIPAA support mean for an MCP gateway?
It depends on the deployment and the vendor's role in handling electronic protected health information. When the provider acts as a business associate, confirm a business associate agreement covers the relevant service. You still need to assess access, logging, retention and your own operating controls.
