TL;DR: HTTPS_PROXY, deny-lists, and model prompts only create policy, not enforcement, because an agent can spawn subprocesses or choose transports that bypass them, according to PipeLab. The practical boundary is below the agent process, where the kernel or cluster network policy can refuse unrouted traffic entirely.
At a glance
What this is: This analysis says agent egress protection fails when controls live inside the agent’s own runtime, and that only kernel- or cluster-enforced boundaries can prevent bypass.
Why it matters: IAM and security teams need to separate declarative policy from enforceable control when agents handle credentials, untrusted content, or internet access.
Context
The core governance gap is simple: many agent egress controls ask the process to comply with its own rules. In practice, that means environment variables, prompts, and local allowlists can be read, edited, or bypassed by the same runtime they are meant to constrain. For AI agent security, that creates a boundary problem, not just a configuration problem.
The article’s primary claim is that the enforcement layer must sit below the agent, where the agent’s own decisions no longer determine the outcome. In Linux that means UID-based firewalling or namespace isolation, and in Kubernetes it means pod-level network policy rather than container-local trust. The security question is not whether the agent can be instructed to behave, but whether the system can stop it when it does not.
Key questions
Q: What breaks when proxy settings are the main control for AI agent egress?
A: Proxy settings break down because they rely on cooperative behaviour from the same process they are supposed to constrain. An agent can clear environment variables, spawn subprocesses, or use transports that never consult the proxy. If the runtime can choose its own path, policy is not enforcement, and the control fails at the moment of bypass.
Q: Why does kernel-enforced egress matter for AI agents that handle credentials?
A: Kernel-enforced egress matters because it stops outbound traffic even when the agent runtime misbehaves or is prompted into an unsafe path. That reduces the chance that credentials, tokens, or untrusted content can leave through an unmanaged route. The important difference is that the refusal happens below the agent, where the agent cannot edit the rule.
Q: How should teams test whether agent network controls are real?
A: Teams should test the bypass path, not just the approved path. Run the agent without proxy variables, inspect subprocess behaviour, and confirm disallowed traffic is still blocked at the host or cluster layer. If a direct request succeeds, the control is only advisory, even if dashboards show that some traffic was scanned.
Q: What is the difference between policy and enforcement in agent security?
A: Policy tells a well-behaved agent what should happen. Enforcement prevents the wrong thing from happening even when the agent ignores the instruction. In practice, HTTPS_PROXY is policy, while a kernel firewall rule or NetworkPolicy is enforcement. A mature design uses both, but only enforcement survives an agent that routes around instructions.
Technical breakdown
Why HTTPS_PROXY and prompt rules are asking nicely
Environment variables, deny-lists, and system prompts are policy inputs, not enforcement points. They work only when the agent and its subprocesses choose to comply, and they fail when a process clears variables, changes transport, or invokes a library that ignores the intended route. The underlying weakness is that the control lives at the same trust level as the actor being governed. Once the agent can edit or bypass the rule, the rule becomes advisory rather than binding. Read Zero Trust for AI Agents.
Practical implication: Treat proxy variables and prompt constraints as supplemental policy, not as the mechanism that prevents outbound access.
How kernel-enforced egress changes the control model
A kernel-enforced boundary moves the decision below the agent process. On Linux, nftables rules using UID matching can drop traffic from the agent while allowing a separate proxy UID to reach the internet. Because the firewall evaluates traffic outside the process, the agent cannot opt out by changing its own configuration. In this model, the proxy becomes the only legitimate exit path, and direct egress from the agent UID is structurally blocked rather than merely discouraged. See the AI Agent Authorisation Guide.
Practical implication: Place the agent on a UID that cannot reach the internet directly and allow only the proxy identity to exit.
Why Kubernetes needs pod-level separation, not container-local trust
Kubernetes NetworkPolicy operates at the pod boundary, not the individual container boundary. That matters because an agent container and a proxy container in the same pod share one network namespace, which makes selective egress hard to enforce. If the proxy sits beside the agent, the same network path that enables inspection can also preserve outbound access. The safer pattern is to separate the proxy into its own pod and restrict the agent pod’s egress to that service endpoint only.
Practical implication: Design the proxy as a separate pod and enforce egress at the pod boundary, not inside a shared pod.
NHI Mgmt Group analysis
Policy-only egress controls create a false sense of containment: HTTPS_PROXY, NO_PROXY, prompt instructions, and local allowlists all assume the agent will continue to behave after the control is set. That assumption breaks as soon as the agent can spawn a subprocess, switch libraries, or alter its own runtime environment. The implication is that agent security cannot be judged by what the policy says if the agent can still choose the path around it.
Kernel enforcement is the real trust boundary for agent identity: The article demonstrates that the meaningful distinction is not whether an agent is configured to use a proxy, but whether the underlying system can refuse disallowed traffic. Agent authorisation only becomes meaningful when the agent’s identity is constrained at a layer below its own control plane. For practitioners, that shifts the problem from configuration integrity to architectural enforcement.
Access review processes assume the governed identity remains observable and compliant long enough to inspect: That assumption fails when a runtime can route around controls inside a single task or process tree. The implication is that identity governance for AI agents must account for execution-time escape routes, not just documented policy state.
Shared runtime trust is the wrong model for agent egress: If the agent and the proxy share the same identity or pod boundary, the control surface is too close to the actor. The article shows why a compliant dashboard can still hide partial bypass, which means security teams need to separate inspection capability from enforcement authority. Practitioners should treat visible proxy traffic as evidence of coverage, not proof of containment.
Read next: Zero Trust for AI Agents
What this signals
Runtime boundary design will become a baseline requirement for agent programmes: Teams that deploy AI agents need to assume that any control inside the agent’s own execution context can be bypassed by normal process behaviour. That means the programme conversation shifts from “what rules did we give the agent?” to “what layer can still refuse when the agent chooses otherwise?”
The practical result is a stronger separation between inspection and enforcement. Proxying, logging, and content scanning still matter, but they only become dependable when the network path is controlled outside the agent’s reach. Zero Trust for AI Agents is the right lens when the question is whether the environment can actually deny unsafe egress.
For identity teams, this is also a governance issue: the more autonomous the runtime, the less credible it is to treat in-process configuration as a durable control. Programmes that still equate observability with containment will miss the gap between what was inspected and what was actually prevented.
For practitioners
- Separate the agent identity from the proxy identity Run the agent as a distinct Linux UID or in a distinct pod so its runtime cannot inherit the proxy’s internet reach.
- Enforce egress below the agent process Use nftables or NetworkPolicy to drop traffic that does not match the allowed path, rather than relying on environment variables or prompts.
- Test the bypass, not just the policy Run a shell without proxy variables and confirm the agent UID cannot reach external endpoints directly.
- Isolate the proxy from the agent runtime Place the proxy in a separate pod or process boundary so inspection and enforcement are not controlled by the same actor.
Key takeaways
- Agent egress controls fail when they depend on the agent’s own cooperation, because subprocesses and alternate transports can bypass them without breaking the runtime.
- The article’s central evidence is architectural, not hypothetical: a kernel or cluster boundary can still stop traffic even when proxy variables and prompts cannot.
- Practitioners should move enforcement below the agent process and test the bypass path, not just the approved path, before trusting any agent networking design.
Related NHI Mgmt Group resources: Zero Trust for AI Agents · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Policy Template
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is about an agent bypassing in-process controls and exceeding its intended access path. |
| Recommendation — Constrain agent privilege so runtime choices cannot create an unsanctioned network path. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article shows how an agent or proxy identity becomes risky when it can reach the internet directly. |
| Recommendation — Reduce egress privilege for agent identities so only the proxy can reach external destinations. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification and explicit control enforcement | The piece maps to Zero Trust principles for refusing traffic below the agent layer. |
| Recommendation — Place enforcement below the workload and verify every outbound path before allowing it. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on whether an agent is actually entitled to open network connections directly. |
| Recommendation — Limit entitlements so the agent can only use the approved egress channel. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The bypass scenario affects how a compromised or misbehaving agent can move traffic and access. |
| Recommendation — Map bypassable agent traffic to credential access and lateral movement paths in detection engineering. | ||
Key terms
- Policy-only control: A policy-only control tells a process what should happen but does not physically prevent the wrong outcome. In agent security, proxy variables, prompts, and local allowlists are often policy-only because the same runtime can ignore, edit, or route around them.
- Kernel-enforced boundary: A kernel-enforced boundary is a control layer below the application that can refuse traffic regardless of what the process wants. It is materially different from configuration-based guidance because the agent cannot opt out by changing its own environment or code path.
- Agent Egress Control: Agent egress control is the governance of where an AI agent can send data, which tools it can call, and what external destinations it may reach. It is essential when agents can transform internal information into outbound requests that may leak sensitive content or trigger unintended actions.
- Proxy bypass: Proxy bypass occurs when traffic reaches an external destination without traversing the intended inspection path. For AI agents, this can happen through subprocesses, alternate libraries, or shared runtimes, which makes inspection insufficient unless enforcement sits below the agent.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org