TL;DR: An MCP proxy that began as transport bridging must become an enterprise control point once multiple teams share AI access to internal tools, according to Willow, because identity, authorization, auditability, and action-level policy matter more than simple stdio-to-HTTP translation. The governance problem is not connectivity; it is controlling who can do what, when, and with which upstream credentials.
At a glance
What this is: Willow argues that an MCP proxy server stops being a simple transport bridge once multiple teams share it and it must enforce identity-aware access, action-level governance, and observability.
Why it matters: This matters because IAM teams and AI platform owners need a governed control point for AI agents and LLM clients before shared tool access turns into shadow AI, uncontrolled writes, and weak audit trails.
Context
An MCP proxy server is a governed intermediary between AI clients and upstream tool servers, and the core problem is that transport conversion alone does not control identity, permissions, or action risk. Once shared AI access reaches internal systems, the governance model must shift from connection management to policy enforcement across tools, users, and requests.
The article is really about the security gap that appears when a convenient developer bridge becomes enterprise shared infrastructure. In that state, the proxy has to answer who may discover tools, which actions are allowed, which upstream credential is used, and how each action is tied back to a human or AI agent authorization decision.
Key questions
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.
Q: What breaks when MCP traffic bypasses a central proxy?
A: You lose policy enforcement, session isolation, and complete audit evidence in one move. Without a single proxy path, credentials can be reused across clients, requests may reach sensitive systems without validation, and investigators later lack the record needed to explain what happened. Central mediation is what turns MCP into a governable channel.
Q: How do teams know whether their MCP gateway is actually controlling risk?
A: Look for evidence that the gateway can restrict tool discovery, block high-risk actions, and preserve a complete record of who requested what and why it was allowed or denied. If users can still reach sensitive systems without a clear policy decision, the gateway is forwarding traffic, not governing it.
Q: Should organisations use one gateway for all AI agents and LLM clients?
A: A single gateway can work if it is paired with namespaces, team-level tool bundles, and policy boundaries that prevent cross-team overexposure. Without those controls, one endpoint becomes a shared blast radius. The decision should be based on whether the gateway can preserve least privilege while keeping onboarding simple.
Technical breakdown
Why transport bridging is not enough for shared MCP access
A basic MCP proxy solves protocol reachability problems, such as stdio to HTTP or SSE translation, but it does not solve governance. Once multiple teams connect through the same proxy, the control plane must distinguish low-risk lookups from high-risk write actions, because the same session can expose both. That creates a gap between transport-level access and action-level authority. The enterprise design problem is therefore not whether the proxy can forward requests, but whether it can constrain what each request is allowed to do across shared internal tools, upstream systems, and different user populations. See the MCP Security Guide.
Practical implication: Treat transport bridging as plumbing, not governance, and define policy at the action layer before broad rollout.
How identity-driven authorization changes the proxy model
Identity-aware MCP governance means the proxy becomes the enforcement point between a user, an agent, and an upstream tool. Instead of granting broad access to a connected client, the gateway should evaluate the authenticated identity, associated role, and the specific action being requested. That is closer to an API gateway pattern than to a simple relay, but with an important difference: MCP tool calls carry prompt-driven intent and tool semantics, so the authorization decision must account for what the agent is trying to do, not only whether the connection exists. Upstream credentials should stay centralized and scoped by policy rather than exposed on endpoint machines.
Practical implication: Bind tool access to identity and action, not to the mere presence of a valid session.
Why observability must include human-tied audit trails
Enterprise MCP usage creates a need for end-to-end traceability from the client through the gateway to the upstream server and back. Audit logs need to show the user, the client or agent, the requested tool, the policy outcome, and any redaction or deny decision. Without that chain, teams cannot separate legitimate automation from unsanctioned tool use or explain why a risky action was allowed. Observability also matters for operational reasons, because latency, blocked actions, and error patterns become part of production support when shared AI depends on the same gateway layer. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Log identity, tool, decision, and outcome together so security and operations can reconstruct every AI action.
Threat narrative
Attacker objective: The objective is to use a trusted AI integration path to reach internal tools and data with more privilege and less oversight than the organisation intended.
- Entry occurs when an AI client or agent connects to a shared MCP proxy and inherits access to upstream tools through a managed endpoint.
- Escalation occurs when the proxy exposes broad tool lists or inconsistent namespaces, allowing a benign-looking session to reach write or production-changing actions.
- Impact occurs when sensitive internal systems are reached through weakly governed tool calls, creating shadow AI, unauthorized changes, or unrecoverable audit gaps.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
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
Enterprise MCP governance is really a control-plane problem, not a transport problem. The article correctly shifts the debate away from stdio, HTTP, or SSE mechanics and toward who can discover, invoke, and modify actions through shared tool surfaces. Once multiple teams use the same proxy, the security question becomes whether the organisation can govern intent at runtime, not whether it can relay messages. That is the point where identity, authorization, and action policy become one control layer, and practitioners should stop treating the proxy as a simple integration utility.
Shared MCP access creates an identity blast radius that standard IAM alone does not collapse. IAM can authenticate users and assign roles, but the article shows why prompt-driven tool use needs action-specific decisions as well. A user or agent can have a valid session and still be too powerful for a particular tool call, especially when the same proxy fronts finance, HR, engineering, and production systems. The named concept here is action-layer governance: the idea that the real control boundary sits at the requested action, not the network connection.
Shadow AI becomes operationally durable when tool exposure is easier than review. The article’s real warning is that easy local setups and unreviewed MCP servers spread faster than governance can track them. That creates inconsistent namespaces, hidden upstream credentials, and policy gaps that are hard to unwind later. The practitioner implication is not simply to add more review, but to make approved access easier than unsanctioned access so the control plane becomes the path of least resistance.
Human-tied audit trails are now a prerequisite for accountable AI operations. If a gateway cannot tie a tool call back to a person, a client, an agent, and a policy decision, the organisation cannot explain or defend the action later. That is especially important where the same proxy handles read, write, export, and production-changing operations. Practitioners should treat traceability as part of access control, not as a separate logging project.
Action-level permissions are the real scaling test for enterprise MCP adoption. The article makes clear that broad connection approval is too coarse once AI systems can touch real business workflows. The governance model has to separate discovery from execution, and execution from high-risk change. Teams that cannot express those distinctions in policy will end up with either blanket denial or unsafe over-permissioning, and neither outcome scales.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Governance programmes will increasingly need to treat MCP proxies as identity control points rather than integration utilities. That means access decisions must move from whether a client can connect to whether a specific action should be allowed for that identity, that tool, and that business context.
Action-layer governance: This is the point where enterprises stop asking whether AI can reach a tool and start asking whether a given tool action should be permitted, logged, redacted, or blocked. The organisations that operationalise that distinction first will have a cleaner path from experimentation to production without turning the proxy into a shadow approval queue.
For practitioners
- Define action-level policy boundaries Separate read, write, export, delete, and production-changing tool actions before exposing shared MCP access to multiple teams.
- Centralize approved MCP servers Move shared upstream servers behind a managed gateway with namespaces, ownership, and a registry of approved tools.
- Bind every request to identity Use existing SSO, group membership, and lifecycle controls so each tool call is tied to a human identity or managed agent identity.
- Log policy outcomes end to end Capture the user, client or agent, tool name, policy decision, and any redaction or deny event in one audit trail.
Key takeaways
- The article shows that shared MCP infrastructure changes the security problem from transport bridging to governed tool use.
- Identity-aware authorization and action-level policy are the controls that keep AI access from becoming a broad shared blast radius.
- Audit trails, namespaces, and approved server registries are essential if an MCP proxy is going to support enterprise adoption safely.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · MCP Security Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared MCP access can easily overexpose agents and service credentials beyond the requested action. |
| NHI-04 — Insecure Authentication | The proxy depends on strong identity verification before it routes tool access to internal systems. | |
| Recommendation — Scope MCP-connected identities to the minimum tool and action set needed for each request. Require strong authentication at the gateway before any MCP tool discovery or invocation. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on how agents and clients can gain excess authority through shared tool pathways. |
| Recommendation — Apply per-action authorization checks to stop agents from turning connected access into excess privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the central control principle for limiting tool exposure and upstream credentials. |
| Recommendation — Enforce least privilege so each MCP action is authorized only at the minimum required scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing permissions and entitlements across shared AI tool access. |
| Recommendation — Review and constrain entitlements so MCP tool access maps to role and task need. | ||
| NIST Zero Trust (SP 800-207) | Least privilege — Least privilege | Zero Trust fits the article's requirement to verify each request and avoid standing broad access. |
| Recommendation — Evaluate each MCP request independently and remove standing privilege where possible. | ||
Key terms
- MCP proxy: An MCP proxy is a middle layer that sits between an AI agent and MCP servers, forwarding requests, enforcing policy, and often logging activity. In technical terms, it mediates Model Context Protocol traffic, can normalize tool calls and responses, and helps control authentication, authorization, auditing, and data exposure across connected resources.
- Action-Level Governance: Action-Level Governance is the practice of controlling what an agent, user, or system can do at each discrete step of execution. It applies policy to individual actions, not just to the identity itself. In AI and automation, it limits tool use, data access, approvals, and side effects in real time.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org