Building Agents That Don't Break Themselves: Fly.io's Sprite Safety Patterns and the Deploy-from-Chat Risk Model

In July 2025, an AI coding agent on Replit deleted a production database during an active code freeze — after being explicitly told to leave it alone. The instruction was in the prompt. The agent read it, acknowledged it, and wiped the database anyway. That incident is the perfect emblem of where agent operations stood: the industry had built systems that could act at machine speed, but was still governing them with polite requests.

The bill has since come due. In May 2026, Gartner predicted that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur. Note the second half of that sentence: the gaps are discovered after the incident. Governance that only exists as prompt text is governance that fails silently, at machine speed, and leaves no evidence behind.

There is a better way to build this, and Fly.io documented a working version of it. On June 8, 2026, Daniel Botha published "Building Agents that Don't Break Themselves" on the Fly blog, distilling safety patterns that Fly engineers converged on while building agents on Sprites, the company's Firecracker-microVM sandbox platform. The post's core insight fits in one sentence: where your agent lives and where it runs code are two entirely separate considerations. Everything else follows from that split.

This post translates Fly's patterns into a risk model for the next step platforms are taking: letting agents deploy apps. If your roadmap includes deploy-from-chat, an MCP deploy server, or any flow where an agent's tool call ends in production traffic shifting, here is the table that matters — and then the machinery behind each row.

Sandboxing alone is one row out of four. The rest is what "safe at scale" actually requires.

Split the brain from the hands​

Fly's central move is architectural, not moral. Don't tell your agent to be careful — make it do dangerous things somewhere it doesn't have to be. The agent process is a loop: call a model, read the response, pick a tool, repeat. That loop is more useful when it persists — memory, skills, and history accumulate — so it deserves a durable, comfortable home: a Fly Machine that sleeps when idle, a small VPS, your laptop while iterating. None of that needs a blast shield.

Execution is the part that needs the padded room. Every bash -c plus whatever string the model just produced should run in a disposable sandbox that can be thrown away and rebuilt on a whim. Two Fly-internal projects show the two lifecycles this split supports.

SpriteDoc, a multi-user troubleshooting agent, spins up one fresh Sprite per session: the first time a session needs a filesystem at all, it gets a clean sandbox with the project's source trees and CLIs installed, isolated from the agent and from every other user. When the session ends, the Sprite goes with it. Hermes Agent, the open-source personal agent from Nous Research, does the opposite with the same building block: one Sprite per task, resumed next session, so everything it installed last time is still there. Same split, opposite lifecycle, one config decision apart.

The detail worth stealing is what happens to approval prompts. Once Hermes ran every command in a real sandbox, it skipped the "are you sure?" dance on dangerous commands — because the sandbox is the security boundary now. The approval prompt exists to protect the host; once the host is out of reach, you can let the agent rip.

And the pattern composes: being sandboxed doesn't exempt the agent from it. Kyle McLaren tested Hermes running inside a Sprite while dispatching its commands to another Sprite — the executed commands came back from a machine with a different identity and a different boot. The agent's home can be durable and comfortable; the place it runs untrusted strings should still be somewhere you would happily set on fire.

For a deploy platform, the analogue is direct: the agent loop must never hold deploy capability itself. An agent that can call "promote this build to production" with the same authority it uses to read logs is one misparsed sentence away from a Replit-style incident.

The deploy path should look like SpriteDoc's session model — the agent proposes, and a separate, scoped executor carries out the mutation with its own tool allow-list, session caps, and dry-run-before-execute defaults. Guard rails on tool calls and caps on session blast radius aren't UX polish; they're the brains-vs-hands split applied to infrastructure. Sprites made this cheap by booting in 1–12 seconds and hibernating to near-zero cost when idle. Whatever your executor is, it needs to be cheap enough per invocation that isolation is the default, not the exception.

The token that was never there​

The sharpest pattern in Fly's post is a credential design from SpriteDoc, and Botha flags it explicitly: if you steal one thing, steal this. SpriteDoc runs flyctl inside the sandbox authenticated as the actual user — but the user's token is never written to the Sprite. It is injected into the environment for the duration of that one command and gone when the command returns.

The sandbox does real authenticated work and never holds the credential. If that Sprite is later inspected, snapshotted, or compromised, there is no token in it to steal, because there never was one at rest.

That is hot for multi-user agents precisely because the industry default is so bad. A 2026 Gravitee survey of more than 900 executives and practitioners found that 46% of teams still authenticate agents with shared API keys, and only 22% treat agents as independent, identity-bearing entities with their own credentials. Most agents in production today inherited the credentials of whoever launched them or authenticate through a key several other systems share. Answering "what did this agent touch?" then becomes an inventory project instead of one query against an access log filtered by principal — because the agent never had a principal of its own.

The same survey data explains why prompt-level restrictions keep failing. Teams write "do not modify production tables" in the prompt, but a prompt instruction is advisory, and its influence decays as context grows over a long task. A prompt asks the agent to behave; an IAM policy removes the option. Replit's database deletion and the data team hit with a 5,000-dollar bill from a single AI-generated query its resource monitors never caught are both what "advisory, not enforced" looks like in production.

For deploy-from-chat, the rule is absolute: every agent run gets its own identity with credentials scoped to its task, short-lived, and revocable independently. OAuth identity passthrough — the agent acting as the user who invoked it, through the MCP authorization flow the spec standardized on OAuth 2.1 — is the deploy-platform version of SpriteDoc's injected token.

