How to choose an MCP gateway without buying the wrong category

At a glance

What this is: This is a category guide for choosing an MCP gateway, and its central finding is that gateway design must match the governance problem, not just the protocol.

Why it matters: It matters because MCP is becoming part of broader AI governance, so IAM, NHI, and platform teams need to judge whether identity, audit, and policy controls survive the gateway architecture they choose.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Stacklok's guide to choosing the right MCP gateway category

Context

MCP gateway selection is really an identity and control-plane decision. The protocol standardises how AI agents connect to tools, but the gateway category determines whether identity propagation, policy enforcement, auditability, and supply-chain trust remain coherent once agent traffic moves into production.

The first mistake teams make is evaluating MCP support as if it were a single feature. In practice, the gateway may be a point solution, a platform add-on, an API gateway extension, or an integrated AI control plane, and each model creates different governance trade-offs for NHI, autonomous agent, and human-centric oversight.

For practitioners, the central question is whether the gateway binds requests to real identity, preserves audit context across LLM and MCP traffic, and supports the deployment constraints of regulated environments. That is why category fit matters more than a long checklist of product capabilities.

Key questions

Q: How should security teams choose between different MCP gateway categories?

A: Start with governance scope, deployment constraints, and identity model rather than feature count. A point solution, platform add-on, API extension, and integrated control plane all create different audit and policy outcomes. The best choice is the one that preserves identity propagation, supports your hosting model, and keeps tool approval inside the same control boundary as access decisions.

Q: Why does identity binding matter so much for MCP traffic?

A: Because key-based access tells you a request was authenticated, but not whether it can be cleanly attributed, recertified, or revoked in lifecycle terms. Claim-centric identity ties the call to a real user or agent and gives security teams evidence that survives audit, incident response, and offboarding.

Q: What breaks when MCP governance is added after deployment?

A: Retrofitting control usually means unwinding over-broad credentials, rebuilding approval logic, and rediscovering where sensitive data can flow. By then, connector decisions are already embedded in operations, which makes remediation slower, more disruptive, and harder to evidence for auditors and counsel.

Q: Who should own MCP access governance in an enterprise?

A: Ownership should sit with identity and security teams, not only application developers, because MCP connects user intent to privileged execution. The governing team needs authority over policy design, review cadence, and audit evidence. That keeps MCP aligned with enterprise authorization standards rather than ad hoc server behaviour.

Technical breakdown

MCP gateway categories change the governance model

An MCP gateway is not one architecture with optional features. Point solutions optimise for MCP protocol depth, platform add-ons inherit the parent platform’s model, API gateway extensions adapt existing proxy and policy logic, and integrated AI control planes try to govern LLM and MCP traffic together. Those differences matter because they decide where identity is anchored, how policy is enforced, and whether the audit trail reflects agent activity or just transport events. If the gateway cannot express the right identity model, governance becomes an afterthought instead of an architectural property.

Practical implication: Choose the category before scoring features, because the category determines whether identity, audit, and policy can be enforced end to end.

Identity binding is the real test of MCP governance

The article draws a sharp line between key-centric and claim-centric identity. A key-centric model uses virtual API keys or team keys, which is operationally easy but weak for lifecycle governance, attribution, and revocation. A claim-centric model binds each LLM or MCP request to a real user or named agent through the IdP, which creates stronger provenance and accountability. For NHI governance, that difference is fundamental: a credential may authenticate a call, but only identity-bound context lets security and compliance trace who or what actually acted.

Practical implication: Prioritise gateways that propagate real identity, not just API credentials, so revocation and audit follow the actor rather than the key.

Supply-chain controls now sit inside the access path

MCP governance is no longer only about tool access. Because approved servers become execution targets for agents, the gateway must also enforce provenance, registry approval, and runtime restrictions against unapproved servers. That puts signed artifacts, curated registries, and verification workflows inside the same control path as authorisation. In identity terms, the server itself becomes a governed dependency, not a passive destination. If provenance is weak, the gateway can still route traffic to untrusted tooling even when access control looks correct on paper.

Practical implication: Treat server provenance as part of access governance, and require registry approval and verification before any MCP server is reachable.

NHI Mgmt Group analysis

Category choice is now an identity governance decision, not a procurement detail. The article shows that MCP gateway models behave differently because identity, audit, and policy are distributed differently across the stack. Point solutions, platform add-ons, API extensions, and integrated control planes each expose a different governance surface, so teams that compare them as if they were interchangeable will miss the real control trade-offs. The practical conclusion is that category fit determines whether AI governance can be enforced as a system property or only as a patchwork of add-ons.

Claim-centric identity is the dividing line between governable and ungovernable MCP traffic. A key-centric model may move traffic, but it breaks the lifecycle logic that IAM and NHI programmes depend on because access cannot cleanly inherit employment, role, or agent context. A claim-centric model is harder to implement, but it aligns MCP requests with real identity and produces audit evidence that survives investigation and recertification. The implication is that gateway selection should be anchored in identity propagation, not transport compatibility.

