Problem Statement
Problem
In corporate/enterprise Kubernetes clusters, nodes do not have direct internet access. All outbound traffic must go through a corporate forward proxy (e.g., Squid, Zscaler). The supervisor's L7 proxy does not respect HTTP_PROXY, HTTPS_PROXY, or NO_PROXY environment variables, causing all external API calls from agents (e.g., Tavily search, Stripe, external MCP servers) to fail with connection timeouts.
Current Behavior
- The agent process has HTTP_PROXY=http://10.200.0.1: pointing to the supervisor
- The supervisor intercepts outbound traffic and applies policy
- After policy approval, the supervisor connects directly to the destination
- In proxy-required environments, this direct connection fails (no route to host / connection timeout)
Proposed Design
Desired Behavior
The supervisor should:
- Read HTTPS_PROXY / HTTP_PROXY / NO_PROXY from its own environment variables
- When policy allows an outbound connection, route it through the configured corporate proxy using HTTP CONNECT
- Respect NO_PROXY for cluster-internal destinations (e.g., *.svc.cluster.local, 10.96.0.0/12)
- Ideally configurable per-sandbox via the Sandbox CRD:
spec:
podTemplate:
spec:
containers:
- name: agent
env:
- name: HTTPS_PROXY
value: "http://proxy.corp.com:8080"
- name: NO_PROXY
value: "*.svc.cluster.local,10.0.0.0/8"
Alternatives Considered
Use Case
Large enterprise deployments where all Kubernetes clusters are behind corporate proxies. Without this, agents cannot access any external API (search tools, SaaS APIs, external MCP servers) even when policy allows it.
Workaround
None currently viable. We've explored adding a second proxy container but the supervisor rewrites the agent's proxy env to point to itself, overriding any custom configuration.
Agent Investigation
No response
Checklist
Problem Statement
Problem
In corporate/enterprise Kubernetes clusters, nodes do not have direct internet access. All outbound traffic must go through a corporate forward proxy (e.g., Squid, Zscaler). The supervisor's L7 proxy does not respect HTTP_PROXY, HTTPS_PROXY, or NO_PROXY environment variables, causing all external API calls from agents (e.g., Tavily search, Stripe, external MCP servers) to fail with connection timeouts.
Current Behavior
Proposed Design
Desired Behavior
The supervisor should:
Alternatives Considered
Use Case
Large enterprise deployments where all Kubernetes clusters are behind corporate proxies. Without this, agents cannot access any external API (search tools, SaaS APIs, external MCP servers) even when policy allows it.
Workaround
None currently viable. We've explored adding a second proxy container but the supervisor rewrites the agent's proxy env to point to itself, overriding any custom configuration.
Agent Investigation
No response
Checklist