Security

Sandbox code is untrusted. Only give it secrets and files it may read. An allowed destination can receive anything that code can access.

The application that creates sandboxes is trusted within its permissions. Cloud and cluster administrators are also trusted.

IsolationCopy Anchor Link

Kubernetes requires the gvisor RuntimeClass with a supported sandboxed handler. Accepted handlers include gVisor and Kata variants. The operator refuses an ordinary container runtime.

Users and privilegesCopy Anchor Link

The image contract is planned for the release after v3.3.40. These rules apply to builds made with the updated tools, except native Azure catalog images. See Upgrade order. All agent commands and jobs have no capabilities and use no_new_privs, which prevents gaining privileges through executable files.

AWS "internet" builds plan a gateway before it is installed. Deployment requires the prepared gateway; a missing gateway does not enable fallback startup. See the connector checks.

On AWS, GCP, and agent-backed Azure, a root image process receives Docker's default capabilities except NET_RAW. Its effective, permitted, and bounding sets are 0xa80405fb. Ambient and inheritable sets are empty. Non-root image processes have no capabilities. The root boot process also has no_new_privs.

Root can switch UIDs, change file ownership, and bind low ports. It has no SYS_ADMIN, NET_ADMIN, or NET_RAW. It cannot administer the sandbox network or perform privileged mounts in the sandbox's namespace.

Before image startup, private read-only mounts protect the agent binary and /opt/alien. Protected ancestor mounts prevent replacing them by renaming a directory. Guest root cannot overwrite these files.

Root shares the agent's PID namespace. It can signal commands and the agent, disrupting its own sandbox.

Guest root can read guest files and change other writable files. Keep secrets and control-plane credentials outside the sandbox. File ownership inside the guest does not protect data from a root image process.

These rules come from the image identity resolver, privilege drop, and platform checks.

Google's custom-image requirements say images must not require root. Alien's GCP probes passed with root on October 22, 2026. That observed behavior is not a provider guarantee.

Device accessCopy Anchor Link

AWS images using the new startup contract and Azure agent images require cgroup2 with CGROUP_BPF. Startup fails if these facilities are unavailable.

Their guest processes cannot read, write, or create block devices. This includes existing device nodes. Loop devices, raw-disk access through blkid or fdisk, and device mapper are unavailable.

Only these character devices are allowed:

The next release denies all other character devices, including existing nodes. Reads, writes, and creation fail for /dev/fuse, /dev/net/tun, /dev/kmsg, and /dev/ttyS*. Raw SCSI/NVMe character devices are also denied.

Ordinary terminal I/O and PTY allocation remain supported. Provider processes retain their own device access.

Guest processes cannot remove the device filter through bpf calls. A seccomp filter blocks those calls, including in AWS modes without a gateway. Gateway mode also blocks IPv6 sockets and io_uring calls.

See the device filter and seccomp rules.

On GCP, Alien installs neither a device filter nor a seccomp filter. Root retains MKNOD. Device access depends on the provider runtime alone.

Agent accessCopy Anchor Link

For the new image contract, control access differs by backend.

See the caller checks, file protection, and Azure token scope.

Azure transportCopy Anchor Link

Azure registry and source builds use authenticated HTTPS to the Alien agent. The binding reads a per-boot credential through Azure's native file API. A fresh boot replaces the credential. Readiness detects an unactivated boot even when public health accepts the cached token. The binding refreshes credentials, verifies the provider policy, and activates that boot.

After a 401 response, the binding checks for a changed credential or endpoint. An untyped 404 or a connection failure before delivery also triggers a refresh. The binding activates the refreshed connection and retries once.

An agent 404 containing PATH_NOT_FOUND or JOB_NOT_FOUND returns immediately. It preserves the working route and never replays the request. This also applies after a route refresh.

An unchanged 401 fails without retrying. Timeouts, broken responses, and server errors discard the cached route without replaying commands. A stalled or disconnected error body also fails without replay.

Error-body reads are capped at 4,096 bytes with a separate 60-second deadline. Oversized or incomplete bodies leave command and job outcomes unknown, without replay. An unchanged 401 releases the session cache lock before reading its body. A later operation can fetch a fresh route.

Session labels select the transport when reconnecting across upgrades or rollbacks. Unknown labels fail closed. An agent error never falls back to native exec. See the Azure transport implementation.