The named concept here is identity-bound AI control plane: a gateway design where LLM calls, MCP tool calls, and policy enforcement all share one identity and audit model. That pattern matters because production AI systems do not separate model calls from tool calls in the way legacy infrastructure does. When security teams split them across separate products, they inherit fragmented budgets, fragmented logs, and fragmented accountability. Practitioners should treat unified control as a governance requirement, not a convenience.

Supply-chain provenance is becoming part of access governance for AI agents. If an MCP gateway can invoke only approved servers, then server registry hygiene, signed artifacts, and provenance verification become the equivalent of access reviews for tooling. That shifts the centre of gravity from network mediation to trust establishment. The consequence is that platform and security teams must evaluate whether the gateway can prove which tools are authorised, who approved them, and whether runtime invocation stays inside that approval boundary.

The market is moving toward consolidation around AI control planes, but consolidation does not remove architectural risk. Integrated platforms can reduce tool sprawl and simplify audit, yet they also force buyers to test whether LLM governance and MCP governance are equally mature. The field is heading toward shared policy engines, shared identity, and shared audit streams, and that will reward organisations that can define governance requirements before platform standardisation hardens around the wrong model. The practitioner takeaway is to demand depth in both layers, not just the promise of one pane of glass.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, which shows how often lifecycle control still lags behind access creation.
• For a deeper lifecycle lens, the Ultimate Guide to NHIs , 2025 Outlook and Predictions shows how governance pressure will intensify as non-human estates keep expanding.

What this signals

Identity-bound AI control plane: MCP governance is becoming a proxy for broader AI identity maturity. Teams that cannot bind requests to real user or agent identity will struggle to prove accountability once tool traffic, model traffic, and approval chains are separated across platforms.

The practical signal for IAM and platform teams is to expect more pressure to unify audit, spend, and access controls under one policy layer. That is consistent with broader NHI growth, and it means gateway selection should be treated as an identity architecture decision rather than a networking purchase.

Regulated environments will increasingly reject designs that depend on loosely attributed keys or opaque upstream tooling. As AI traffic expands, lifecycle control, provenance verification, and real identity propagation become part of the minimum control set, not advanced hardening.

For practitioners

• Classify the gateway before comparing features Decide whether you are evaluating a point solution, platform add-on, API gateway extension, or integrated AI control plane. Map that category to your deployment, identity, and audit requirements before running a feature scorecard.
• Require claim-centric identity propagation Verify that every LLM and MCP request carries real user or named-agent identity from your IdP. Reject designs that only surface API keys or team keys in the audit trail, because those credentials do not support lifecycle review or precise revocation.
• Make server provenance a gating control Insist on curated server registries, signed artifacts, and runtime blocking of unapproved MCP servers. Treat server approval as part of the authorisation workflow, not as a separate operational checklist.
• Check whether prompt and tool traffic share one policy model Confirm that the gateway governs LLM calls and MCP tool calls together, with one audit stream and one policy engine. If those paths split, you will inherit blind spots in spend attribution, data protection, and investigation.

Key takeaways

• MCP gateway choice is fundamentally a governance decision because the category determines how identity, audit, and policy behave in production.
• Claim-centric identity is the most meaningful dividing line in the article, because it lets MCP requests remain attributable across lifecycle, audit, and incident workflows.
• Practitioners should evaluate server provenance, deployment model, and shared policy coverage before they compare feature matrices.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Claim-Centric Identity: Claim-centric identity binds a request to identity assertions from an IdP rather than to a reusable shared key. For AI and non-human access, this creates stronger attribution, better lifecycle control, and clearer audit evidence when access must be reviewed or revoked.
• Server Provenance: Server provenance is the evidence that an MCP server is known, approved, and trustworthy before an agent invokes it. It usually includes registry approval, signed artifacts, and verification of what version is running, which turns server selection into a governed trust decision.
• Enterprise AI Control Plane: An enterprise AI control plane is the governance layer that sits above models and platforms to control context, policy, and accountability for AI actions. It is not a model or a catalog, but the operating layer that determines what agents can interpret and do across the estate.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Deployment-model trade-offs across self-hosted, in-VPC, air-gapped, and appliance-style options.
• Evaluation checklists for comparing claim-centric identity, audit propagation, and policy inheritance across gateway categories.
• Operational guidance on curated server registries, provenance verification, and onboarding new teams or agents.
• Category-specific fit questions for platform teams that need to decide whether MCP belongs in an existing control plane or a dedicated one.

👉 Stacklok's full post covers the category trade-offs, identity model questions, and deployment checks in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or AI governance programme, it is worth exploring.