# When the Agent Writes the Migration, Who Approves It? > AI agents are no longer just reading your database, they are authoring the migrations. The write path is a different risk class, and it needs its own gate. Tianzhou | 2026-06-12 | Source: https://www.bytebase.com/blog/governing-agent-authored-database-changes/ --- Almost everything written about AI agents and databases is about reading. Can the agent only see the data it is allowed to see. Does it have enough context to write a correct query. Both questions assume the agent is a reader, and for a while that assumption held. It expired. Agents are now the ones writing the migration, altering the column, backfilling the table. A bad read leaks data. A bad write destroys it. Same database, completely different risk class, and most teams have not built for the second one yet. ## The Agents Are Already Writing This is not a forecast. At the recent [Background Agents Summit](https://background-agents.com/summit/), team after team described the same thing: background agents that author changes and open pull requests with no human in the loop until review time. Stripe [runs "Minions"](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents) on a 30-million-line codebase: an agent allocates a box, makes the change, runs checks, and opens a PR. Uber's "Minion" platform now generates 11% of all merged PRs, with a separate system, Shepard, aimed squarely at large-scale migrations. The agent that used to query your database now changes it. What stands between that change and production? ## Code Has a Merge Gate. Your Database Doesn't. Here is the part everyone glosses over. When an agent writes code, you get a safety gate for free. The output lands in a branch. Nothing reaches production until a human merges the pull request. Stripe made this explicit: human review stays mandatory on every agent-authored PR. Uber built Code Inbox just to route those reviews to the right person. Git is the gate, and it has been there for fifteen years. The database has no equivalent. Hand an agent a connection string and a migration, and `ALTER TABLE` runs the instant it is sent. No branch. No pending state. No merge. The change is live the moment the agent decides it is ready, and no agent feels the weight of typing `DROP TABLE` against production the way you do at 2am. We have spent years teaching humans not to point at the wrong database by accident and not to DROP PROD. Agents start with none of that scar tissue, and they operate faster than anyone can watch. The merge gate that code gets from git, the database has to install on purpose. ## You Can't Prompt Your Way to Safety The tempting fix is to write the rules into the agent. "Never alter a table without a WHERE clause." "Always ask before touching production." Put it in the system prompt and move on. It does not hold, and it was a recurring theme at the summit: an autonomous agent will reason its way around any rule you write in a prompt. Tell it not to run a command and it renames the command, swaps the tool, or splits the work across steps so no single action trips the policy. Guardrails the agent can read are guardrails the agent can argue with. Enforcement has to live somewhere the agent cannot see or edit. The OS-level crowd has the right instinct and the wrong altitude. Tools like [nono](https://nono.sh/) sandbox the agent at the kernel: filesystem allow-lists, network allow-lists, deny by default. Useful. But the kernel sees a TCP connection to port 5432. It cannot tell `SELECT 1` from `DROP SCHEMA public CASCADE`. It does not know that `users.ssn` is restricted, or that the `payments` table needs DBA sign-off before anyone alters it. Database governance is semantic. A sandbox that does not parse SQL is blind to every distinction that actually matters here. So the guardrail belongs in neither place. Not in the prompt, where the agent can reason past it. Not in the kernel, where it is too dumb to understand the change. It belongs at the database-change layer, below the agent's reasoning and above the raw connection. ## Govern the Change, Not the Agent The trick is to stop trying to make the agent trustworthy and instead make the change pass through a gate. The same gate, whether a human or an agent wrote it. At Bytebase, an agent does not get a connection string. It gets a service account, and that account carries the full governance stack with it. Every change the agent proposes becomes an issue that runs the same pipeline your humans already run: ![Human or agent, every change clears the same governed gate before production](/content/blog/governing-agent-authored-database-changes/govern-the-change.svg) - **SQL Review.** 200+ lint rules catch the dangerous shapes before anything executes: an `UPDATE` with no `WHERE`, a blocking `ALTER` on a hot table, a column drop with no backfill. The automated reviewer never gets tired and never waves it through. - **Approval flow.** You decide what an agent applies on its own and what needs a human. A dev-branch migration self-serves. A change to a production financial table routes to a DBA. The summit kept circling one question: when no human is at the terminal, where does the request go? The answer is a defined approval flow, not a prompt and a prayer. - **Staged rollout and rollback.** The change moves through environments in order, with a rollback plan attached, so a mistake is recoverable instead of terminal. - **Audit.** Every change recorded, attributed to the agent and the human it acted for. When something breaks, and it will, the trail is the only thing that lets you reconstruct what happened. None of this is new machinery. It is the change process teams have run for years. What is new is the author. The gate matters more now, not less, because an agent writes faster and worries less than any human ever did. ## The Question That Actually Matters First came access: can the agent see only what it should. Then context: does it have what it needs to act correctly. Both are about an agent that reads. The newer question is the one that decides whether you keep your production data. When the agent writes the change, who approves it before it ships? The industry is racing to make agents better at writing. The race nobody is sprinting in is the boring one: building the gate the change has to clear. Code got that gate from git for free. Your database is still waiting for you to install it. ## The rest of the series - [How to Govern AI Agent Database Access](/blog/how-to-govern-ai-agent-access-to-enterprise-data) - the read path: identity, authorization, masking, and audit for an agent that queries your data. - [From Schema as Code to Schema as Context](/blog/schema-as-code-to-schema-as-context) - giving an agent the classification, ownership, and policy it needs to act correctly.