A proxy is the simplest intermediary in an AI or MCP stack. It forwards traffic between endpoints without interpreting the payload or making policy decisions. In practice, it is useful for protocol adaptation, such as exposing local stdio services over HTTP or WebSockets, but it does not provide identity, governance, or audit controls.
Proxy as an intermediary layer
A proxy sits between two endpoints and relays traffic without taking a decision about the payload itself. That makes it useful when a stack needs translation, routing, or transport bridging, but not when it needs policy enforcement, identity checks, or audit-grade control decisions. The distinction matters because a proxy can improve reachability without increasing trust.
In AI and MCP environments, this usually means the proxy is an operational adapter rather than a governance layer. It can expose a local stdio service over HTTP or WebSockets, preserve protocol compatibility, or simplify integration boundaries, while leaving authentication, authorisation, and logging to other components.
What a proxy does and does not do
The core function of a proxy is forwarding. It receives a request, passes it onward, and returns the response. Because it does not interpret the payload, it does not inspect intent, evaluate policy, or decide whether the caller should be allowed to perform a specific action. That makes it different from gateways, policy engines, and brokers that actively mediate behaviour.
This separation is important in system design. A proxy can make two otherwise incompatible interfaces communicate, but it cannot by itself reduce privilege, validate context, or establish trust. If a security requirement depends on those outcomes, the proxy is only one piece of the path, not the control that satisfies the requirement.
Where proxies fit in AI and MCP stacks
Proxy patterns often appear when an AI tool or model interface needs to cross a protocol boundary. A local service may speak stdio, while the consumer expects HTTP, WebSockets, or another transport. The proxy bridges that mismatch so the integration can exist at all, especially in development, lab, or connector-heavy environments.
Because the proxy is deliberately thin, it is best understood as infrastructure glue. It can support interoperability and deployment flexibility, but it should not be confused with an agent runtime, an authorisation layer, or a trusted policy boundary. If the surrounding architecture needs those controls, they must be provided explicitly elsewhere.
That is why proxy placement is a design choice, not a security guarantee. If traffic passes through a proxy, the system may become easier to integrate, but not automatically safer, more accountable, or more observable.
Security implications of a non-decisioning intermediary
A proxy can still influence security posture through exposure and routing. It may expand the attack surface by making a local or internal service reachable over a broader transport, or by concentrating traffic through a single chokepoint. If the proxy is misconfigured, it may forward more access than intended even though it never makes an explicit policy decision of its own.
That is why proxying is often paired with separate control layers. In practice, teams commonly map the surrounding access and control design to NIST SP 800-53 Rev 5 Security and Privacy Controls, NIST Cybersecurity Framework 2.0, and NIST SP 800-207 Zero Trust Architecture when they need clearer segmentation, verification, and control separation around the intermediary path.
Risk and Threat Considerations
A proxy can become risky when organisations mistake transport mediation for security mediation. If callers can reach the proxy, they may inherit access to whatever lies behind it unless the upstream service, surrounding network controls, and authentication layers are doing the real enforcement work.
Failure mechanism: The proxy forwards traffic faithfully, but a weak surrounding design allows unauthorised requests, over-broad reachability, or blind relay into a sensitive backend. Misconfiguration, exposed endpoints, and trust in the intermediary rather than the protected service are the usual failure paths.
Impact: Attackers can exploit the proxy as a convenient entry point, a lateral movement bridge, or a way to reach internal functionality that was never meant to be broadly accessible. The consequence is usually not the proxy itself, but the access it unintentionally preserves.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Network Segmentation | Proxy placement affects segmentation and trust boundaries around exposed services. |
| Recommendation — Use network segmentation to constrain what the proxy can reach and what can reach through it. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | A proxy is a boundary component that forwards traffic across trust zones. |
| AC-4 — Information Flow Enforcement | Proxies affect how traffic flows between systems and where enforcement is applied. | |
| Recommendation — Implement boundary protections so the proxy does not become an uncontrolled bridge between zones. Enforce information flow rules at the points where proxy traffic enters and leaves protected systems. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero Trust treats intermediaries as insufficient without continuous verification and explicit policy. |
| Recommendation — Verify every request explicitly instead of trusting the proxy as a security decision point. | ||
Practitioner Guidance
Why practitioners should care: Treat a proxy as a routing component, not a control plane. If the architecture needs identity, policy, auditability, or privilege boundaries, those capabilities must be designed and verified outside the proxy itself.
What to watch for: The common mistake is assuming that “in front of the service” means “in control of the service.” When a proxy is used for protocol adaptation, confirm that exposure, trust, and logging are intentionally handled by adjacent layers rather than implied by the intermediary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org