Notifications
Clear all
Topic starter
18/08/2026 2:50 pm
TL;DR: MCP gateway evaluation is splitting into four categories, and Stacklok argues that the right choice depends less on feature checklists than on deployment model, identity binding, governance scope, and supply-chain controls. The core issue is not MCP support alone, but whether the gateway can preserve real identity, auditability, and policy across both LLM and tool traffic.
NHIMG editorial — based on content published by Stacklok: How to Choose an MCP Gateway
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Require claim-centric identity propagation Verify that every LLM and MCP request carries real user or named-agent identity from your IdP.
- Make server provenance a gating control Insist on curated server registries, signed artifacts, and runtime blocking of unapproved MCP servers.
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.
👉 Read Stacklok's guide to choosing the right MCP gateway category →
MCP gateways: what category fit means for IAM and AI governance?
Explore further
18/08/2026 3:32 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: How to choose an MCP gateway without buying the wrong category
