Claude Code gateways expose the real AI gateway governance gap

At a glance

What this is: This is an analysis of why Claude Code deployments need an AI gateway, and its key finding is that model access, MCP governance, and audit controls become inseparable at team scale.

Why it matters: It matters because IAM, PAM, and NHI teams must treat AI coding assistants as governed access paths, not just developer productivity tools, once shared credentials and tool connections enter the picture.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read TruFoundry's full comparison of Claude Code gateway options

Context

Claude Code becomes an identity governance problem the moment it moves from one developer’s personal API key to shared use across a team. At that point, the questions are no longer only about model quality or latency. They become about centralized authentication, credential lifecycle, auditability, and whether tool access through MCP servers is actually controlled.

The article frames an AI gateway as the control plane that sits between developers and model providers, but the larger issue is governance drift. Once teams distribute access across laptops and local configs, they create the same kind of unmanaged access sprawl that security teams already know from service accounts, API keys, and other non-human identities.

That starting position is typical, not exceptional. Most organisations adopt AI coding tools quickly and discover governance gaps only after access has already spread across users, devices, and connected tools.

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 Claude Code users manage their own API keys?

A: Per-user keys create scattered trust edges, weak auditability, and slow offboarding. Security teams lose a single enforcement point for model access, usage tracking, and provider switching. The failure mode is not just inconvenience. It is an identity lifecycle gap that leaves access active after the user or device should no longer have it.

Q: How do you know if an AI gateway is actually governing access?

A: Look for centrally registered tools, per-user logs, identity-backed provisioning, and the ability to revoke access without touching each developer’s machine. If gateway telemetry exists but authentication still depends on shared or local secrets, the gateway is observing traffic rather than controlling identity.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

Why direct API-key access breaks down at team scale

Claude Code can be used with just a base URL and auth token, which makes individual adoption simple but governance weak. When many developers connect directly to the model provider, each local configuration becomes a separate trust edge. That fragments authentication, obscures usage, and makes offboarding or policy change a manual exercise. The result is not just convenience risk. It is an identity control problem where access, usage, and accountability no longer share a single enforcement point.

Practical implication: move shared Claude Code use behind a centralized gateway before local configuration sprawl becomes the default control model.

MCP server governance is the real access boundary

Claude Code can connect to MCP servers for GitHub, Slack, databases, and internal APIs, which means the tool boundary is broader than model calls alone. Without central registration and policy enforcement, every developer can wire up different tools with different credentials, creating invisible machine-to-machine reach. In identity terms, the model is not the only subject that needs governance. The tool graph itself becomes part of the attack surface, and unmanaged MCP connections can expand blast radius quickly.

Practical implication: inventory and approve MCP servers centrally, then tie tool access to enterprise policy rather than developer-by-developer setup.

Gateway routing adds visibility, but only if identity is enforced first

A gateway can centralize routing, logging, and failover, but those controls only matter when the identity layer is already structured. If authentication still depends on copied API keys, observability tells you who used the path, not whether the path was supposed to exist. The useful pattern is enterprise SSO, RBAC, and SCIM-backed onboarding and offboarding tied to a single control point. That is what makes AI gateway governance comparable to mature NHI lifecycle management rather than ad hoc developer tooling.

Practical implication: make identity provisioning and revocation the first control layer, then add routing and observability on top.

Threat narrative

Attacker objective: The objective is to reach model access, internal tools, and sensitive data paths through poorly governed AI gateway and MCP connectivity.

1. Entry occurs when developers use locally stored API keys or unmanaged gateway tokens to connect Claude Code directly to model providers and MCP tools.
2. Escalation follows when those same credentials or tool connections are reused across multiple devices and internal services without centralized policy enforcement or lifecycle offboarding.
3. Impact is broader model and tool exposure, including unauthorized data access, untracked usage, and harder incident investigation when credentials or MCP access are no longer visible in one control plane.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Code governance is really NHI governance wearing a developer-friendly interface. The article describes centralized authentication, RBAC, SCIM, audit logs, and controlled tool access, which are all classic identity controls applied to an AI workflow. The difference is not that the problem is new, but that the access surface now includes model calls plus MCP-connected tools. Practitioners should treat these deployments as governed non-human access, not as a special case of developer productivity.

