Isolation model
The threat model, what each tier's boundary defends against, and the compensating controls.
Threat model
The platform assumes the agent is hostile. Not that the customer is, but that the code and instructions reaching a session are attacker-influenced by construction: a model that read a web page, a document, an email or a tool result containing text written by someone who wants the agent to do something else.
Three adversaries, in order of how often they matter:
| Adversary | Capability | Goal |
|---|---|---|
| Prompt-injected agent | Everything the session's tier and policy permit | Exfiltrate data, pivot to the customer's systems, consume budget |
| Malicious customer | Full control of their own sessions, including attempting escape | Reach another tenant, reach the host, get free compute |
| Compromised dependency | Code execution inside a session | Same as above, plus persistence across sessions |
What is explicitly out of scope: physical access to a datacentre, a compromised host kernel before any workload runs, and an attacker with valid platform operator credentials and a second operator's collusion.
Boundaries by tier
| Tier | Boundary | Defends against | Does not defend against |
|---|---|---|---|
| 0 | Handler contract | Anything outside the declared tool surface | A badly designed tool handler |
| 1 | gVisor | Host kernel exploitation via syscalls | A sentry bug combined with a seccomp bypass |
| 2, 3 | MicroVM | Guest kernel compromise, host kernel reach | A KVM or VMM bug, mitigated by the jailer |
| 4 | Full VM, no co-tenancy | Everything above, plus cross-VM side channels | A KVM bug, mitigated by 1:1 placement |
Detail on the mechanisms: isolation runtimes.
Tier 0's safety is entirely a property of its tool handlers. A handler accepting an arbitrary URL, SQL string or file path hands the agent that primitive with nothing behind it. If a tool needs to express arbitrary computation, it belongs at tier 1 where there is a sandbox. See policy engine.
Defence in depth
No single control is trusted. Each layer assumes the one above it has already failed.
1 tier boundary process · gVisor · microVM · full VM 2 VMM confinement unprivileged uid, seccomp, netns, chroot, cgroup (the jailer) 3 host hardening minimal kernel surface, no module loading, measured boot 4 network isolation no route to the host; vsock only for platform traffic 5 egress chokepoint default-deny, allowlist, DNS filter, logged and metered 6 policy floor non-overridable denies: metadata endpoints, internal CIDRs 7 resource ceilings cgroup CPU, memory, disk IOPS, bandwidth per session 8 secret scoping short TTL, injected at start, never on disk 9 no reuse scratch destroyed; tier 4 VMs destroyed, never recycled 10 detection egress denial spikes, anomalous syscall patterns, placement anomalies
An attacker needs to defeat several of these in sequence to reach anything that matters. The egress chokepoint in particular means a full session compromise still has to exfiltrate through a logged, filtered, metered path.
Tenant isolation
| Vector | Control |
|---|---|
| Shared host kernel | gVisor at tier 1; hardware virtualisation at tiers 2–4 |
| Shared CPU (side channels) | Tier 4 at 1:1 with no co-tenancy; tiers never mix on a host |
| Shared memory | No shared memory between guests; per-session page allocation |
| Shared disk | Per-session logical volumes; block-level trim at teardown |
| Shared network | Per-session tap and namespace; no guest-to-guest path |
| Shared storage keys | Per-organization encryption keys |
| Shared pool instances | Claimed instances are bound to one session and destroyed after |
| Template cache | Read-only, shared, content-addressed — nothing writable is shared |
The only genuinely shared mutable resource across tenants is the physical host's CPU and memory bandwidth. That is what tier placement classes and the oversubscription ratios address, and why tier 4 — where the workload is interactive and the data is often most sensitive — runs with no co-tenancy at all.
Data protection
| State | Control |
|---|---|
| In transit, client to platform | TLS 1.3, HSTS, certificate transparency monitored |
| In transit, within the platform | mTLS between every service |
| In transit, host to storage | TLS 1.3 |
| At rest, scratch | Host full-disk encryption; per-session key at tier 4 |
| At rest, volumes and snapshots | Per-organization key, optional customer-managed key |
| At rest, recordings and profiles | Per-organization key |
| In memory | Not encrypted; guest memory is cleared before reallocation |
Customer-managed keys are available on Enterprise. Revoking the key makes every volume, snapshot and recording encrypted under it permanently unreadable, including to the platform — which is the point, and is stated in capital letters in the confirmation dialog.
Credential handling
Platform credentials never enter a guest. A session has no platform API key, no cloud credentials and no path to the instance metadata service. Guest-to-platform communication is over vsock to the node agent, authenticated by the vsock connection itself.
Customer secrets are injected, not stored.
A secret that must be long-lived — an SSH key, a cloud credential — should be exchanged for a short-lived one before injection wherever the upstream supports it.
Known residual risks
Stated plainly, because a security model that claims no residual risk is not a security model.
| Risk | Mitigation | Residual |
|---|---|---|
| gVisor sentry escape at tier 1 | Seccomp filter, unprivileged sentry, rapid patching | A sentry bug plus a seccomp bypass reaches the host kernel |
| KVM or VMM escape at tiers 2–4 | Jailer confinement, minimal device model, rapid patching | A KVM bug with a jailer bypass reaches the host |
| CPU microarchitectural side channels | Tier 4 at 1:1; microcode current; tiers never mix | Theoretical cross-VM leakage at tiers 2–3 under sustained attack |
| Malicious tool handler at tier 0 | Review, schema validation, allowlist | A customer's own badly designed handler is the customer's risk |
| Prompt injection | Default-deny egress, allowlists, confirmations, denial alerting | An agent can still misuse what its policy permits |
| Exfiltration through allowed destinations | Egress logging, volume alerting, optional TLS inspection | An allowed destination is an allowed destination |
That last row is the honest one. If a policy allows api.customer.com, a compromised agent can send
data there. Egress policy limits where data can go; it cannot limit what goes to a place you
permitted.
Vulnerability management
| Component | Patch target |
|---|---|
| Host kernel, critical | 72 hours, rolling drain |
| Hypervisor and VMM, critical | 24 hours |
| gVisor, critical | 24 hours |
| Template base images | Weekly rebuild, immediate on a critical CVE |
| Platform services | Continuous deployment, same-day for critical |
Patching that requires a host reboot is a rolling drain. Non-preemptible sessions run to the drain
deadline; preemptible ones are evicted with 30 seconds' notice and a prorated bill. Customers see
host_maintenance as the reason, and announced drains are excluded from the availability SLO.
Reporting a vulnerability
security@workspaces.build, PGP key published at workspaces.build/.well-known/security.txt.
Acknowledgement within 24 hours, triage within 72. Safe harbour for good-faith research that does not access other tenants' data, does not degrade service for others, and gives 90 days before disclosure. Bounties scale with severity; sandbox-escape findings are the top band.
Do not test against other organizations' sessions. Create your own, and tell us before you start if the testing will be noisy.