MCP gateway refactoring shows where identity control belongs

At a glance

What this is: Obot's MCP gateway refactor shifts security and lifecycle responsibilities from a central proxy into protocol-aware shim containers and standards-based token exchange.

Why it matters: This matters because IAM teams must decide where to enforce authentication, authorization, logging, and secrets isolation when MCP servers and AI-connected tools expand beyond a single control point.

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.

👉 Read Obot's design story on the MCP gateway refactor

Context

MCP gateways sit at the intersection of identity, tool access, and runtime mediation for AI-connected systems. When that gateway also becomes the home for authentication, authorization, webhook handling, lifecycle coordination, and audit logging, it starts to behave like an overloaded policy engine instead of a clean control boundary.

For identity and access teams, the real question is not whether an MCP gateway exists, but whether it should own governance decisions that scale poorly as server count, tool fan-out, and token handling increase. Obot's refactor is a useful example of how control-plane design can either centralize trust or push governance closer to the identity being mediated.

That distinction maps directly to NHI governance: secrets, token exchange, and auditability need to stay isolated from the workload that consumes them, while access policy needs a stable place to live. The article's starting point is typical of early platform designs that absorb too much logic before governance boundaries are defined.

Key questions

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. Authentication, authorization, secrets custody, and audit logging should each have a clear owner and boundary. That separation reduces coupling, limits blast radius, and makes MCP governance easier to change without rewriting the proxy layer.

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. If those interfaces are not bound to lifecycle controls, teams lose visibility into who or what is using enterprise capabilities and when.

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. That makes testing harder, increases maintenance risk, and creates hidden dependencies between security policy and application behaviour.

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.

Technical breakdown

Why an intercepting MCP server becomes a governance bottleneck

An intercepting design places every control decision inside the proxy path, which means authentication, authorization, logging, lifecycle checks, and request transformation all compete for the same execution surface. That can work initially, but each new feature increases coupling between policy enforcement and protocol handling. In MCP environments, the result is a gateway that knows too much, changes too often, and becomes harder to validate because every security decision is embedded in forwarding logic rather than separated into clear trust layers.

Practical implication: separate identity decisions from protocol relay code before the gateway becomes the only place policy can change.

How shim containers change secrets and token handling

A shim container is a protocol-aware companion process that handles MCP-specific security tasks next to the server rather than inside the central gateway. In Obot's model, the shim performs authentication, authorization, webhook invocation, audit logging, and OAuth token exchange while keeping client credentials and exchange secrets away from the MCP server itself. That matters because the server and the shim now have different secret scopes, which reduces accidental exposure and narrows the blast radius of a compromise.

Practical implication: isolate credential custody from workload execution so the server never sees secrets it does not need.

Why OAuth token exchange is a better fit for MCP tool access

OAuth 2.0 Token Exchange RFC 8693 lets one credential be exchanged for another in a standards-based flow, which is cleaner than replacing bearer tokens inside a custom gateway. For MCP, that means the gateway can forward the original token unchanged and let the shim perform the exchange at the edge of the actual tool interaction. This preserves protocol clarity, reduces bespoke bearer-token rewriting, and gives authors a more familiar model when integrating with existing OAuth ecosystems.

Practical implication: use standards-based token exchange where possible instead of embedding custom credential substitution into gateway logic.

NHI Mgmt Group analysis

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.

Secrets custody must be separated from workload execution in MCP architectures: The article's shim model keeps client credentials, token exchange secrets, and audit tokens out of the MCP server while keeping the server's own configuration out of the shim. That is the right direction for NHI governance because secret scope should match function, not convenience. The named concept here is identity blast radius: the smaller the credential boundary, the less damage a single runtime compromise can create.

Token exchange is a governance boundary, not just an integration detail: Using OAuth 2.0 Token Exchange shifts credential handling from custom forwarding logic to a standard that is easier to reason about, audit, and constrain. That matters because MCP tool access is increasingly part of NHI stewardship, not just application plumbing. Practitioners should treat exchange points as policy checkpoints, especially where tool permissions and server lifecycle differ across deployments.

Composable MCP architectures are starting to look like managed NHI estates: Once every server has a shim, a converter, and a defined secret boundary, the problem stops being raw connectivity and becomes lifecycle governance across many machine identities. That aligns more closely with OWASP-NHI and NIST-CSF thinking than with traditional reverse-proxy design. The practical conclusion is that MCP platforms need explicit ownership, scoping, and offboarding rules for each server instance.

The market is moving toward less monolithic identity mediation: This design change suggests that future MCP governance will favor thin gateways, delegated enforcement, and standardized exchanges over bespoke all-in-one control planes. That does not eliminate security work. It changes the unit of governance from the proxy to the combination of server, shim, and credential boundary, which is a better fit for modern NHI programmes.

From our research:

• 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.
• For a broader control lens, see NHI Lifecycle Management Guide for lifecycle patterns that keep secrets out of the workload path.

What this signals

Identity blast radius: MCP architectures that keep credentials, token exchange, and audit tokens inside a narrow shim boundary are easier to govern because compromise does not automatically expose the whole server estate. That design choice matters more as AI-connected tool use grows and static credential habits persist in infrastructure teams.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, the control problem is no longer about whether access exists. It is about where enforcement happens, how secrets are isolated, and whether server lifecycle governance is actually mapped to runtime identity boundaries.

As MCP deployments scale, teams should expect the governance model to shift from gateway-centric review to component-level ownership across server, shim, and exchange flow. The organisations that treat those pieces as one managed identity surface will have a cleaner path to auditability and offboarding.

For practitioners

• Define the gateway's governance boundary Decide which identity functions stay in the gateway and which move to per-server shims. Keep authentication, authorization, and audit policy explicit, but avoid embedding protocol-specific business logic in the forwarding path.
• Separate credential custody from server runtime Store client credentials, token exchange material, and audit tokens in the shim or an equivalent companion control plane. Do not expose those secrets to the MCP server process itself.
• 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. That keeps the trust model auditable and easier to port across tool providers.
• Treat each MCP server as a governed identity instance Apply lifecycle controls to every deployed server, including provisioning, change control, and offboarding of the shim and any related webhook converter components. Use the NHI Lifecycle Management Guide to map those steps to operational ownership.
• Review tool permission scope before scaling composite servers As composite MCP servers add fan-out and routing complexity, verify that tool permissions remain tightly scoped and that local secrets do not accumulate across nested server paths.

Key takeaways

• Obot's refactor shows that MCP gateways become fragile when they absorb identity, logging, and lifecycle logic that belongs in separate control boundaries.
• The governance risk is not just complexity, but credential scope, because shared runtime paths make secret custody and auditability harder to defend.
• Practitioners should treat each MCP server stack as a managed NHI surface with explicit ownership, scoping, and offboarding rules.

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.
• Shim Container: A companion container that sits alongside an MCP server and handles protocol-aware security functions. It can authenticate requests, enforce authorization, exchange tokens, and log activity while keeping sensitive credentials separated from the main workload.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.

👉 The full Obot post covers the shim architecture, token exchange flow, and migration details.

Deepen your knowledge

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