> ## Documentation Index > Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # How Langy is Isolated > Langy runs each conversation as an isolated worker under a gVisor sandbox, with per-worker file and control-port walls and an L7 egress adapter; this page states exactly what each layer blocks and where the boundary is only cooperative today. Each conversation runs as a separate `opencode` worker process inside a single agent pod. gVisor is a user-space kernel that 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 pins the pod to a `gvisor` RuntimeClass by default; on a cluster without one the pod waits rather than silently dropping to the node's runtime. Any sandboxed RuntimeClass works (a Kata class on AKS, for example). Running unsandboxed takes an explicit pair, `runtimeClassName: ""` plus `acceptUnsandboxedRuntime: true`; the chart's render-time `fail` guard refuses the first value alone. You then lose the pod-to-host boundary and keep only the in-pod walls below. ## 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: | Boundary | Mechanism | Enforced by | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | | Pod to host | gVisor (`runsc`) user-space kernel; required RuntimeClass with a render-time chart guard | Kubernetes + chart | | Worker to worker (files) | Each conversation gets a distinct Unix UID and a `0700` home; homes are chowned before any secret is written; `/proc//environ` is `0400` owned by the worker UID, so a sibling UID gets `EACCES` | Linux file permissions (DAC) | | Worker to worker (control port) | Each worker gets a distinct random `OPENCODE_SERVER_PASSWORD`; a per-worker auth proxy terminates the external token and swaps in HTTP Basic upstream; a fail-closed guard refuses to start a worker whose control server does not return `401` to an unauthenticated request | Go auth proxy + opencode | | Worker to external (L7) | Per-worker egress adapter: require-TLS, per-destination throttle, the project's allow-list, an operator FQDN floor, and a TLS SNI cross-check against the CONNECT authority | Go adapter (cooperative, see below) | | Worker to external (L3/L4) | Deny-by-default `NetworkPolicy`; outbound `:443` to anywhere is off by default; RFC 1918 private ranges, CGNAT, and the cloud metadata endpoint are carved out and blocked | Container network interface (CNI) | | Worker to external (optional, hard) | Cilium `toFQDNs` on the floor, or a per-worker network namespace (ADR-033 Fix B) | Cilium / netns (planned, see below) | | Control plane to agent | `LANGY_INTERNAL_SECRET` bearer token, constant-time compared; the agent Service is ClusterIP only and never exposed outside the cluster | Go | The manager process runs as root in the container, which is load-bearing: 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 kernel implements **no netfilter**. `iptables` and `nftables` fail in every mode under gVisor, so the usual way to control a container's outbound traffic (an `iptables` OWNER-match DROP or a REDIRECT to a local proxy) is not available here. That is why Langy enforces egress at the application layer instead: a per-worker CONNECT proxy (ADR-043) 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 are dead 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 gVisor sandbox 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](/docs/self-hosting/langy/networking-and-egress) and [the GitHub App setup](/docs/self-hosting/langy/github-app). ## 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:** nothing durable lives worker-side. 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](/docs/langy/security/data-flow-and-privacy), [What Langy can do in your GitHub](/docs/langy/security/github-access), [Self-hosting: networking and egress](/docs/self-hosting/langy/networking-and-egress). ## Reference * [Data flow and privacy](/docs/langy/security/data-flow-and-privacy) * [What Langy can do in your GitHub](/docs/langy/security/github-access) * [Self-hosting Langy](/docs/self-hosting/langy/overview)