The MCP gateway market has developed quickly. Microsoft, IBM, Lunar, Stacklok and Kong all offer serious ways to place identity, policy, audit and transport controls between an AI client and MCP servers. That is good news for buyers. It also makes a vague claim such as “enterprise authentication supported” much less useful as a differentiator.
Authentication answers who arrived at the gateway. Enterprise authorisation ultimately depends on who arrives at the resource.
The comparison question that matters
Imagine Alice asks Copilot to read a protected file. There are several valid architectures:
- the gateway can approve Alice, then use a shared workload or service identity;
- it can pass Alice’s identity claims to an upstream server that understands them;
- it can exchange Alice’s token for another user-scoped token understood by the backend;
- it can provision an isolated server or credential context for Alice;
- or access to the protected resource can remain bound to Alice’s actual enterprise identity and existing permissions.
These are not interchangeable. Each can be a sensible design for a particular workload. The procurement mistake is assuming that because the first login was Alice, every later access is automatically Alice too.
Current enterprise MCP gateway approaches
The table below summarises publicly documented approaches as of August 2026. It is deliberately focused on identity and existing MCP reuse rather than attempting to score every gateway feature.
| Gateway / platform | Existing STDIO MCP | Enterprise identity | Publicly documented downstream pattern |
|---|---|---|---|
| Microsoft MCP Gateway | Yes — local STDIO servers can be proxied remotely | Microsoft Entra roles/authentication | Optional workload identity for upstream Azure access; Microsoft documents that this identity is shared and is not owned by the requester. |
| IBM ContextForge | Yes — STDIO can be exposed through Streamable HTTP | SSO/OIDC and user context | Original user identity can be propagated as HTTP headers or MCP metadata; OAuth token exchange is also supported for user-scoped upstream tokens. |
| Lunar MCPX | Yes — local MCP tools can run as subprocesses | Enterprise IdPs including Microsoft Entra ID | Identity-aware gateway policy, profiles and dedicated gateway instances per identity; downstream servers use their supported OAuth, token or managed-secret mechanisms. |
| Stacklok / ToolHive | Yes — STDIO servers can be exposed through an HTTP proxy | OIDC authentication plus gateway authorisation | Gateway policy can authorise the caller; documented patterns include token exchange and delegated credentials for downstream systems. |
| Kong AI Gateway | Not the primary documented pattern in the material reviewed | Enterprise IdP and gateway policy | Depending on the upstream, Kong documents user-token passthrough or swapping the authenticated user token for a credential the backend already accepts. |
| Steward | Yes — compatible tool-oriented STDIO MCP servers can remain unchanged | Microsoft Entra ID | Protected-resource access remains bound to the actual requesting user identity, without substituting another backend identity; the user’s existing permissions remain authoritative. |
Product capabilities change quickly. This comparison reflects public vendor documentation reviewed on 24 August 2026; always verify the behaviour required by your own security model.
This is not a good-versus-bad comparison
A workload identity is exactly right for a service that should act as an application. OAuth token exchange is often the strongest model for a modern API. Gateway-level RBAC can provide excellent control over which MCP tools a person may invoke. Per-user isolated runtimes can make credential handling and tenancy much cleaner.
The identity-preserving model becomes especially valuable when the MCP tool reaches resources that already enforce mature user-specific security — ordinary network files, existing servers, databases using integrated OS authentication and other enterprise resources where Alice and Bob are intentionally entitled to different things.
If Alice asks Copilot to read a protected file, Alice reads the file. If she asks it to query a database using integrated OS authentication, the database access occurs as Alice. The protected resource authorises Alice first; the AI receives only the information returned by the MCP operation she was authorised to perform. It does not become a new principal with a wider view of the estate.
Six questions to put to any MCP gateway vendor
- What identity does the protected resource actually see? Do not stop at the identity visible to the gateway.
- Does access stay bound to the actual user identity? If Alice loses ordinary access tomorrow, does the AI path lose it too without a second permission change?
- Does the backend require a broad shared account? If so, understand exactly what compensating authorisation layer replaces native user access.
- Must existing MCP servers be modified? A gateway that requires every tool to learn a new identity protocol moves security complexity into every backend.
- Where is authorisation enforced? At tool selection, at the backend resource, or both?
- Can the design prove who actually accessed the resource? Gateway audit and native resource audit are not always the same thing.
Why unchanged STDIO servers matter
STDIO is not a toy transport. It is an intentionally simple boundary that keeps many MCP tools local and narrow. When enterprise AI needs remote access, rewriting each of those tools as a network-facing service can multiply authentication code, deployment surfaces and security reviews.
A gateway that can secure remote access while leaving compatible tool-oriented MCP servers unchanged creates a useful separation of concerns: one place owns the enterprise boundary, while each MCP server keeps owning only its business capability.
That qualification matters. A conventional tool server built around request/response operations is a natural fit; a server that depends on client-side sampling, elicitation, subscriptions or other server-initiated interactions may require adaptation rather than transparent proxying.
Where Steward fits
Steward is aimed at the case where an organisation wants approved remote AI clients to use compatible tool-oriented STDIO MCP servers without surrendering the identity model already protecting its configured enterprise resources.
That makes the proposition intentionally narrow: Steward is not trying to replace every API gateway, identity platform or MCP control plane. Its job is to make remote MCP access secure while keeping protected-resource access bound to the actual requesting user identity all the way through, without substituting another backend identity.
Vendor documentation consulted
- Microsoft MCP Gateway — proxying local and remote MCP servers and Entra application roles / workload identity.
- IBM ContextForge — transport translation and identity propagation.
- Lunar MCPX — centralized user management and architecture.
- Stacklok / ToolHive — authentication and authorization.
- Kong — secure external MCP gateway patterns.
The defining question is what happens after authentication, when the AI reaches the resource the user actually cares about.