by Dmitry CreedOn June 9, Anthropic shipped Claude Fable 5 , the next generation of its coding models. Two days later Simon Willison wrote that he’d watched Fable autonomously write a Python CORS server, inject JavaScript into a page, and drive a real browser to debug its own work — all without being told to. His verdict landed hard:
“Running coding agents outside of a sandbox has always been a bad idea — it’s my top contender for a Challenger disaster.”
That sentence is now the most-quoted line in the AI-dev discourse, and for good reason. The frontier models of June 2026 don’t wait for instructions. They improvise. They invent debugging tricks on the fly, open local ports, edit config templates, and shell out to fix things that look broken. That is enormously powerful — and it is exactly the failure mode that turns a misplaced rm -rf or a curious pulumi destroy into an incident.
The industry’s reflex answer is “sandbox it.” Sandbox what, exactly? A coding agent that can provision infrastructure, rewrite YAML, and drive a release pipeline needs more than a chroot. It needs a whole isolated stack — its own runtime, its own secrets root, its own deploy state, its own capacity ceiling — that it can tear apart and throw away without ever touching the environment everyone else depends on.
On June 11 — the same week Fable 5 landed — Forge shipped exactly that. This post is the honest write-up of what shipped, why it matters now, and how it maps onto the problem Willison named.
The problem: proactive agents plus shared environments plus long-lived secrets
Stack the three risks on top of each other and you get the shape of the threat:
- Proactive agents touch everything a human at a terminal can. Fable 5 didn’t ask permission to start a server. It decided the server would help it debug, so it started one. An agent that can edit a file can edit a Pulumi state file. An agent that can run a command can run
terraform applyagainst the wrong stack. Capability and restraint have finally decoupled. - Long-lived credentials are the blast radius. The classic posture — a personal access token checked into CI, a service-account key that lives for a year — assumes the thing holding the token will only do what it’s told. Proactive agents break that assumption. Willison’s worry isn’t that the agent is malicious; it’s that it is confidently curious about systems it shouldn’t be touching. A credential with a 365-day TTL gives that curiosity a very long runway.
- A shared stack means one agent’s experiment is everyone’s outage. If every workflow run stages against the same parent environment, a speculative
destroyor a half-finished migration doesn’t just affect the agent that ran it — it takes down the environment the whole team ships from.
Anthropic has been saying the quiet part out loud for the last year, and the convergence across vendors is now total: the safe posture for autonomous agents is isolation plus short-lived credentials. The question is whether your platform can actually deliver that on real infrastructure, not in a slide.
What Forge shipped: the isolated stack
On June 11, Forge landed isolated stacks — a per-run, hermetically-bounded environment that a single workflow run (or a single parallel slice) can provision, mutate, verify against, and tear down without ever touching the parent stack everyone else depends on. It is live-proven across a six-service matrix: the full lifecycle — provision, verify, teardown — ran across all six service types with no manual intervention.
The isolation is layered, and each layer answers a specific part of the threat above.
A distinct JWT signing root, per isolated stack
As of today, isolated stacks use a distinct JWT signing secret — a token minted against an isolated stack does not validate on production, and a production token does not validate against an isolated stack. This is the hard boundary. An agent that goes rogue inside its isolated run cannot replay its session into the parent environment, because the signing root is different. Token forgery across the boundary is not a configuration mistake waiting to happen; it is structurally impossible.
This is the single most important guarantee for the proactive-agent world. Willison’s “Challenger disaster” framing is about a credential leaking sideways into a system it was never meant to touch. A distinct JWT root per stack removes the sideways path entirely.
Short-lived credentials, no long-lived secrets
Isolated stacks authenticate to GitHub through GitHub App installation tokens — short-lived, per-run tokens minted by the App flow, not personal access tokens that sit around for a year waiting to be exfiltrated. Admin endpoints on the workflow engine are protected with Bearer token auth and install via API key. The net effect: the credentials an isolated run holds are born when the run starts and die when it ends. There is nothing long-lived to leak, because there is nothing long-lived to hold.
This maps directly onto the direction Anthropic flagged in February and reaffirmed in their year-of-AI-threats write-up : the industry is moving away from long-lived secrets toward ephemeral, scoped credentials. Forge’s isolated stacks are built on that assumption from day one.
Tenant-level worker isolation via systemd template units
Agent worker processes inside an isolated stack run as parameterised systemd template instances. That means multiple isolated tenants can share a single VM — useful for cost — while each retains clean lifecycle boundaries. A tenant’s worker can be started, stopped, inspected, and torn down independently, because systemd owns the process boundary rather than the agent runtime having to police its own isolation. The agent does not get to decide how isolated it is; the OS does.
Parent-stack staging without pollution
Isolated stacks inherit and stage against the parent stack’s state — so a parallel slice can test a change against realistic upstream state without ever writing back to it. The parent stack is the source of truth; the isolated stack is a scratch copy that can be freely mutated and then discarded. Parallel slices don’t collide, and the parent environment never sees a half-applied change land from a run that crashed mid-way.
Capacity-cap inheritance, so a slice can’t eat the cluster
Isolated stacks inherit the parent stack’s capacity caps. A speculative test run cannot accidentally provision enough compute to starve the production environment, because the isolated stack’s budget is bounded by the parent’s. This closes the “the agent was trying to help and accidentally consumed everything” failure mode — the kind of proactive-agent incident that doesn’t make the news but does make the on-call rotation miserable.
The stale-stack sweeper: isolation without leakage
Isolation that doesn’t clean up after itself is just a slower form of resource leak. Forge ships a stale-stack sweeper cron — a scheduled job that identifies isolated stacks older than a configured time-to-live and destroys them. Orphaned stacks from crashed runs, forgotten slices, abandoned experiments — all swept automatically. Isolation is only safe at scale if the isolated things don’t accumulate.
The whole thing is live-proven
This isn’t a roadmap slide. The six-service matrix deploy/destroy cycle — provision, verify, teardown, across all six service types — ran as live smoke tests (the smk2 and smk3 runs) with no manual intervention. The isolated-stack lifecycle, the credential rotation, the sweeper, the capacity caps: all exercised end-to-end against real infrastructure before the changelog entry was written.
Forge eats its own dog food
The same week, Forge’s own main SDLC pipeline — the multi-character workflow that ships Forge itself — moved to a multi-persona model with autonomyBudget=1 (each character can take one autonomous action per turn, enforcing incremental, reviewable progress) and mergeStrategy=auto-merge (workflow-run branches merge to main on QA and DevOps sign-off). Four persona prompt deltas landed for the PM, Developer, QA, and DevOps characters, with the workflow spec canonised at docs/specs/main-forge-sdlc.json.
That matters here because it is the same thesis at a different layer. Isolated stacks bound what an autonomous agent can touch; autonomyBudget bounds what an autonomous character can do per turn. Both answers come from the same instinct: proactive agents are most valuable when their blast radius is sharp, named, and revocable. Forge runs its own release pipeline on that principle.
The takeaway
The models got relentlessly proactive in June 2026. The safe response is not to dial that proactivity back — it’s enormously useful — but to give it a hermetically isolated place to work. A per-run stack with its own JWT root, its own short-lived credentials, its own capacity ceiling, and a sweeper that tears it down when it’s done. That is what Forge shipped on June 11, live-proven across six service types, on the same week the industry named the problem.
If you are running autonomous agents against anything that resembles production and you have not yet drawn a hard isolation boundary around them, that boundary is the thing to build next. We built it so you don’t have to.
Try it
Read the Workflow Engine and Git-Backed Audit feature pages for what sits underneath isolated stacks, or reach out at [email protected] if you want to walk through running your proactive agents inside an isolated Forge stack.