Skip to main content
Each conversation runs as a separate worker process inside a single agent pod. When the pod runs under gVisor, a user-space kernel sits between the worker and the host kernel, so a worker that runs arbitrary shell (Langy workers spawn git, gh, and npm) has a much smaller pod-to-host escape surface than a normal container. On LangWatch Cloud the pod always runs under gVisor. Self-hosted, the chart runs the pod on the node’s normal runtime by default (runtimeClassName: ""), so it starts on any cluster. To harden, set runtimeClassName: "gvisor" and acceptUnsandboxedRuntime: false; on a cluster without that RuntimeClass, Kubernetes then rejects the pod at admission rather than silently dropping it to the node’s runtime. Any sandboxed RuntimeClass works (a Kata class on AKS, for example). See Setup. The default pair, runtimeClassName: "" plus acceptUnsandboxedRuntime: true, runs unsandboxed: there is no pod-to-host boundary beyond a normal container, only the in-pod walls below. With acceptUnsandboxedRuntime: false, the chart’s render-time fail guard refuses an empty runtimeClassName, so a hardened install cannot lose its sandbox by accident.

​
Isolation layers

Langy is isolated at several layers, from the pod boundary down to the walls between two conversations sharing one pod. Weakest to strongest: The manager process runs as root in the container, because assigning a distinct UID per worker needs CAP_SETUID, CAP_SETGID, and CAP_CHOWN. To keep the blast radius small, the container drops all capabilities and adds back only five: CHOWN, DAC_OVERRIDE, FOWNER, SETUID, and SETGID. It also sets allowPrivilegeEscalation: false and readOnlyRootFilesystem: true. It omits fsGroup, since sharing it would reopen the cross-worker file boundary, and sets automountServiceAccountToken: false because the manager makes no Kubernetes API calls.

​
Why egress is enforced at L7, not with iptables

gVisor’s network stack supports only part of iptables and nftables, so Langy does not rely on kernel firewall rules such as an iptables OWNER-match DROP or a REDIRECT to a local proxy. Egress control has to work the same way with and without the sandbox. That is why Langy enforces egress at the application layer instead: a per-worker CONNECT proxy (ADR-076) that the worker’s HTTPS_PROXY points at. It checks TLS, checks the destination against the allow-list, and cross-checks the TLS SNI against the CONNECT authority to block domain fronting. The earlier iptables-based rule and its NET_ADMIN capability were removed because they did not work under gVisor.
Isolation limits (state these to a regulated buyer).Today the per-worker Unix accounts are a sibling-process boundary, not a full per-tenant boundary. Multiple workers still share one pod (one gVisor sandbox when enabled) and one network namespace (ADR-053, Proposed). The file and control-port walls above stop one worker from reading another worker’s secrets or driving another worker’s control server, but they do not give each conversation its own kernel or its own network stack.The stock L7 egress adapter is cooperative, not mandatory. It enforces the allow-list only for traffic that goes through the proxy. A prompt-injected worker that ignores HTTPS_PROXY and dials an external IP directly on :443 is monitored, not blocked, in the stock pod.The mandatory-enforcement end states (a Cilium toFQDNs policy, or a per-worker network namespace that needs CAP_SYS_ADMIN) are designed, not shipped. Do not read this page as a claim of hard tenant isolation by default.
The defence-in-depth mitigations that are shipped today:
  • CGNAT egress deny. The 100.64.0.0/10 range is blocked at L3/L4, so a worker cannot reach the node-local link addresses that some managed Kubernetes networking uses.
  • Dropped default service-account token. automountServiceAccountToken: false; a worker that reached the Kubernetes API would have no token to present.
  • Public-subnet node placement (opt-in). You can schedule the agent pod on a node group that has no route to your private data tier, so a full escape lands somewhere with no path to your databases.
For a self-hosted install, egress is denied by default: networkPolicy.allowExternalHttps is false, so Langy cannot reach the internet at all until you enable it. Turning it on for GitHub is covered in Networking and egress and the GitHub App setup.

​
What the sandbox can and cannot reach

  • Can reach (when configured): the LangWatch API (through the per-session langwatch CLI credentials), the LangWatch AI Gateway for LLM traffic, and github.com / api.github.com / codeload.github.com when external HTTPS is enabled.
  • Cannot reach: RFC 1918 private ranges, CGNAT, and the cloud metadata endpoint. These are blocked at L3/L4 to prevent SSRF and IMDS credential theft, so the block holds regardless of what the worker attempts.
  • Reaches only through the adapter, by cooperation: any other external host goes through the L7 egress adapter, which enforces the project allow-list and the operator floor. In the stock pod that path is cooperative, not mandatory: a worker that ignores HTTPS_PROXY and dials a public address on :443 directly is monitored rather than blocked, per the limits above.
  • Does not keep at rest: the worker writes only to disposable storage. The manager wipes the sessions root on boot, and the idle reaper deletes a worker’s home once it has been idle for 10 minutes, so clones and injected credentials do not survive.
Also check: Data flow and privacy, What Langy can do in your GitHub, Self-hosting: networking and egress.

​
Reference

Last modified on October 12, 2026