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.
Expanded Definition
In NHI and agentic AI environments, a proxy is a forwarding layer that relays requests between a client and a target service without inspecting the payload as a policy engine would. It is often used to translate protocols, for example when a local stdio tool is exposed over HTTP or WebSockets, or when a service needs transport normalization across runtime boundaries.
Definitions vary across vendors, but the critical distinction is that a proxy moves traffic while a governance component decides whether that traffic should be allowed. A proxy may preserve connection metadata, headers, or routing context, yet it does not by itself establish identity, enforce least privilege, or create durable audit evidence. For that reason, it should be understood as an infrastructure primitive, not an access-control control plane. In practice, teams often compare it with gateways, brokers, and policy enforcement points; those adjacent concepts may inspect, enrich, or block traffic, while a proxy simply passes it along.
For broader identity and trust context, NIST’s NIST Cybersecurity Framework 2.0 is useful for mapping the surrounding controls that a proxy does not provide. The most common misapplication is treating a proxy as a security boundary, which occurs when engineers assume forwarding infrastructure alone can replace authentication, authorization, and logging.
Examples and Use Cases
Implementing proxies rigorously often introduces latency, debugging complexity, and another component to operate, so organisations must weigh transport flexibility against added failure modes.
- A development team exposes a local agent tool over WebSockets through a proxy so remote orchestration clients can reach it without rewriting the tool itself.
- An integration layer forwards MCP traffic from a workstation to an internal service, preserving protocol compatibility while another layer performs policy checks.
- A runtime proxy normalizes requests between heterogeneous services so an AI agent can call multiple back-end tools through one transport shape.
- An enterprise uses a proxy to centralize egress routing for agent traffic, but still relies on a separate enforcement layer for identity verification and authorization.
- Security teams review how proxy placement affects visibility, because Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts.
Where protocol adaptation is required, a proxy can make legacy and local services usable in modern agentic stacks, but the transport shortcut should not be confused with governance. Standards-based identity work such as the NIST Cybersecurity Framework 2.0 still needs to wrap around it.
Why It Matters in NHI Security
Proxy design affects how much of the NHI attack surface is visible, attributable, and controllable. If a proxy sits between an AI agent and a sensitive tool, teams may assume the relay itself is monitoring access, but forwarding alone does not detect credential misuse, enforce JIT access, or prevent a compromised agent from replaying requests. That gap is especially dangerous when proxies are deployed as convenience layers in front of service accounts, API keys, or MCP endpoints.
NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which means a proxy can easily become a high-trust transit path for over-permissioned identities if governance is absent. The same guide notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, underscoring how quickly a simple forwarding layer can become part of a broader compromise when secrets and identity controls are weak.
For security teams, the operational question is not whether a proxy forwards traffic, but whether the surrounding architecture authenticates, authorizes, and logs what flows through it. Organisations typically encounter the limits of a proxy only after a tool is abused, at which point proxy placement becomes operationally unavoidable to address.
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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Proxies can hide or expose NHI traffic paths, affecting visibility and control. |
| NIST CSF 2.0 | PR.AC-3 | Proxy forwarding must sit inside stronger access control and identity enforcement. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust treats network path components like proxies as untrusted until verified. |
| OWASP Agentic AI Top 10 | AI-04 | Agentic stacks often use proxies for tool transport, which can obscure unsafe request flow. |
| NIST AI RMF | AI RMF addresses system context and governance around components like proxies. |
Place proxies behind explicit verification and segmentation controls in Zero Trust designs.
