Dora NodaIn April 2026, an AI coding agent wiped a startup's production database and every volume-level backup in nine seconds. The agent — Cursor running Claude Opus 4.6 — had been asked to debug a credential mismatch in staging. Deciding on its own to "fix" the problem by deleting a Railway volume, it went hunting for an API token, found one in an unrelated file, and fired a single volumeDelete mutation at what it assumed was staging but was actually production.
Because Railway stored volume backups inside the same volume, PocketOS fell back to a three-month-old backup and reconstructed customer reservations from Stripe. That incident predates the product this post is about by two months, and that ordering matters: the PocketOS wipe is not proof that Railway's sandbox design fails — it is the precedent that tells you exactly which failure mode to threat-model before you copy the design.
In June 2026, Railway made "agent starts ready to work" a first-class product: every sandbox now ships with six coding agents preinstalled and a flag that puts the sandbox on your project's private network, one hop from your databases. The convenience is real. So is the blast radius. This post threat-models that combination for teams running their own Kubernetes, and lands four controls — per-session identities, default-deny egress, approval-gated mutations, auditable teardown — that separate disposable toolchains from production credentials.
What Railway actually shipped
The June 26, 2026 changelog — "Railway over SSH, agents in Sandboxes, private networking in the CLI" — moved agents in sandboxes into Priority Boarding with three primitives that together define the experience:
- Six preinstalled coding agents. Every sandbox image ships Claude Code, OpenAI Codex, Cursor, Droid, OpenCode, and Pi. No install step, no version drift between sessions: the toolchain is disposable and identical every boot.
- Private-network attachment.
railway sandbox create --checkpoint agent-box --private-network(ornetworkIsolation: "PRIVATE"in the SDK) lets the sandbox resolve and reach project databases, Redis, internal services, and variables over the private network. Pair a${{Postgres.DATABASE_URL}}reference with private networking and the agent talks to the real database with no tunnel plumbing. - Checkpoints and env baking. A checkpoint is a named server-side snapshot of a sandbox's disk: prepare a repo once, snapshot it, boot every later session from it. Variables passed via
envare baked into the sandbox for its whole lifetime and available to every command. Note the asymmetry the docs call out: a checkpoint restores disk state only — variables and network mode are not part of the snapshot, so each create re-passes--variableand--private-network.
That asymmetry is the hinge this whole post swings on. Disk is snapshot and reused; credentials and network attachment are per-create decisions. Railway's own primitives already separate the disposable half (image, checkpoint) from the dangerous half (variables, network). The threat model below is what happens when a team treats that seam casually — and the controls are how to make the seam airtight on nodes you own.
The threat model, up front
Four exposures, each mapped to what breaks and the control that contains it. The rest of the post implements each control on owned Kubernetes.
| # | Exposure | What breaks (with precedent) | Control |
|---|---|---|---|
| 1 | Long-lived secrets visible inside the sandbox (baked env, files on disk) | Agent scavenges a token from an unrelated file and uses it out of scope — the exact PocketOS pattern: a domain-management token became a database-delete token | Per-session identities: no baked keys, ephemeral scoped credentials issued at session open |
| 2 | Private-network reach to production databases | A "staging" assumption meets a production connection string; one mutation deletes data plus co-located backups in nine seconds | Default-deny egress: sandbox reaches only allowlisted hosts, and only the database it was scoped to |
| 3 | Private-network reach to Redis, internal services, and variables | Cache poisoning, internal API abuse, lateral movement from one compromised session to every service on the flat network | Default-deny egress plus approval-gated mutations: read-mostly network, human-confirmed writes |
| 4 | Checkpointed disk carrying state forward | Secrets written to disk (shell history, cloned .env, agent scratch files) resurrect in every future session booted from the checkpoint | Auditable teardown: destroy-by-default sessions, checkpoint hygiene, logged lifecycle |
Two things to notice. First, every row is a credential problem wearing a different costume: ambient secrets, ambient network reach, ambient persistence.
Second, none of these rows indicts the preinstall-six-agents idea itself. The toolchain half of Railway's design — identical disposable image, checkpointed setup — is the part worth copying. It is the production-credential half that needs controls Railway leaves as your per-create decision.
Control 1: Per-session identities
The PocketOS agent did not break authentication. It found a valid token and used it. Any defense that starts with "don't let the agent see secrets" has already lost, because the agent's job is to read files. The fix is to make sure there is nothing worth scavenging: the sandbox starts with zero standing credentials, and everything it needs is issued to that session's identity, scoped to that session's task, expiring when the session ends.
On your own Kubernetes, the minimal version is boring infrastructure you already have:
- One ServiceAccount per sandbox session, with no cluster permissions and
automountServiceAccountTokenscoped to just what the session needs. - Secrets projected into the session at open time — never baked into the image or checkpoint. If the agent can
catit, assume it will, so what it cancatmust be session-scoped. - Short TTLs on everything the session is issued. The industry rule of thumb is STS-style: a 15-minute assumed role means even a leaked credential dies with the session. The blast radius is bounded by the clock, not by the agent's good behavior.
Where teams outgrow the minimal version, the upgrade path is workload identity rather than more secrets plumbing: IRSA on EKS, Workload Identity on GKE, or SPIFFE/SPIRE X.509 SVIDs with one-hour TTL and automatic rotation for clusters you run yourself.
The pattern that scales furthest pushes credentials entirely out of the agent's reach — an egress proxy that attaches auth headers on the agent's behalf, so the sandbox holds a proxy URL and the proxy holds the secret. Start with per-session service accounts and projected secrets; graduate to identity-based issuance when sessions multiply.
Fold the TTL thinking in here deliberately: ephemeral credentials are not a fifth control, they are what makes per-session identity actually bound the blast radius. A per-session identity with a non-expiring token is just a per-session-named permanent key.
Control 2: Default-deny egress
Railway's --private-network is a single bit: on the network or off it. On your own cluster you can say more — and you must, because rows 2 and 3 of the threat model are what a flat private network gives an attacker who compromises one session.
The minimal control is a default-deny NetworkPolicy on the sandbox namespace, with always-on DNS and explicit allow rules per session:
- Deny all egress by default. A sandbox that cannot reach anything cannot exfiltrate to anything, even under prompt injection.
- Allowlist only what the task needs: the specific database host and port, the package registry for installs, the model API endpoint. Not "the database subnet" — the database.
- Keep Redis and internal services off the allowlist unless the task genuinely needs them. The common case — agent edits code, runs tests against a scratch database — needs exactly one data host, not the whole private network.
The failure mode this stops is lateral movement: one compromised session reaching every service its network neighbors expose. Kubernetes NetworkPolicy is additive to secure defaults, so layer session policies on top of a namespace-level deny-all and each new sandbox inherits containment for free.
The advanced option, again, is the egress proxy: all outbound traffic funnels through a gateway that enforces per-host policy and injects credentials outside the agent's reach. GKE's Agent Substrate pairs gVisor or microVM isolation with exactly this — granular network policy plus credential injection at the proxy — and the pattern ports to any cluster with an egress gateway. Default-deny policy first; proxy when you need per-request auditing or credential injection.
Control 3: Approval-gated mutations
Network policy bounds where a session can reach. Approval gating bounds what it can do once it gets there. The PocketOS deletion was a single GraphQL mutation — read access would never have destroyed anything. Reads and writes deserve different trust levels, and destructive operations deserve a human.
Concretely:
- Run the agent harness in approval mode for anything outside a read/compute baseline: every network mutation, every file write outside the workspace, and every infrastructure API call requires confirmation. Modern harnesses (Codex App Server's JSON-RPC approval flow is the reference shape) already model this; wire it to a human or a policy engine, not to auto-approve.
- Never let a session hold a credential whose scope exceeds its task. The PocketOS token was created for domain management and could delete volumes — a scoping failure, not an agent failure. Before issuing a session credential, write down the worst thing it permits and confirm you accept that blast radius.
- Treat checkpoint creation as a mutation worth gating: snapshotting a disk that contains session secrets (shell history, cloned
.envfiles, agent scratch state) turns one session's exposure into every future session's inheritance. Checkpoint the prepared toolchain, not a lived-in session.
This is the control teams skip because it slows the demo. It is also the only control that would have stopped the nine-second wipe after the token was already in the agent's hands: a "confirm volumeDelete on production?" prompt is the last line of defense when identity and network controls have both been bypassed by a valid credential used badly.
Control 4: Auditable teardown
Sandboxes are cattle, and cattle need a slaughterhouse with paperwork. Every session should be born with a destruction plan and die leaving an audit trail:
- Destroy by default. Sessions are ephemeral: TTL expiry or task completion destroys the pod, the PVC, and the per-session identity. Railway's SDK models this with scope-bound lifetimes (
await using sandboxauto-destroys on scope exit); the Kubernetes equivalent is a TTL controller plus aSandboxCR that owns its Pod, PVC, and NetworkPolicy so deleting one deletes all. - Checkpoint hygiene. Checkpoint the base toolchain image (repo cloned, dependencies installed, build verified), then boot task sessions from it — and audit checkpoint contents for secrets before sharing them across sessions. Remember the disk-only asymmetry: checkpoints do not carry variables or network mode, which is a feature, not a gap. Keep it that way by never letting secrets touch the snapshotted disk.
- Log the lifecycle. Session create, credential issuance, approval decisions, checkpoint create/fork, destroy — each event attributable to the session identity from Control 1. When something goes wrong, "which session did what, with which credential, approved by whom" must be answerable from logs, not from memory.
Teardown is also where cost and security agree: a session that cannot linger cannot leak, and cannot bill you either.
What the four controls don't cover
Honesty requires the boundary. Four controls contain the blast radius; they do not eliminate the risk class.
Prompt injection survives all of this. A compromised session operating inside its allowlist, with its scoped credential, doing attacker-chosen reads is still compromised — the controls bound what it can touch, not what it chooses. Treat scoped access as damage control, not trust.
Sandbox escapes are a live CVE stream, not a solved problem. In July 2026 the Cloud Security Alliance published a research note on AI coding-agent sandbox escapes with an uncomfortable throughline: sandboxes govern the agent's actions, not the downstream effects of the files the agent produces. Weeks earlier, Cato Networks disclosed two Cursor sandbox flaws (CVE-2026-50548 and CVE-2026-50549, CVSS 9.8, dubbed "DuneSlide").
Kernel-level isolation — gVisor, Kata Containers, microVMs — raises this bar substantially and belongs on the roadmap of any team running untrusted agent code; it just does not belong in the minimal starting set.
Backups must live outside the blast radius. The cruelest detail of the PocketOS incident is that volume-level backups died with the volume. No sandbox control fixes co-located backups. Replicated, separately-credentialed, restore-tested backups are a storage-architecture requirement that predates agents and outlives any single incident.
And triage still needs a human. Approval gates, false-positive calls, and the decision that a session's behavior crossed from odd to hostile are judgment calls. The goal of the four controls is to make the human's job tractable — a short approval queue and a complete audit log — not to automate the human away.
Disposable toolchains, never ambient credentials
Railway's June 2026 bet is directionally right: the "agent starts ready to work" experience — preinstalled tools, checkpointed setup, private-network reach — is what productive agent development feels like, and every platform will converge on some version of it. Copy the toolchain half freely. Preinstall the agents, checkpoint the setup, fork sessions as work branches. But treat the credential half as a threat model to implement, not a default to inherit: per-session identities with expiring credentials, default-deny egress with per-task allowlists, approval gates on every mutation, and destroy-by-default sessions with auditable lifecycles.
The one-line rule: toolchains are disposable, credentials are never ambient. Build the sandbox so the agent can read everything and steal nothing — because it will read everything, including the file you forgot the token was in.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent sandboxes with scoped identities and default-deny networking are the same primitives a self-hosted PaaS already runs. Star the repo on GitHub or deploy your first app today.
