MCP gateway vs MCP proxy: why delegated control matters in production

At a glance

What this is: This is an analysis of MCP gateway versus MCP proxy design, with the central finding that proxies move traffic while gateways enforce delegated control over agent actions.

Why it matters: IAM, PAM, and NHI teams should care because once an AI agent acts on behalf of a human, identity, consent, authorization, and audit evidence become governance requirements rather than optional routing features.

Context

The security gap in MCP deployments is not transport. It is delegated authority, because once an agent reaches tickets, code, customer data, or internal systems, the control problem becomes who the agent is acting for and what it may do.

An MCP proxy can mediate requests and hide topology, but it usually does not bind identity, consent scope, and tool-level policy into one decision path. An MCP gateway exists to make that delegated trust explicit and enforceable.

That distinction matters most in production, where AI agents can chain tool use across a session and drift from harmless lookup to sensitive action without a human in the loop at the moment of execution.

Key questions

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: Why do AI agents need request-time authorization for MCP tools?

A: Because the risk is in the invocation context, not just the caller's identity. A model can only act on tools it can see, and the actual arguments may make a permitted action unsafe or out of scope. Request-time policy lets the system judge the caller, the tool and the input together before execution.

Q: What are the signs that an MCP deployment is still proxy-only?

A: If the platform can show how a request reached a service but cannot show who the agent represented, what consent it held, or why a sensitive action passed policy, it is proxy-only in practice. That usually means the control boundary is still at transport, not governance.

Q: How should security teams decide whether an MCP proxy is enough or they need a gateway layer too?

A: Use a proxy alone when a small, trusted team is supervising a limited set of internally controlled servers and there is no need for per-call governance. Move to a gateway when multiple teams, tenants, or regulated workflows share the same infrastructure, because you then need identity binding, authorization checks, and an auditable record of each decision.

Technical breakdown

Transport mediation versus delegated trust

An MCP proxy sits on the request path and focuses on connectivity: it forwards traffic, normalizes access, terminates TLS, and can mask network details. That is useful, but it is not governance. An MCP gateway adds a policy decision layer between the agent and the tool, so the system can evaluate identity, consent scope, and per-action authorization before the request reaches the target service. In practice, the gateway becomes the enforcement point for runtime decisions that a proxy cannot make because it lacks the trust context needed to explain why an action is allowed.

Practical implication: Treat proxy functions as network plumbing and reserve gateway design for any path that needs policy-backed agent authorization.

Why agent sessions need runtime authorization

MCP changes the security model because agents are not static callers. They discover tools, carry context forward, and can chain actions across a session. That means a one-time authentication event is not enough to explain or constrain later tool use. Runtime authorization evaluates the current agent, the current consent scope, and the current tool request together, which is closer to delegated authority than simple request forwarding. Without that decision layer, the platform can prove a request moved correctly but cannot prove it was appropriate for that moment or that user.

Practical implication: Design for per-invocation policy checks whenever an agent can change task direction mid-session.

Auditability is part of the control plane

A production gateway has to do more than approve or deny requests. It must record the identity binding, the consent context, the policy result, and enough surrounding detail for security, compliance, and incident response to reconstruct why the action occurred. That is especially important in MCP because tool calls may touch regulated data or operational systems where later review depends on evidence, not memory. A proxy may log traffic, but transport logs alone rarely answer accountability questions about delegated actions.

Practical implication: Capture decision logs that explain delegated authority, not just connection metadata.

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.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

Delegated trust, not connectivity, is the real control boundary in MCP. Once an agent can discover tools and invoke them in production, the problem is no longer whether the request reaches the server. The problem is whether the organisation can enforce who the agent represents, what consent it holds, and whether the action is acceptable in context. That makes the gateway a trust and control layer, not a networking accessory. Practitioners should treat any production MCP design without delegated-control semantics as incomplete.

Transport-only thinking creates an accountability gap. Proxy-centric architectures can make the system function while leaving no clear answer to why an agent was allowed to act. That gap matters across IAM, PAM, and NHI governance because the control objective is not just access, but explainable delegated access. If the decision cannot be reconstructed later, the architecture has moved risk into the review process rather than removing it.

Runtime policy is the governing primitive for agent tool use. MCP makes the old authenticate-once model too weak for dynamic agents that can chain tools and shift intent within a session. The governing assumption should be that authorisation must be evaluated at the moment of action, not inferred from earlier connectivity. Teams that still anchor their design on transport mediation will discover that the hardest production questions are identity, consent, and evidence.

MCP gateway vs MCP proxy is a category distinction with programme consequences. The market language matters because teams often buy or build the wrong layer for the problem they actually have. If the goal is safe routing, a proxy may be enough. If the goal is delegated authority over tool actions, the programme needs a gateway model that ties human intent, agent identity, policy, and audit together.

Proxy-first deployments are often a staging pattern, not a final state. Many teams begin with the simplest component that makes MCP work, then outgrow it as business systems, regulated workflows, and customer data enter the picture. The signal for maturity is when the organisation stops asking how to forward requests safely and starts asking how to govern agent action explicitly. That is the point where control design must move beyond transport.

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.
• Read next: MCP Security Guide

What this signals

Gateway semantics are becoming the control layer for production agent systems. As agents move from demos into business workflows, the real question shifts from connectivity to delegated authority. Teams should expect their MCP architecture to be judged on whether it can prove who the agent represented, what it was allowed to do, and how that decision was recorded.

A proxy can still be a useful staging layer, but it should no longer be mistaken for the control plane once agents touch real systems. The programme signal is clear: identity binding, consent scope, and per-action authorization belong in the path before the tool call, not in documentation after the fact.

For practitioners

• Separate transport from authorisation Map every MCP component to either connectivity mediation or delegated-control enforcement. If a component is only moving requests, do not rely on it for consent, policy, or audit decisions.
• Bind agent sessions to human identity Require the control layer to tie an agent session to the human on whose behalf it acts, then carry that binding into each tool decision so later review can reconstruct delegated authority.
• Evaluate tool actions at runtime Check the current request, current consent scope, and current tool context before each action instead of trusting the initial session grant to remain valid for the whole workflow.
• Record decision evidence, not just traffic Log the policy result, the identity context, and the approved tool scope so security and compliance teams can explain why a sensitive action was allowed.

Key takeaways

• MCP proxy and MCP gateway are not interchangeable terms, because they solve different production problems.
• The core risk is not whether an agent can reach a tool, but whether the organisation can govern delegated action with evidence.
• Teams that need explainable agent behaviour should move control decisions into the runtime path rather than relying on transport mediation alone.

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.
• 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.
• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

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.