Claude Code gateways expose the real AI gateway governance gap

At a glance

What this is: This analysis shows that Claude Code becomes an enterprise governance problem as soon as multiple developers use it, because direct-to-provider setups leave authentication, auditability, and MCP server control fragmented.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern developer-facing AI access as a shared control plane issue, not as isolated API-key hygiene.

Context

Claude Code is a developer-facing AI coding assistant that can connect through an AI gateway using simple environment variables, but that simplicity breaks down once many engineers, multiple providers, and MCP-connected tools enter the picture. The governance question is no longer whether the tool works, but whether access, routing, logging, and tool reach are centrally controlled.

For identity and access teams, the key issue is that Claude Code behaves like an enterprise non-human identity surface once it is scaled across an organisation. API keys, SSO, RBAC, SCIM, audit logs, and MCP server approvals all become part of the same governance boundary, and treating them separately leaves visibility gaps that platform teams cannot reconcile after the fact.

Key questions

Q: How should security teams govern Claude Code access across a team?

A: Treat it as a non-human identity problem. Use enterprise SSO, RBAC, and centralized gateway policy so access is revocable, auditable, and consistent across users and devices. If developers can point the tool directly at a provider with local credentials, governance becomes fragmented and offboarding remains incomplete.

Q: What breaks when developers connect Claude Code directly to MCP servers?

A: Visibility and control break first. Each engineer can create a separate set of tool connections and credentials, which fragments the inventory of what the assistant can reach. That makes recertification, offboarding, and incident reconstruction unreliable because the organisation no longer has one authoritative view of assistant-to-tool access.

Q: How do teams know whether an AI gateway is actually enforcing governance?

A: Look for blocked requests, denied tools, scoped credentials, immutable audit logs, and clear owner assignment for policy decisions. If the system only shows dashboards but cannot stop disallowed actions, it is providing visibility, not governance.

Q: When should organisations prefer centralised AI gateway controls over local developer setup?

A: Prefer centralised controls once multiple developers, shared models, or internal tool access are involved. At that point the operational risk is no longer the model itself but the spread of credentials, tool reach, and inconsistent policy enforcement across endpoints. Local setup is fine for experiments; production use needs the control plane.

Technical breakdown

Why Claude Code becomes a gateway governance problem

Claude Code is easy to adopt because it only needs a base URL and auth token to reach a gateway, but that simplicity hides the operational change that occurs at scale. Once multiple developers use it, the organisation needs a control point for authentication, routing, logging, spend management, and policy enforcement. Without that boundary, every developer effectively becomes a separate integration point with separate credentials, separate tool reach, and separate visibility. In identity terms, the problem is not the model call itself. It is the absence of a central enforcement layer for a distributed non-human access pattern.

Practical implication: treat gateway selection as an access-governance decision, not just a connectivity choice.

MCP server governance and developer tool reach

MCP servers extend Claude Code beyond model access into tool use, including GitHub, Slack, databases, and internal APIs. That makes the gateway part of the authorisation path, because tool reach can expand far beyond what the model provider itself sees. When developers can wire up their own MCP servers locally, the security team loses a reliable inventory of what the assistant can touch. Central registration, outbound authentication, and policy-enforced server allowlists turn that tool layer into a governed access surface rather than a shadow integration mesh.

Practical implication: inventory and approve MCP server connections before tool access spreads across individual laptops.

Central authentication replaces scattered API keys

The governance shift in enterprise AI is from per-user provider secrets to centrally managed identity. SSO, RBAC, and SCIM matter because they let the organisation prove who connected, what they accessed, and when access should end. That is especially important when offboarding or role changes occur, because manual API-key rotation does not scale cleanly across hundreds of developer devices. Centralised authentication also makes audit trails usable, since the access record is tied to an enterprise identity rather than a laptop-local credential. This is classic lifecycle governance applied to a non-human access surface.

Practical implication: align Claude Code onboarding and offboarding with your existing identity lifecycle processes, not ad hoc key distribution.

Threat narrative

Attacker objective: The attacker objective in this pattern is to exploit fragmented developer-side AI access to reach unmanaged tool paths, provider credentials, or sensitive internal systems.

