Topic starter
25/10/2026 11:07 am
TL;DR: Agent subprocesses, non-HTTP traffic, and NO_PROXY-listed services can all route around HTTPS_PROXY-only controls, according to PipeLab. Egress policy needs kernel or pod enforcement, or the process can choose a path the proxy never sees.
Editorial analysis by NHI Mgmt Group, based on content published by PipeLab: “Three Things "Set HTTPS_PROXY" Cannot Stop”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: HTTPS_PROXY-only controls are insufficient when the same agent identity can spawn subprocesses or use non-HTTP transports to bypass inspection.
Glossary terms: Proxy Hint, Kernel-Level Enforcement, NO_PROXY Exception, Transport-agnostic Egress Control
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:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: HTTPS proxy controls fail when agents can route around the kernel
This post was modified 7 days ago by NHI Mgmt Group