Hardware-level isolation
Each sandbox runs in a dedicated Firecracker microVM. That means your sandbox has its own kernel — not a container sharing a kernel with other workloads, but a full hardware-virtualized Linux kernel running inside a microVM. It also has its own filesystem and its own network namespace.Its own kernel
The kernel inside your sandbox is completely separate from the host kernel and from every other sandbox’s kernel.
Its own filesystem
Each sandbox starts from a clean snapshot of its template. No filesystem state is shared between sandboxes.
Its own network namespace
Sandboxes cannot reach each other’s processes or the cluster network directly. All external access is routed through the gateway.
Sandboxes share nothing
Two sandboxes from the same template start from identical snapshots, but from that point on they are completely independent. There is no shared memory, no shared filesystem, and no network route between them. A process running in sandbox A cannot observe, reach, or influence anything in sandbox B, even if both belong to the same organization and both started from the same template.Capability tokens
Accessing a sandbox’s data plane — running commands, reading and writing files, connecting to an exposed port — requires a short-lived capability token. Tokens are signed by the control plane and scoped to a specific sandbox and a specific epoch. They are not reusable across sandboxes, and they are not permanent. Here is how the token lifecycle works in practice:1
You authenticate to the control plane
Your SDK uses your API key or OIDC bearer token to talk to the control plane. This credential never goes anywhere near the sandbox itself.
2
The SDK obtains a capability token
When you create or resume a sandbox, the control plane mints a short-lived capability token scoped to that sandbox and epoch. The SDK stores it on the sandbox handle.
3
The token is used for data-plane access
Command runs, file operations, and private port access all carry the capability token, not your API key. The node runtime verifies the token before allowing any operation.
4
Tokens are refreshed automatically
When a token expires, the SDK mints a fresh one and replays the request. You never have to manage token expiry in your own code.
Epoch scoping
Pausing and resuming a sandbox creates a new epoch. Capability tokens from before the pause are invalid after the resume. This is intentional: it ensures that a token obtained before a pause cannot be replayed after the sandbox restarts in a new state. The SDK automatically obtains a new token afterresume(), so this is transparent unless you hold a token outside the SDK’s lifetime.
A sandbox handle returned by
sandboxes.get() or sandboxes.iterate() does not carry a pre-minted token. Call sandbox.mintToken() (TypeScript) or sandbox.mint_token() (Python) before running commands on such a handle.No credentials cross the guest boundary
The single most important security property: no platform credential ever reaches code running inside the sandbox. Your API key never goes to the node. Capability tokens are verified at the node boundary and then stripped before anything is forwarded to the in-guest agent. The code running inside your sandbox has no way to observe a token that would let it impersonate you or access other sandboxes. This is enforced structurally. The node runtime’s job includes verifying tokens and removing them before forwarding to the guest — the guest never receives a token to inspect, replay, or exfiltrate.Port exposure security
Every port inside a sandbox is private by default. Accessing a private port requires a valid capability token. No unauthenticated request can reach a private port, no matter what URL someone constructs. Making a port public is an explicit action, per port, that you take:TypeScript
Python
Organization isolation
Sandboxes and templates are owned by your organization. Other tenants on the same FissionPlane installation cannot list, access, or influence your sandboxes, even if they know a sandbox ID. The control plane enforces organization boundaries on every API call.Dedicated node pools
Sandbox nodes are labelled and tainted in Kubernetes so that only FissionPlane sandbox workloads run on them. If a workload were somehow to escape its microVM, it would land on a node that runs no other tenant’s workloads — limiting the blast radius to the nodes specifically set aside for sandbox execution.The guest-hostile assumption
FissionPlane treats everything that comes from inside a sandbox as untrusted input. The guest agent that executes commands inside the microVM is assumed to be under the control of an adversary. Every message from the guest to the host is size-limited, rate-limited, and strictly validated. The guest never provides a value that the host uses to name a file, address a peer, or perform a privileged operation.This assumption exists because the sandbox occupant has root inside the guest. They can read memory, replace binaries, and forge messages from the guest agent. The only meaningful isolation boundary is the hardware virtualization boundary of the microVM itself.