1. Entry occurs when developers connect Claude Code directly to a provider or gateway using distributed credentials and locally configured tool endpoints.
2. Credential access expands when separate API keys and MCP connections are provisioned per developer rather than controlled centrally, creating many recoverable access paths.
3. Impact emerges as security and platform teams lose reliable visibility into which models and MCP servers are reachable from developer laptops.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Code turns gateway selection into identity governance, not just traffic routing. The moment developer-facing AI is scaled across an organisation, the real question becomes who can authenticate, what they can reach, and how that reach is audited. That shifts the control boundary from model access to non-human identity governance, where lifecycle, policy, and observability must be managed together.

Centralised MCP governance is the missing control plane for AI tool reach. MCP servers are not a side feature once assistants can invoke internal tools, data sources, and developer systems. Allowing each engineer to self-wire those connections creates a shadow access layer that security cannot inventory or recertify. Practitioners should treat approved server registration as the governing unit of tool access.

Per-user API keys are a lifecycle failure mode once AI assistants become shared infrastructure. API-key sprawl is tolerable in experiments and brittle in production because it makes offboarding, role change, and audit reconstruction manual. The deeper issue is that identity proof, entitlement assignment, and revocation now sit across developer laptops instead of in the enterprise control plane. That is a governance design flaw, not an integration inconvenience.

Authentication, routing, and observability are converging into one enterprise AI boundary. The market is moving toward platforms that collapse these functions into a single enforcement layer because organisations cannot operate model traffic, tool access, and audit evidence as separate programmes. That does not eliminate risk; it clarifies where responsibility sits. Teams should expect their AI gateway decisions to influence both security architecture and identity operating model.

Managed-device policy for AI assistants is becoming a distinct governance pattern. When a controlled configuration file or equivalent policy mechanism determines which MCP servers an assistant can use, the enterprise has effectively created a new class of non-human access enforcement. That pattern deserves its own review, offboarding, and monitoring discipline. Practitioners should recognise this as a governed access model, not a convenience feature.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Compliance Guide

What this signals

Identity controls have to move upstream of developer endpoints. Claude Code-style assistants expose a familiar failure mode: if access is configured locally, governance arrives too late to shape tool reach, logging, or offboarding. Teams should design around a single enforcement point for authentication, routing, and approved tool connections rather than layering reviews after adoption.

Gateway policy is becoming the practical boundary between experiment and production. The useful distinction is not whether a team can make a coding assistant work, but whether it can make access reviewable, revocable, and observable under enterprise identity processes. That boundary now matters as much for AI assistants as it does for workload identity and privileged access.

For practitioners

• Define the AI gateway as an access-control boundary Map Claude Code, model routing, and MCP access into the same governance scope so authentication, audit logging, and policy enforcement are reviewed together.
• Inventory every MCP server connection Require central registration for GitHub, Slack, database, and internal tool endpoints before developers can connect assistants from local machines.
• Replace local API keys with enterprise identity Use SSO, RBAC, and SCIM to issue, scope, and revoke assistant access through enterprise identity lifecycle processes rather than developer-managed secrets.
• Establish per-user auditability for assistant activity Ensure request logs, tool calls, and model selection records can be tied back to the enterprise user who initiated them.
• Test offboarding for AI assistant access Verify that leaving users lose gateway access, MCP reach, and provider permissions without manual cleanup on each workstation.

Key takeaways

• Claude Code becomes a governance issue when organisations scale beyond individual users and need consistent control over access, routing, and tool reach.
• The central risk is fragmented identity and tool governance, not simply model access, because local configuration hides what the assistant can touch.
• Enterprise teams should manage AI gateways, MCP approvals, and lifecycle controls as one access plane if they want auditability and enforceable offboarding.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• 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.
• Enterprise Identity Lifecycle Convergence: The merging of human and non-human identity governance into one operational model. In this context, offboarding, access review, logging, and delegated administration all depend on the same source-of-truth and revocation paths, instead of being handled as separate control problems.
• Assistant Tool Reach: Assistant tool reach is the set of systems, APIs, and internal services an AI assistant can invoke through connected tools or protocols. It matters because tool reach determines blast radius, audit scope, and the controls needed to keep a coding assistant inside approved boundaries.

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 IAM programme, it is worth exploring.