Scoped tools with per-tool permission declarations, runtime policy enforcement, and confirmation hooks for risky operations (the pattern Fly's own Sprites Claude Code plugin ships with) complete the picture. 1Password CTO Nancy Wang put the baseline well: sandboxed tool execution, scoped and short-lived credentials, runtime policy enforcement, and comprehensive audit logging should not require custom engineering. If your agent's deploy credential outlives the run, or is shared with anything else, you haven't built this row yet.

Give the agent an undo button​

Security motivates the architecture, but Botha is honest that time savings sell it. His demo: two migration files freshly written into a Sprite, checkpointed, then a seemingly innocuous prompt — "clean up the old migrations and stale binaries we don't need anymore." The model decides that means rm -rf /root/app /usr/bin/python3 /usr/bin/git. Work gone, toolchain gone. On the agent's host, that's a cry and a restore-from-backup-if-you-have-one. On a Sprite, it's a checkpoint restore in about nine seconds: both files back to the byte, git back on the path. The restore is copy-on-write, so checkpointing before every risky step is cheap enough to be a reflex. The platform underneath makes this credible at scale — Sprites take checkpoints in roughly 300 milliseconds on persistent NVMe-backed Firecracker microVMs — but the principle is what matters: an agent that can roll back is an agent you can actually let run unattended, because the worst case is "restore and retry."

Deploys need the same reflex, one level up. An agent that triggers a deploy must never be trappable mid-deploy when a tool call fails: every promotion the agent can initiate must be atomic, with a guaranteed instant rollback that doesn't require the agent's help — or even its survival — to execute.

Blue-green traffic shifts, immutable releases with a pointer flip, backward-compatible migrations by construction: these are the deploy platform's copy-on-write checkpoints. If rolling back requires the same agent that just broke production to correctly diagnose what it did and run five more tools successfully, you don't have an undo button; you have a hope.

The test is simple: kill the agent's process halfway through its deploy sequence. Does the platform converge back to the last good state on its own? If not, the agent isn't safe to run unattended no matter how good its sandbox is.

This is also where session caps earn their place in the risk model. SpriteDoc tears down the sandbox when the session ends; idle Sprites cool from warm to cold and stop billing. Deploy runs want the same boundedness: a run that can't finish — stuck health check, hung migration, tool timeout — must time out into a rolled-back state, not linger half-applied. "Restore and retry" only works if restore is automatic.

The layer Fly implies: evidence​

There is a fourth row in the table that Fly's post implies more than it states, and it's the one incident reviews die without. Altimate AI CEO Pradnesh Patil's September 2026 autopsy of enterprise agent incidents names the three questions every review asks and usually can't answer: what did the agent touch, who owns it, and what did it actually do, step by step.

The third question is where reviews stall longest. What an agent leaves behind is output — merged changes, executed queries, a warehouse bill — but not what it knew when it acted, what it checked, what it skipped, or why it chose the path it chose. Long-running tasks widen the gap because context compression discards the intermediate reasoning a forensic review needs. The evidence isn't merely unindexed; it was thrown away mid-task, before anyone knew an incident would make it valuable.

That is why Patil's corrective — treat decision traces as first-class artifacts — belongs in the risk model as its own control. For every consequential action, the system should record what context the agent retrieved, what validations it ran, what confidence it had, and who approved the action if a human did. The record has to be produced at the moment of action, because it cannot be recovered afterward. For a deploy platform, that means append-only audit logs capturing every agent decision in the deploy path: the plan it proposed, the approvals it collected, the exact commands the executor ran, and the health signals observed after. These logs are what let you narrow scope after an incident instead of demoting the whole agent — which, as Patil notes, is what remediation looks like when there is no evidence to remediate from.

Gartner's framing gives this a growth path worth adopting: graduated autonomy across four levels — agents that observe, agents that advise, agents that act with approval, agents that act autonomously within guardrails. Promotion is earned by accumulating a track record at the level below. A deploy-from-chat flow can ship at level three (act with approval) on day one and only graduate specific, well-logged action classes to autonomy.

And Patil's sharpest principle deserves to be quoted on the wall of every team building this: deterministic questions deserve deterministic answers. Whether a table exists, whether a health check passes, whether a deploy fits inside a spend limit — these have verifiable answers and should be checked by systems that cannot hallucinate. The model's judgment belongs where judgment is required: on the ambiguous calls, not the verifiable ones. Dry-run-before-execute defaults are this principle in action — the plan is rendered deterministically, and only then does anything irreversible happen.

Fly's post ends with the line the whole genre needed: telling your agent to be careful is silly — just make it do things somewhere it doesn't have to be. The deploy-platform version goes one step further. Sandbox the execution, scope the credential to the run, guarantee the rollback, and log every decision where no agent can rewrite it. Do those four and an agent deploying your app stops being a battleship-scale footgun and starts being an operator with a narrower blast radius than most humans: no standing credentials, no unaudited actions, no un-undoable change.

Gartner's 40% is not a prediction about model quality. It's a prediction about missing infrastructure — and infrastructure is the part a platform gets to build once and offer to every tenant. The teams that build the unglamorous parts first — enforced scopes, named owners, traces that survive the incident — will run agents they can defend in an incident review. The teams that skip it will supply the 40%.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. As agents become first-class operators, the deploy primitives they drive need scoped credentials, audit trails, and rollback guarantees built in, not bolted on. Star the repo on GitHub or deploy your first app today.