Public MCP servers and reverse proxies increase risk because they create internet-facing entry points, depend on changing allowlists, and can expand the scope of what defenders must patch and monitor. They also make it easier for an exposed agent path to become a broader compromise path, especially when the agent can reach sensitive enterprise systems from outside the network boundary.
Why public MCP servers and reverse proxies change the security model
Once an agent talks to a public MCP endpoint, the trust boundary shifts. The server is no longer a local helper inside a controlled environment, it becomes an internet-exposed integration point that may accept requests from many clients, many networks, and many trust contexts. That changes how you authenticate, authorise, inventory, and monitor the path, especially when the agent can chain tools into sensitive enterprise systems.
That shift is why the subject is not just “using MCP”, but using MCP across a public path. A reverse proxy can hide and aggregate traffic, yet it also becomes part of the control plane, so token handling, request routing, and policy enforcement all matter. The design only stays safe if the proxy and server both preserve the intended audience, identity, and scope of each request.
For the protocol side, the MCP authorization specification is useful because it treats MCP servers as OAuth resource servers rather than generic pass-through endpoints. That matters when the agent is reaching a server through a public URL, because loose token forwarding or weak audience binding can turn a bounded request into an unintended delegated session.
Why allowlists, token scope, and proxy placement become brittle
Public exposure forces defenders to maintain allowlists, callback rules, and network policy exceptions that are much harder to keep stable than a private endpoint or local transport. Every time the proxy changes, the set of trusted destinations, headers, and client paths can change too, which increases the chance of misconfiguration and accidental overexposure. The risk is not only external attackers, but also internal drift between what the proxy permits and what the agent was meant to reach.
This is also where reverse proxies can be deceptive. They often look like a clean security layer, but they can obscure whether the server is validating the original caller, the proxied caller, or a forwarded credential. If the proxy becomes a generic trust relay, the agent path can inherit broader access than the underlying use case really needs.
The MCP Security Guide is directly relevant here because it covers OAuth-based authorisation, token passthrough, gateways, local servers, and the confused deputy problem. In public MCP deployments, those are not abstract design concerns, they are the failure modes that decide whether the proxy is a containment layer or a privilege multiplier.
How an exposed agent path becomes a broader compromise path
Once a public MCP route is reachable from outside the network boundary, the agent’s tool access can become the shortest path to enterprise systems. If an attacker can abuse the exposed interface, steal a token, or induce the agent to perform an allowed action, the compromise is no longer limited to the proxy. It can extend into the tools, data sources, and downstream systems the agent was permitted to use.
That is why agentic deployments with public MCP endpoints deserve the same scrutiny as other high-value delegation paths. The issue is not simply inbound connectivity, it is that a single exposed control point may mediate multiple privileged actions, and those actions may be difficult to distinguish from legitimate automation unless logging and policy enforcement are precise.
The Agentic AI Security Guide is a good complement because it frames tool access, identity, and blast radius as one combined problem. For public MCP paths, that combined view matters, because the dangerous condition is often not “the server is reachable” but “the reachable path can trigger enterprise-impacting actions with insufficient containment.”
Risk and Threat Considerations
Public MCP servers and reverse proxies create an attractive attack surface because they concentrate trust, reachability, and delegated authority in one path. If the proxy or server is misconfigured, an attacker may gain a stable way to probe, replay, redirect, or abuse requests that were meant to be narrowly scoped.
Failure mechanism: Weak audience validation, token passthrough, stale allowlists, or proxy trust confusion can let a request arrive with more authority than the original design intended, turning a remote entry point into a privilege expansion path.
Impact: The likely result is broader compromise of tools, data, or enterprise systems reachable by the agent, plus a larger monitoring and patching burden for defenders who now must secure the public path as well as the downstream targets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Public MCP paths can amplify agent privilege beyond intended scope. |
| ASI02 — Tool Misuse | Public MCP servers expose tool invocation paths that attackers can abuse. | |
| ASI07 — Insecure Inter-Agent Communication | Proxy-mediated agent traffic can weaken trust boundaries and request integrity. | |
| Recommendation — Enforce per-action authorization to stop exposed agent paths from inheriting excess privilege. Restrict tool access to approved actions and validate each invocation server-side. Authenticate and integrity-protect inter-agent requests across public and proxied paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Public MCP deployments depend on secure token handling and credential lifecycle. |
| AC-6 — Least Privilege | The core risk is excess authority on an externally reachable agent path. | |
| Recommendation — Rotate, scope, and revoke credentials used by public MCP and proxy components. Limit exposed agent pathways to the minimum permissions needed for each task. | ||
Practitioner Guidance
What to verify: Confirm that the proxy, the MCP server, and the downstream tool chain all agree on who the caller is, what audience each token is meant for, and which actions are allowed. If any one layer can silently forward or reinterpret authority, treat the design as over-trusted.
Decision rule: If the deployment needs public reachability, keep the exposed MCP surface as narrow as possible and require per-request policy checks rather than network location as the main control. If you cannot explain how a public request stays bounded after it passes the proxy, the design is not ready for production use.
Practitioner takeaway: Public MCP paths are risky because they convert an integration detail into a trust boundary, so the goal is not just to hide the server, but to prove that exposure cannot widen privilege or obscure attribution.
