MCP proxies are becoming the control layer for enterprise AI access

At a glance

What this is: An MCP proxy sits between clients and MCP servers to enforce policy, mediate credentials, and provide observability over AI-to-tool traffic.

Why it matters: It matters because MCP is quickly becoming part of enterprise identity and access architecture, so IAM teams need a control point for authorization, telemetry, and session governance across NHI and agent-driven access.

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.

👉 Read Obot's analysis of MCP proxy control for enterprise AI access

Context

MCP proxies address a basic governance gap: when AI clients and users connect directly to MCP servers, security teams lose a consistent place to authenticate, scope, inspect, and log activity. In practice, that leaves identity, authorization, and telemetry fragmented across multiple servers and tools, which is exactly where unmanaged access grows.

The primary issue is not just traffic routing. MCP introduces a new access layer for applications, data, and systems, so the enterprise now needs a control plane that can treat MCP interactions like governed identity events rather than opaque tool calls. That is why proxy design now sits alongside broader NHI and agent access governance, not outside it.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do MCP tool pickers create governance risk even when users stay in control?

A: Tool pickers can turn one-off access into repeatable authority patterns. When users save tool bundles or reusable modes, the client is no longer just helping them choose actions, it is normalising a stable access profile. That matters because repeated authority is easier to misuse, harder to spot, and often broader than the original task.

Q: What breaks when MCP access is not centrally enforced?

A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths. That breaks policy consistency, weakens auditability, and leaves security teams with multiple uncontrolled routes to the same backend system.

Q: How do audit and telemetry requirements change when MCP becomes part of the AI stack?

A: Audit data becomes part of the identity record because it shows who accessed which server, what they invoked, and when. Teams need to control access to those logs as tightly as they control the servers themselves, since logs may contain sensitive prompts, tool details, or credentials. That creates a second governance layer around the evidence store.

Technical breakdown

How an MCP proxy mediates client-to-server identity

An MCP proxy acts as an intermediary identity layer between the MCP client and the target server. In practice, it receives the client request, authenticates it, applies policy, and then reissues or forwards the call to the upstream MCP server using a scoped credential or session context. That design lets organizations separate client identity from backend access, enforce OAuth 2.1 flows, and keep a single place to inspect requests, tool definitions, and responses. The proxy is also typically both an MCP server and an MCP client, which makes it a control point rather than just a traffic relay.

Practical implication: treat the proxy as part of identity architecture, not infrastructure plumbing, and bind it to enterprise authentication and authorization controls.

Why access scoping and RBAC matter for MCP tool calls

MCP servers can expose tools, data, and system actions that vary widely in sensitivity. Without access scoping, every connected client may see more capability than it should, especially when tool definitions are shared broadly across teams. The article describes RBAC, token exchange, user isolation, and policy filters as the mechanism for separating who can discover a tool from who can invoke it. That distinction matters because tool discovery itself can leak sensitive context, and invocation can create backend-side privilege use if access is not narrowed first.

Practical implication: scope tool visibility and invocation separately, and require policy enforcement before a client ever reaches backend execution.

What telemetry changes when MCP traffic is centralized

Centralizing MCP traffic gives teams request tracking, performance data, error logs, and full audit trails in one place. That is more than operational convenience. It creates evidence for who accessed what, when, and through which server, which is essential when MCP deployments span internal teams, third parties, and remote services. It also enables scrutiny of log access itself, since the proxy can expose sensitive content that should not be broadly visible. In identity terms, the proxy becomes the record of non-human and user-mediated actions across a new control plane.

Practical implication: define who can read proxy logs, how long they are retained, and how audit evidence maps back to access reviews and incident response.

Threat narrative

Attacker objective: The objective is to reach sensitive applications, data, or system actions through poorly governed MCP access while avoiding centralized detection and audit trails.

1. Entry occurs when clients connect directly to distributed MCP servers without a shared control point, allowing unmanaged access paths and inconsistent authentication.
2. Escalation follows when exposed tools, hard-coded credentials, or overly broad permissions let a client discover more capability than it should or invoke backend actions outside intended scope.
3. Impact is the loss of governance visibility, unauthorized data exposure, and backend misuse that becomes difficult to investigate once MCP sprawl spreads across teams and vendors.

Breaches seen in the wild

• New York Times breach — New York Times source code and credentials exposed via GitHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

