Topic starter
25/10/2026 11:07 am
TL;DR: HTTPS_PROXY-only egress controls for AI agents can be bypassed through subprocess environment clearing, non-HTTP transports, and NO_PROXY-listed internal services, according to PipeLab, because the kernel does not enforce the policy. The boundary only holds when egress is denied at the kernel layer or per pod, making enforcement a source-of-truth problem rather than a client-library problem.
Editorial analysis by NHI Mgmt Group, based on content published by PipeLab: “Three Things "Set HTTPS_PROXY" Cannot Stop”.
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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →