Sandbox Isolation

---

These controls also apply to higher-level abstractions like Scaling Groups, which share the same isolation primitives.

---

​

Isolation with gVisor

Every sandbox runs under gVisor, a container runtime that intercepts application system calls through a user-space kernel. Unlike traditional containers that share the host kernel directly, gVisor interposes a second layer of defense:

┌────────────────────────┐
│   Application process  │
├────────────────────────┤
│   gVisor (Sentry)      │  ← intercepts syscalls
├────────────────────────┤
│   Host kernel          │
└────────────────────────┘

This means a kernel exploit in one sandbox cannot compromise the host or other sandboxes. gVisor also restricts the set of available syscalls, reducing the attack surface exposed to untrusted code — particularly important for agent workloads that execute LLM-generated commands.

Each sandbox additionally receives its own:

• Filesystem namespace. The root filesystem is ephemeral and private. Persistent storage is available through Volumes.
• Network namespace. Sandboxes have isolated network stacks. Outbound access is allowed by default; attach a network policy to restrict destinations.
• PID namespace. Processes inside a sandbox cannot see or signal processes in other sandboxes.

---

​

Multi-tenancy

Chalk enforces tenant isolation at every layer of the stack:

Layer	Mechanism
Runtime	gVisor kernel-level syscall interception per sandbox
Network	Separate network namespace per sandbox; no shared listening sockets
Storage	Volumes are scoped to the owning environment; cross-tenant access is impossible
Scheduling	Workloads from different tenants are placed on separate host nodes by default
Identity	A sandbox created with chalk_identity=True receives its own workload identity; no two sandboxes share credentials

For deployments with strict regulatory requirements, dedicated node pools can be configured so that a tenant’s workloads never share physical hardware with any other tenant.

---

​

Kernel hardening

Sandboxes restrict the syscalls and host access available to the workload by default. Control this with security_policy:

from chalkcompute import ContainerSecurityPolicy, Image, KernelPolicy, Sandbox

sandbox = Sandbox(
    image=Image.debian_slim(),
    security_policy=ContainerSecurityPolicy(kernel_policy=KernelPolicy.RESTRICTED),
).run()

kernel_policy is KernelPolicy.RESTRICTED (the default, both when security_policy is omitted and when set explicitly) or KernelPolicy.OPEN, which relaxes the sandboxing controls RESTRICTED enables. Use OPEN only for workloads that need syscalls or host access that RESTRICTED blocks.

OPEN works only on the k8s compute class.