MCP proxying is becoming the governance boundary for agent-to-tool access. The article makes clear that direct client-to-server MCP connections create blind spots in authentication, authorization, and logging. For identity teams, that means the proxy is not an optional optimization but the layer where NHI-style controls are actually enforced. The practitioner conclusion is simple: if MCP traffic is not centrally mediated, it is not centrally governable.

Tool discovery now has the same risk profile as tool execution. The article notes that tool descriptions can leak sensitive context and support prompt injection during discovery, not just during invocation. That changes the control problem from simple API gating to pre-invocation policy enforcement. The implication is that enterprises must govern what a client can see before they worry about what it can call.

Central logging creates identity evidence, but only if log access is constrained. A proxy can prove who accessed what and when, yet those audit trails may themselves contain sensitive context. This is the familiar IAM paradox for NHI and agentic workflows: observability improves accountability only when the evidence store has its own access controls. The practitioner conclusion is to treat proxy logs as regulated identity data, not operational noise.

Named concept: MCP access control plane. The article points to a control layer that combines policy, credential mediation, telemetry, and session management for MCP traffic. That is a useful concept because it distinguishes governed AI connectivity from simple gateway routing. The field should treat this as a new NHI and agent access boundary, with enterprise oversight required before MCP sprawl hardens into shadow infrastructure.

Remote MCP sprawl will outpace manual governance if teams rely on chat threads and ad hoc registries. The article cites environments with thousands of known MCP servers, which is a scale problem as much as a security problem. Once the server count grows that fast, identity review, ownership mapping, and access certification break down unless control is centralized. The practitioner conclusion is to inventory first and approve second.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• AI Agents: The New Attack Surface report shows that 80% of organisations report AI agents have already acted beyond intended scope.

What this signals

MCP access control plane: enterprises should now treat proxy policy, token mediation, and audit logging as a single governance surface rather than separate infrastructure concerns. As MCP adoption rises, the control point that mediates tool access will determine whether AI connectivity is auditable or merely observable. For teams building a programme around NHI and agent access, that means proxy governance should sit inside IAM and PAM review cycles, not outside them.

With 18% of MCP server deployments implementing access scoping, the category is still early in governance maturity and still vulnerable to shadow growth. That creates a strong case for inventory-first controls and for linking proxy policy to enterprise identity sources before broader deployment.

The next phase is likely to be evidence-driven control placement: which tools are exposed, which identities can see them, and which sessions generate sensitive data. Teams that wait for a full platform standard will end up retrofitting governance across a much larger server estate.

For practitioners

• Define the MCP proxy as an identity control point Map the proxy into IAM and NHI governance, then require authentication, authorization, and audit logging at that layer before any server is exposed.
• Separate tool discovery from tool execution Apply policy before tool definitions are presented to clients, and filter upstream tools by names, scopes, and business context to reduce prompt injection and context leakage.
• Bind proxy access to enterprise identity systems Integrate the proxy with existing identity platforms such as Okta or Microsoft Entra so access decisions reflect role, team, and server-specific policy.
• Treat proxy logs as sensitive evidence Restrict access to request logs, audit trails, and session records, then align retention and review with incident response and certification workflows.
• Inventory remote MCP servers before expanding use Maintain a server registry with ownership, transport type, and capability metadata so new MCP deployments can be reviewed against a known baseline.

Key takeaways

• MCP proxies matter because they create a central place to authenticate, authorize, inspect, and audit AI-to-tool traffic.
• The governance risk is not only execution, but tool discovery, credential handling, and evidence access across a rapidly expanding server estate.
• Identity teams should treat MCP proxy policy as part of their NHI control plane and bring it into enterprise access reviews now.

Key terms

• 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.
• 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.
• Tool discovery: The process by which an AI agent learns what functions or actions are available to it at runtime. It becomes a security issue when discovery is broader than entitlement, because the agent can map capabilities even when it should not be able to use them.
• Session Management: Session management is the control layer that keeps track of an identity after successful authentication. Good session management limits how long access lasts, protects session material from theft, and supports fast revocation when risk changes. Poor session handling often turns one valid login into prolonged unauthorized access.

What's in the full article

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

• How the MCP Gateway implements proxy-based control across remote MCP servers and client sessions
• Details on policy enforcement using OPA Rego, OAuth 2.1, RFC 8693 token exchange, and personal access tokens
• Support for multiple transports, including Streamable HTTP, stdio, and Server-Sent Events
• Operational examples of request tracking, connection pooling, and server registry management at scale

👉 Obot's full article covers the proxy architecture, governance functions, and scaling details behind MCP server delivery.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.