Saved imagesCopy Anchor Link

Saved releases retain their old behavior until rebuilt.

Native Azure sessions, including new catalog sessions, do not have the agent restrictions. See Saved releases for migration details.

Egress pathCopy Anchor Link

Guest root cannot widen provider network rules or gateway policies. Those controls run outside the sandbox. The AWS DNS exception below still applies.

For deployed "internet" sandboxes on AWS and Kubernetes:

sandbox → egress gateway → network egress → internet
             │
             ├─ per-sandbox policy
             └─ public destination checks

The gateway resolves destinations itself and checks every returned address. It rejects private, link-local, metadata, deployment, and container-network addresses. IPv6 destinations are not supported.

The gateway's own network rules also restrict outbound destinations. A gateway failure does not enable direct sandbox internet access.

The AWS agent checks its outbound path before accepting commands. Failed checks report EGRESS_PATH_UNEXPECTED.

GatewayCopy Anchor Link

The deployment runs two gateway replicas with 512 MiB each. Each release pins their image by digest. They use port 3128 for traffic and port 3129 for signed administration requests.

Policies are signed records stored in memory. There is no database. Policy writes replicate before success is returned. A sandbox without a policy record has no gateway access.

Policy storage uses half the gateway's memory limit, normally 256 MiB per replica. A full store refuses writes with SANDBOX_EGRESS_POLICY_STORE_FULL. It does not evict existing policies.

Each sandbox receives an identity token, valid for at most 24 hours. The token cannot change policy. It is installed at runtime, never baked into the image.

PermissionsCopy Anchor Link

The signing key lives in the deployment's secrets vault. Trusted workloads with sandbox management receive access to it. Never pass it to sandbox code.

On AWS internet deployments, an explicit deny prevents the deployment management identity from reading the signing key. Management can write it. Kubernetes controllers and cluster administrators remain trusted.

The gateway holds verification keys. Even a caller with the signing key cannot authorize private destinations through it.

GCP management and execute grants bind at project scope. Use separate projects where deployments need separate sandbox access. See Permissions for the complete scope rules.

Remote callers hold cloud credentials directly. Their cloud grant bounds access, including which images they can start. The SDK declaration alone cannot constrain those callers. See Remote bindings.

Instance metadataCopy Anchor Link

The cloud probes obtained no metadata credentials. These are observations from October 22 and 23, 2026, not guarantees about every metadata path.

The metadata fixture describes the identities, headers, and endpoints tested. The AWS live guard also checks open internet access without metadata credentials.

DNS on AWSCopy Anchor Link

AWS security groups do not block the VPC resolver. Guest root can use that network path if it bypasses guest-side DNS redirection. A hostname can carry data, so treat VPC DNS as a possible outbound channel.

New agents redirect DNS for the boot process, its child UIDs, and commands. Synthetic DNS answers do not mean the sandbox contacted an external resolver.

The AWS qualification procedure checks direct VPC queries separately. Its external DNS firewall closes the resolver path left open by security groups. Do not infer DNS exclusion from a gateway allowlist alone.

Allowed servicesCopy Anchor Link

The gateway checks TLS SNI or HTTP Host for hostname policies. It cannot see requests that an allowed service forwards elsewhere.

Allow only services you trust. Keep wildcard entries narrow.

Gateway failuresCopy Anchor Link

A surviving replica can continue serving existing policies when another stops. New connections sent to a stopped replica can stall until the load balancer removes it.

If every replica loses its state, deletion history is lost too. A sandbox can restore an older signed policy until a newer management write or token expiry. This can last up to 24 hours.

VerificationCopy Anchor Link

AWS, GCP, and Azure passed the boot probes with the new assemblers and runtime bindings. These runs did not cover a complete CLI release deployment.

AWS version-skew checks used actual v3.3.39 and v3.3.40 CLI metadata. Generated CloudFormation deployments passed create, non-root exec, suspend, and resume. The fixture supplied a test build role and uploaded artifact URI. It did not exercise the hosted manager release flow.

AWS packaged sessions passed suspend/resume with the same boot and protected files. GCP retained its process boot. Azure disk resume started a fresh boot. These results cover the tested configurations.

Local harness tests validate the probes. They do not establish cloud enforcement. Live results apply to the tested deployment, runtime, and network configuration.