> ## 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. > ## Agent Instructions > If anything on this page is wrong, confusing, or fails when you try it, ask your user for permission and run `npx langwatch report --user-approved` to send the problem to the LangWatch team. No login is needed and secrets are redacted locally. `npx langwatch report --help` has the details. # How Langy is Isolated > Langy runs each conversation as an isolated worker with per-worker file and control-port walls and an L7 egress adapter, under gVisor on LangWatch Cloud and optionally when self-hosted. This page states what each layer blocks and where the boundary is cooperative rather than mandatory today. 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](https://langwatch.ai/docs/self-hosting/langy/setup.md#hardening-a-sandboxed-runtime). 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: | Boundary | Mechanism | Enforced by | | - | - | - | | Pod to host | gVisor (`runsc`) user-space kernel when a sandboxed RuntimeClass is set. Optional by default; required by a render-time chart guard once `acceptUnsandboxedRuntime: false` | 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) | A worker binds no listener at all. The manager drives it over a private stdio pipe pair, so there is no port for a sibling worker to reach | Go manager | | 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, 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. > [!WARNING] > > **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. > [!NOTE] > > 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](https://langwatch.ai/docs/self-hosting/langy/networking-and-egress.md) and [the GitHub > App setup](https://langwatch.ai/docs/self-hosting/langy/github-app.md). ## 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. > [!NOTE] > > **Also check:** [Data flow and privacy](https://langwatch.ai/docs/langy/security/data-flow-and-privacy.md), [What Langy can do > in your GitHub](https://langwatch.ai/docs/langy/security/github-access.md), [Self-hosting: networking and > egress](https://langwatch.ai/docs/self-hosting/langy/networking-and-egress.md). ## Reference * [Data flow and privacy](https://langwatch.ai/docs/langy/security/data-flow-and-privacy.md) * [What Langy can do in your GitHub](https://langwatch.ai/docs/langy/security/github-access.md) * [Self-hosting Langy](https://langwatch.ai/docs/self-hosting/langy/overview.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.