Topic starter
25/10/2026 11:05 am
TL;DR: Agent egress controls failed when HTTPS_PROXY, deny-lists, and model prompts depended on the agent’s own cooperation, according to PipeLab. Kernel or cluster boundaries are what can still stop unrouted traffic when the runtime tries to route around the rules.
Editorial analysis by NHI Mgmt Group, based on content published by PipeLab: “Politeness vs Enforcement: Why "Set HTTPS_PROXY" Isn't a Security Control”.
Key questions
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.
Q: How should teams test whether agent network controls are real?
A: Teams should test the bypass path, not just the approved path.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: Policy-only control, Kernel-enforced boundary, Agent Egress Control, Proxy bypass
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kernel-enforced agent egress is the real security boundary
This post was modified 7 days ago by NHI Mgmt Group