Tool access is now part of identity perimeter design. When Claude Code can reach GitHub, Slack, databases, and internal APIs through MCP, the real control boundary moves from the prompt to the approved tool graph. That creates a distinct named concept: MCP trust sprawl, where every unmanaged tool connection becomes a separate privilege path. The implication is straightforward. If the tool graph is not centrally governed, the gateway becomes a traffic switch rather than an access control point.

Standing API-key workflows are a lifecycle failure, not just an authentication shortcut. Manual key distribution turns onboarding and offboarding into a per-device cleanup exercise, which is exactly the kind of lifecycle weakness identity programmes are supposed to eliminate. The article’s emphasis on SSO and SCIM is important because it replaces fragmented local secrets with revocable enterprise identity. Practitioners should recognise this as an access lifecycle problem, not merely a deployment preference.

AI gateway consolidation is pushing the market toward control planes, not point integrations. The article shows why organizations will increasingly expect one place to govern model routing, tool access, observability, and authentication. That validates a broader trend in identity security: the winning architecture is the one that can govern non-human access across provider, tool, and lifecycle layers without forcing developers to change workflows. Practitioners should re-evaluate whether their current IAM and NHI controls can operate at that control-plane level.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• AI agents attack surface research shows 98% of companies plan to deploy even more AI agents within 12 months, which makes governance debt a scaling problem, not a pilot issue.

What this signals

MCP trust sprawl: once developers can attach tools locally, the access boundary moves from the model to the tool graph, and that graph needs the same governance discipline that service accounts and API keys already require. The right response is to treat approved tool registration as a control requirement, not an optional convenience.

With 80% of organisations reporting AI agents already acting beyond intended scope in the AI agents attack surface research, the governance burden is moving faster than most review cycles. Teams that still rely on local configuration and manual offboarding will keep discovering access only after it has already expanded.

For teams building on authenticated gateways, the next step is not just observability. It is aligning gateway policy with identity lifecycle, MCP approval, and device management so access can be granted and removed at the same control point.

For practitioners

• Centralize Claude Code authentication Replace per-developer API keys with enterprise SSO and scoped RBAC so model access is tied to revocable identity rather than copied credentials.
• Register MCP servers before rollout Approve GitHub, Slack, database, and internal API connections through one control plane, then block unmanaged tool connections from local configs.
• Automate onboarding and offboarding Use SCIM to provision and revoke access as part of joiner-mover-leaver workflows, so removed users do not retain gateway or tool reach.
• Separate routing from authorization Treat model failover and observability as operational controls, but make identity policy the first gate before any request reaches a provider or MCP server.
• Review device-managed configurations Push controlled gateway and MCP settings through MDM for managed endpoints so local files cannot quietly expand access paths.

Key takeaways

• Claude Code becomes an identity governance problem as soon as it is shared across a team, because local keys and unmanaged tools create non-human access sprawl.
• The core control gap is not routing performance but lifecycle control over model access, MCP connections, and offboarding.
• Security teams should evaluate AI gateways as control planes for non-human identity, not as proxies that merely forward traffic.

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.
• NHI Lifecycle Management: The end-to-end governance of a non-human identity from creation and onboarding through active management, monitoring, credential rotation, and secure decommissioning.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

TruFoundry's full article covers the operational detail this post intentionally leaves for the source:

• Hands-on comparison of the top five Claude Code gateway options and how they differ in deployment model.
• Implementation details for managed MCP server registration and device-enforced configuration files.
• Provider-by-provider notes on failover, observability, and routing behaviour under load.
• Practical tradeoffs between self-hosted, VPC, on-premises, and hosted gateway deployments.

👉 TruFoundry's full post breaks down deployment tradeoffs, MCP governance, and routing controls in more implementation 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 identity programme, it is worth exploring.