Notifications
Clear all
Topic starter
24/06/2026 7:26 pm
TL;DR: An MCP proxy mainly mediates transport, while an MCP gateway binds identity, consent, authorization, and auditability for agent tool use, according to Permit.io. That distinction matters because production MCP turns connectivity into delegated trust, and proxy-only designs leave security, legal, and incident-response teams unable to explain why an agent acted.
NHIMG editorial — based on content published by Permit.io: MCP Gateway vs MCP Proxy: What’s the Difference, and Why It Matters in Production
Questions worth separating out
Q: How should security teams govern agent tool access in MCP environments?
A: Treat tool access as delegated authority, not simple request forwarding.
Q: When does an MCP proxy stop being enough for production?
A: A proxy stops being enough when the agent touches real business systems, customer data, or regulated workflows.
Q: What breaks when teams treat MCP proxies as governance controls?
A: They usually lose the ability to prove who authorised the action, what consent was granted, and whether the tool call stayed inside scope.
Practitioner guidance
- Map the delegated trust boundary Document where a human identity becomes an agent session, where consent is captured, and where tool use is authorised.
- Separate transport controls from decision controls Use proxies for TLS, routing, and topology hiding, but reserve gateways or policy points for identity binding, scope checks, and per-tool authorisation.
- Require runtime evidence for sensitive tool actions Record the consent scope, current identity context, policy decision, and downstream action for every agent invocation that can affect tickets, code, customer records, or business workflows.
What's in the full article
Permit.io's full article covers the operational detail this post intentionally leaves for the source:
- A practical table comparing proxy and gateway responsibilities across connectivity, identity, consent, and audit.
- Examples of when a transport-only pattern is sufficient and when delegated authority demands a gateway.
- Product-language context around low-latency policy decisioning, hybrid deployment patterns, and decision logging.
- The operational questions teams should ask when evaluating MCP control points in production.
👉 Read Permit.io's analysis of MCP gateway vs MCP proxy in production →
MCP gateway vs MCP proxy: are your agent controls actually governing?
Explore further
25/06/2026 4:43 am
Proxy-only MCP designs create a delegated trust gap that identity teams will have to close. A transport component can forward traffic, but it cannot prove delegated authority, consent scope, or per-tool intent. Once agents touch real systems, the missing control is not routing but governable decision evidence. Practitioners should treat proxy-only deployments as an interim state, not a production governance model.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
- 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, according to SailPoint research.
A question worth separating out:
Q: What is the difference between transport mediation and delegated trust in MCP?
A: Transport mediation gets the request to the server safely. Delegated trust decides whether the agent should be allowed to perform that action for that user in that moment. The first is a network function. The second is an identity and policy function that determines whether the system is governable.
👉 Read our full editorial: MCP gateway vs MCP proxy: why delegated control matters in production
