Notifications
Clear all
Topic starter
20/08/2026 5:44 pm
TL;DR: A refactor that moves authentication, authorization, webhook execution, audit logging, and token exchange out of MCP gateways and into protocol-aware shim containers is reducing proxy complexity while keeping existing deployments intact, according to Obot. The shift matters because MCP identity control works better when the gateway stops becoming a policy monolith and access logic stays closer to the server boundary.
NHIMG editorial — based on content published by Obot: the refactor of its MCP gateway into a reverse-proxy passthrough with shim-based control handling
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should security teams govern MCP gateway identity controls?
A: Treat the gateway as a relay point, not the place where every identity decision lives.
Q: Why do MCP servers create new risks for NHI governance?
A: MCP turns AI-facing integrations into persistent, callable access paths, which means secrets, resources, and tools all become part of the non-human identity surface.
Q: What breaks when webhook handling is embedded in a central MCP gateway?
A: Webhook execution becomes part of the same critical path as authentication and request forwarding, so one design change can affect multiple control layers at once.
Practitioner guidance
- Define the gateway's governance boundary Decide which identity functions stay in the gateway and which move to per-server shims.
- Separate credential custody from server runtime Store client credentials, token exchange material, and audit tokens in the shim or an equivalent companion control plane.
- Adopt standards-based token exchange where applicable Use OAuth 2.0 Token Exchange for credential handoff instead of rewriting bearer tokens inside custom proxy logic.
What's in the full article
Obot's full post covers the implementation detail this analysis intentionally leaves for the source:
- The container layout for Kubernetes and Docker deployments, including how the shim and server communicate locally.
- The exact OAuth token exchange flow used to keep bearer handling standards-based inside the shim layer.
- The converter pattern for turning existing webhooks into MCP servers without exposing signing secrets to the main gateway.
- The non-breaking migration path for existing deployments and webhook configurations.
👉 Read Obot's design story on the MCP gateway refactor →
MCP gateway passthrough and shim design: what changes for IAM?
Explore further
20/08/2026 6:27 pm
Gateway identity control becomes fragile when it also owns protocol transformation: Obot's refactor shows the cost of letting a single MCP gateway absorb authentication, authorization, webhook execution, lifecycle logic, and audit logging. That pattern creates a control plane that is too coupled to the transport path to scale cleanly. For identity teams, the lesson is that access governance should not depend on a proxy becoming a full application runtime.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Should organisations use custom bearer-token rewriting for MCP tool access?
A: No, not when a standard token exchange flow is available. Custom rewriting is harder to audit, more fragile under change, and easier to couple to a single gateway implementation. Standards-based exchange keeps the security model clearer and gives practitioners a better foundation for future integrations.
👉 Read our full editorial: MCP gateway refactoring shows where identity control belongs
