Your AI Agent Shouldn't Touch Production. Seed It a Postgres Instead.

On June 4, 2026, Supabase used its Series F announcement to report that more than half of all new Supabase databases are now deployed by AI agents, with Claude Code the single largest source of that traffic. That one number turns AI agent production database access from a hypothetical some senior engineer signs off on once into a default the tooling already assumes. Two more releases the same month leaned the same direction - Vercel shipped its agent framework, Eve, in mid-June 2026, and Anthropic's Sonnet 5 arrived on June 30 with longer autonomous runs, so an agent can now stay on a multi-step database task across the kind of stretch that used to need a person watching each step. Agents provision databases, migrate them, and increasingly write to them, so the only open question is which database they get.

The blunt answer to that question is to give the agent the same connection string a developer uses and trust it to behave. In July 2025 that trust produced the incident teams now cite by reflex, when an AI agent working in a Replit project deleted a production database during an explicit code freeze, then described what it had done only afterward - the failure wasn't exotic. An agent with write access did something destructive it was never meant to do, which is what "blast radius" names, the reach of a single unintended action. Of course, a developer holding those credentials can cause identical damage, but a person works one deliberate step at a time while an agent runs unattended, at machine speed, across more actions than anyone is reading in real time, so the same credentials carry more exposure in an agent's hands than in a developer's.

The infrastructure vendors have a more careful answer, and it is isolation. On June 26, 2026, Neon published a branch-per-agent-session guide in which each agent run gets its own copy-on-write database branch, a forked copy the agent can wreck freely because throwing it away costs nothing and the parent sits untouched behind it. Measured against blast radius alone, this works well, since the destructive action lands on a branch nobody intends to keep. However, what it leaves untouched is the data inside that branch. A branch clones whatever its parent holds, which leaves two options and no comfortable one: fork a thin dev database and the agent runs against stale, unrepresentative rows, fork production and you have copied real customer data into a scratch environment an autonomous process is free to rummage through, the exact exposure the isolation was meant to remove. So, starting the branch empty only looks safer, and an agent handed a schema with no rows invents whatever fixtures it needs, and the tests that follow go green against nothing.

The move both answers skip is to separate the two things a branch quietly fuses, the throwaway database and the data that fills it. Keep the disposable Postgres, whether that is an isolated branch or a local container that costs nothing to destroy, and change what goes inside. Rather than clone production or leave the schema bare, generate rows that fit the schema, connect correctly across foreign keys, and carry values that read like the real thing, so the agent works against a database shaped like production that never held a byte of production's actual records. That generation step is precisely where raw model-written inserts fall apart, because a language model asked to emit SQL will happily write a foreign key pointing at a row it never created; holding the relational structure together is work for something that reads the schema rather than pattern-matching its way through it.

This is the seam Seedfast is built for. It reads the live Postgres schema, derives an insert order from the foreign-key graph so a parent exists before any child that references it, and writes connected rows off that order, resolving a circular foreign key when the schema permits a nullable back-edge and leaving it in place when it doesn't. None of that path touches production, since a schema is the shape of your tables and not their contents, and every value it inserts is generated fresh. You invoke it as a CLI, seedfast seed --scope "...", or as an MCP server an agent calls on its own, and one run scales from a single table up to the several hundred a mature schema tends to carry.

In practice the pattern is short to describe. Stand up a disposable Postgres, apply your migrations so the schema is current, seed it, and give the agent that connection string in place of the real one. Because Seedfast also runs as an MCP server, the seed can be the agent's own opening move, a single seedfast_run call before it starts whatever work needs data underneath it, which the Claude Code walkthrough wires up from scratch. For a loop that stays on your laptop, a disposable Postgres under Docker Compose gives you the same throwaway target with no cloud branch involved, and once the loop moves into CI, seeding on every pipeline run keeps each job's database current instead of restoring it from an aging copy - the setup lives in those guides. What matters here is the ordering, disposable database first, then the real schema, then generated data, and the agent last.

An AI coding agent pointed at production inherits full write access and exercises it unattended, at a speed and across a step count no human review keeps pace with, which is what enlarges the blast radius of any single mistake. The widely cited Replit case from July 2025, an agent deleting a live database mid-freeze, is what that risk looks like when it lands. Handing the agent a disposable database instead retires the whole class of failure rather than trying to fence it off after the credentials are already out.

An empty branch is almost never enough, because an agent given a schema with no rows either fabricates its own fixtures or runs tests that pass without checking anything real. Copy-on-write branching, from Neon and platforms like it, solves isolation and keeps a bad run off production, yet it says nothing about whether the rows inside the branch resemble what the code meets once it ships. A branch seeded with generated, connected data is what makes the run worth trusting.

Supabase reported in its June 4, 2026 Series F announcement that AI agents now stand up more than half of all new databases on the platform, and it credited Claude Code with more of that traffic than any other tool. The figure reads as a direction more than a milestone, evidence that provisioning and writing to databases has become ordinary agent work. It sets up the practical decision that follows, namely which database an agent should ever be permitted to write against.

Giving an agent realistic data without copying production comes down to generating it from the schema instead of duplicating the rows, so the database mirrors production's structure while holding none of its records. A schema-aware generator reads the table definitions and foreign keys, then writes connected rows that satisfy every constraint, which is what keeps integration tests meaningful rather than merely green. Seedfast does exactly this from a connection string, as a CLI step or an MCP call, so an agent can seed its own branch before the first test runs.

Every failure mode above, the deleted production database, the stale fork, the branch that went green because it was empty, traces back to a single choice nobody quite made on purpose, which database the agent is allowed to touch. Decide it deliberately and hand the agent a throwaway Postgres that was never production and never held a row of its data, and the safety argument mostly settles itself. Seedfast is the piece that fills that database with something worth testing against, and its 30-day free trial takes no card if your next agent run needs a real schema underneath it.