Rowbit

Rowbit

A safety net for AI agents that write to your database. Preview every write, approve the risky ones, undo any single change. MariaDB and MySQL, over MCP.

[Release] [CI] [License: AGPL-3.0]

[Rowbit: a safety net for AI agents that write to your database. Preview, approve, undo.]

Get started

curl -fsSL https://ermag.github.io/rowbit/install.sh | shrowbit setup

macOS and Linux (Windows through WSL). If ~/.local/bin isn't on your PATH, the installer says so: run ~/.local/bin/rowbit setup instead. Setup finds your database's URL, checks Rowbit's privileges and prints the GRANT statements to fix them, writes rules that hold every write for review, connects the agent clients you pick, and prints the review page's password. See the quickstart.

No database to try it on? Choose the sample when setup asks: it runs a shop database in Docker with Rowbit in front of it (the tour). Then ask the agent:

The pending orders are stuck. Cancel them.

Works with Claude Code, Cursor, VS Code, Claude Desktop, Codex, Gemini CLI, Windsurf and any MCP client.

Docs · Quickstart · Interactive demo · Tell us what you think

What it does

You ask a coding agent to fix the orders stuck in pending, and it writes UPDATE shop.orders SET status = 'cancelled' WHERE status = 'pending'. That also matches every order placed in the last hour. Rowbit catches it before it touches a row, shows a person exactly which 1,284 rows would change, and waits. If something bad does get through, you undo that one change without restoring a backup.

Status: early and open source; see the changelog for each release. What we build next depends on what you tell us in the feedback discussion.

How it works

Rowbit sits between your agents and your database. Agents talk to Rowbit over MCP, never to the database directly: they read and propose writes through it, without the database's credentials.

• Exact preview. Rowbit reads the rows a write would change and replays it on a private temporary copy, so you see each row before and after, exactly as the table would store it. Your tables are only read.
• Rules, then people. A small YAML file lets safe writes through, holds risky ones for a person, and refuses the rest. Only people approve, and approval applies exactly what was previewed, or nothing. See rules.
• Undo one change. Rowbit keeps every row a change touched, so you can take back one bad write and keep everything else.
• Scopes and shadow mode. Per agent, which tables it may read or write and which columns it may never see, enforced by the database with a user of the agent's own. Shadow mode shows what the rules would hold before you enforce them.
• Review where you are. A web UI in the binary, sign-in through your identity provider, Slack or webhook notifications, and an audit log in a hash chain. See how a change moves.

# rowbit.ymlversion: 0agents:  coding-agent:    default: hold    rules:      - name: small-order-fixes        when: { statement: update, table: shop.orders, columns: status, rows: { max: 20 } }        then: allow      - name: no-deletes        when: { statement: delete }        then: block        reason: Data fixes don't delete rows.

Here the agent can change the status of up to 20 orders on its own. An update that writes any other column, or more rows, waits for a person, and deletes are refused.

See examples/rowbit.yml and the rowbit.yml spec for the full schema.

Connect your agent

rowbit setup connects the clients you pick. rowbit connect <client> sets up one more, with a token of the agent's own. See Connect your agent.

rowbit connect claude-code

/plugin marketplace add Ermag/rowbit/plugin install rowbit@rowbit

rowbit connect cursor

rowbit connect vscode

rowbit connect claude-desktop   # macOS; starts rowbit mcp itselfrowbit connect codexrowbit connect geminirowbit connect windsurf

rowbit connect --print

Why not just migrations?

Having an agent write a migration file that goes through code review and CI is the right answer for a coding agent changing your schema, and Rowbit doesn't compete there: it holds every schema change for a person and leaves the real workflow to your migration tool. It works badly for fixing data:

• A reviewed diff shows SQL, not rows. UPDATE orders SET status = 'cancelled' WHERE status = 'pending' looks fine in review. What it touches depends on the data when it runs. Rowbit shows the exact rows when the decision is made, and refuses to apply if they changed since.
• A one-off fix can't wait for a pull request. Repairing a few broken rows during an incident needs an answer in minutes, and nobody writes and reviews a migration for every one.
• Not every write needs a person. Rules let small, safe writes straight through and hold only the risky ones, so reviewers aren't trained to rubber-stamp.
• Undo is per change. Down-migrations for data are usually missing or lossy. Rowbit keeps the before image of every row a change touched.

The well-known incidents of coding agents wiping production databases are a credentials problem as much as anything: take the credentials away and have the agent write migrations. Rowbit is for the agents that need to write. And if an agent does the same thing over and over, like issuing refunds, give it a tool that does just that instead of SQL.

Good to know

• Only Rowbit holds the database credentials. If an agent also has its own connection string, it can write around Rowbit. Give agents Rowbit's endpoint and nothing else (over HTTP, a token of their own), and Rowbit a database user of its own.
• An agent without scopes reads and writes with Rowbit's privileges. Its rules still decide every write, but nothing stops it reading whatever Rowbit's user can. Give production agents scopes.
• Undo restores rows, not the world. It puts the data back, but it can't take back an email that was sent or a refund that was paid because of it.
• Preview never writes to your tables. It reads the affected rows without taking locks and replays the write on a temporary copy that only Rowbit's connection can see. Tables with triggers or cascading foreign keys are refused, because their side effects wouldn't show in the preview or be undone. So are tables Rowbit's database user can't fully inspect: it needs the TRIGGER and PROCESS privileges. See database privileges for the exact grants.
• Where data lives. Change state, previews (including before and after copies of affected rows) and the audit log are stored in a local SQLite file next to Rowbit. Protect it like a replica of the database (how).
• The CLI trusts whoever runs it. Anyone who can read rowbit.db and has the database URL can run rowbit approve, under any --as name. Keep both from agents, and run Rowbit as a user they can't act as; see Before you use it for real.
• Fail closed. Anything Rowbit can't evaluate, it refuses. See the change lifecycle and SECURITY.md.

Contributing

Ideas and opinions are welcome in Discussions. For code, see CONTRIBUTING.md. Commits need a DCO sign-off (git commit -s). Report security issues as described in SECURITY.md.

License

The server is AGPL-3.0-only. The rowbit.yml policy schema (crates/rowbit-policy) and future client SDKs are Apache-2.0.