HTTPS proxy controls fail when agents can route around the kernel

At a glance

What this is: This article explains three concrete ways AI agents can bypass HTTPS_PROXY-based egress controls and shows why kernel-level enforcement is the real control boundary.

Why it matters: It matters because identity and access teams cannot treat application-layer proxy hints as containment for autonomous or semi-autonomous agents when the underlying process identity can still reach the network directly.

Context

HTTPS_PROXY is a policy hint, not an enforcement boundary. For AI agents, that distinction matters because a process can spawn children, change transports, or reach internal services that were added to proxy exception paths without the kernel ever applying the intended restriction.

The governance problem is not only whether an agent is supposed to use a proxy, but whether the runtime can bypass the proxy through ordinary Linux behaviour. In that model, egress control has to be tied to process identity and network path enforcement rather than to environment variables alone.

Key questions

Q: What breaks when AI agent egress depends on HTTPS_PROXY instead of kernel enforcement?

A: The control breaks because HTTPS_PROXY is only a client-side hint. A subprocess, alternate transport, or NO_PROXY-listed relay can route around it without violating the process's apparent behaviour. If the kernel does not deny direct egress from the agent identity, the proxy is advisory rather than enforceable.

Q: Why do proxy exceptions create risk for AI agents in Kubernetes and Linux environments?

A: Proxy exceptions widen the trust boundary to every service that can bypass inspection or forward traffic externally. In Kubernetes, a NO_PROXY-listed service can become a relay, while on Linux a spawned process can bypass the intended route. That turns convenience settings into hidden outbound paths unless egress is enforced below the application layer.

Q: How can security teams know whether an agent egress control is actually working?

A: They should test the exact bypass paths the article describes, including subprocesses with cleared environments, non-HTTP transports, and requests to NO_PROXY destinations. If any of those succeed when blocking was expected, the control is not enforced. A working design blocks traffic at the kernel or network-policy layer, not just in client code.

Q: What should teams do when an agent can choose different network paths?

A: They should move from policy hints to enforced boundaries. That means constraining the agent identity itself, then allowing only the network destinations that are explicitly required for the task. When the runtime can choose its own route, the safe answer is to make every unapproved route unreachable.

Technical breakdown

Subprocess environment clearing bypasses proxy hints

A child process inherits the parent process identity, but not necessarily its environment. If the parent spawns a subprocess with env cleared, HTTP libraries in that subprocess never see HTTPS_PROXY and will connect directly. The kernel then treats the traffic as ordinary outbound activity from the same UID, so the proxy policy exists only as a convention. This is a classic example of application-layer policy being weaker than kernel-level control. The fix works because the decision moves from the process to the network boundary: deny direct internet egress for the agent UID and allow only loopback to the proxy. See the AI Agent Authorisation Guide. See the AI Agent Authorisation Guide.

Practical implication: bind agent egress to UID or pod identity, not to inherited environment variables.

Non-HTTP transports ignore HTTPS_PROXY entirely

HTTPS_PROXY only affects cooperative HTTP and HTTPS stacks. Raw TCP sockets, UDP, ICMP, QUIC over UDP, and direct DNS queries can all bypass it because the variable is not consulted by those transports. That means an agent can exfiltrate data through lower-level networking primitives even when the HTTP path appears constrained. The important lesson is that proxy-based controls are protocol-selective, while kernel and network-policy controls are transport-agnostic. When the agent can choose its transport, the proxy is not the control point. The control point has to sit below the transport choice. See Zero Trust for AI Agents. Read Zero Trust for AI Agents.

Practical implication: assume an agent will use non-HTTP paths unless the kernel blocks them all.

NO_PROXY creates a second trust boundary inside the cluster

NO_PROXY is intended to keep internal service calls from hairpinning through a proxy, but it also creates a bypass surface whenever a listed internal service has its own outbound access. If an agent can call an internal LLM gateway, MCP server, or logging service that forwards traffic externally, the proxy never sees the original request. In practice, that means the boundary has moved from the proxy to every service included in the bypass list. The design choice is not wrong by itself, but it must be treated as a trust expansion, not a convenience setting. See the AI Agent Identity Security Buyer's Guide. See the AI Agent Identity Security Buyer's Guide.

Practical implication: audit every NO_PROXY destination for outbound reach before you trust it as an internal-only exception.

NHI Mgmt Group analysis

Proxy hinting is not egress governance: HTTPS_PROXY and NO_PROXY describe how cooperative clients should behave, but they do not define what the runtime is allowed to do. That distinction is fatal when the same process identity can spawn children or choose alternative transports. The implication is that identity governance for agents must be anchored in enforced network control, not in client obedience.

The control failed because enforcement sat above the attack surface: The article shows three bypass shapes that all live below or beside the proxy abstraction. A subprocess can clear inherited variables, a lower-level socket can skip HTTP client logic, and a service on the NO_PROXY list can become a relay. Practitioners should read this as a boundary-placement problem, not a proxy-configuration problem.

Identity is the right enforcement primitive here: The kernel can distinguish source identity in a way the application layer cannot. That makes UID or pod identity the correct control anchor for agent egress, because the policy must follow the process regardless of what code path it uses. This is where NHI governance meets runtime enforcement: the identity must be constrained where the traffic actually leaves the host.

Runtime boundaries collapse when policy depends on cooperation: The broader lesson is that agent containment fails whenever a control assumes the subject will politely use the intended path. Once the subject can choose subprocesses, transports, or internal relays, the policy becomes advisory. Practitioners need to treat every agent egress control as suspect until it is proven at the kernel or network-policy layer.

Read next: Zero Trust for AI Agents

What this signals

Policy hints will keep failing wherever the runtime can improvise: The next governance step is to assume that agents will find the weakest layer in the path, whether that is a cleared environment, a raw socket, or a trusted internal service. Egress control has to be enforced at the same layer that owns the traffic, not at the layer that merely recommends behaviour.

Kernel-bound containment is the durable pattern: Once the agent identity is fenced at the host or pod boundary, transport choice stops mattering in the same way. That shifts programme design from reviewing proxy settings to proving that direct outbound paths do not exist outside the approved inspection route.

For practitioners

• Move agent egress enforcement into the kernel path Deny direct internet access from the agent UID and allow only loopback to the proxy, so child processes inherit the same restriction.
• Treat NO_PROXY as an exception list that needs review Inventory every hostname or domain in NO_PROXY and verify whether any of those services can reach external systems on the agent's behalf.
• Test non-HTTP transports explicitly Check raw TCP, UDP, DNS, QUIC, and ICMP paths from the agent runtime, because HTTP proxy hints do not cover them.
• Separate proxyable and non-proxyable workloads Place agents that need inspection into their own pod or UID boundary and enforce NetworkPolicy or nftables rules around that boundary.

Key takeaways

• HTTPS_PROXY-only controls are insufficient when the same agent identity can spawn subprocesses or use non-HTTP transports to bypass inspection.
• NO_PROXY entries create a trust expansion that can hide relay paths inside the cluster unless outbound reach is reviewed for every exception.
• Enforced egress at the kernel or pod boundary is the control that changes the outcome, because it constrains the process rather than trusting its client library.

Related NHI Mgmt Group resources: Zero Trust for AI Agents · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide

Key terms

• Proxy Hint: A proxy hint is a setting that tells cooperative clients where to send traffic, but it does not physically block alternate routes. In agent environments, it is useful for preference, not enforcement, because subprocesses and lower-level transports can ignore it entirely.
• Kernel-Level Enforcement: A control pattern that intercepts network or credential handling below the application layer. It reduces exposure because the user-space process never needs to hold the secret material directly, which lowers the chance of leakage through memory inspection, logs, or process tools.
• NO_PROXY Exception: A NO_PROXY exception is a destination that a client is told to access directly rather than through a proxy. In identity and runtime governance, it becomes a trust expansion point because any exempted service with outbound reach can act as a relay or hidden path.
• Transport-agnostic Egress Control: Transport-agnostic egress control is a design that blocks or permits network access regardless of whether the traffic uses HTTP, TCP, UDP, DNS, QUIC, or ICMP. It matters for agents because choosing a different protocol is often the easiest way to bypass client-side policy.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.