Backstep sits between an AI agent and the tools it calls. Before the agent changes any data, it records what that data looked like, so any mistake can be reviewed and rolled back with one command.
From a wiped table to an exact restore, plus a refusal and the benchmark results.
They run queries against real databases, file stores and cloud accounts.
An UPDATE with the wrong WHERE clause. An insert loop that runs 200 times.
Keep the agent read-only, or give it write access and hope for the best.
Let the agent act, keep an exact record of every change, and undo any of it with one command.
Every tool call the agent makes passes through Backstep first.
A transparent MCP proxy aggregates tools from every configured upstream server and routes each call through an interceptor. It never alters or swallows the upstream response.
Each tool has a risk grade, from read-only to irreversible.
Looks up the tool's reversibility class (R0 to R4) and decides to pass it through, journal it, ask for confirmation or block it. No model is in the loop at runtime.
Before anything changes, it saves a copy of the rows about to change.
The Postgres adapter parses the statement with sqlglot, rewrites the INSERT, UPDATE or DELETE into a SELECT over the same rows, and runs it on its own connection.
It writes down what happened and what the data looked like before.
An append-only SQLite journal stores the call's arguments, the state before the change and a fingerprint of the state right after it.
One command puts it back. If someone else has changed the data since, it stops.
Compares the live rows with the stored fingerprint. No drift: restore the original rows. Any drift: refuse and show the difference.
Every tool gets a reversibility grade. It decides what is recorded, what needs your confirmation and what is refused.
backstep eval runs six "agent gone wrong" scenarios against a real Postgres database and grades each recovery.
| Scenario | What the agent did | Result | Recovery |
|---|---|---|---|
| wrong_where_update | An UPDATE that hit far more rows than intended | Full recovery | 28 ms |
| runaway_insert_loop | 200 INSERTs from a stuck loop | Full recovery | 2.7 s |
| mixed_session | 3 updates, 1 delete, 1 insert, undone together | Full recovery | 87 ms |
| cascading_delete | A DELETE whose child rows cascade | Partial recovery | 37 ms |
| partial_drift | Another process edited the row afterwards | Correctly refused | 3 ms |
| unparseable_sql | A CTE-heavy statement it cannot safely read | Correctly refused | 17 ms |
In partial_drift, reverting would have destroyed someone else's edit. In unparseable_sql, Backstep could not safely read the statement, so it declined to guess.
In cascading_delete, Postgres removes child rows inside the same statement, before Backstep can see them. The parents come back; the children do not.
Missing pre-state, no primary key, drift or an action already undone: any doubt ends in a refusal with a clear reason.
tests against a disposable Postgres container, with a fresh schema for each test.
Once an action is recorded, only its status can change.
Install with uv, then point your MCP client at the proxy instead of the upstream server.
$ uv sync # install dependencies
$ uv run backstep init # optional: Claude grades each tool
$ uv run backstep doctor # check config, journal, database
$ uv run backstep serve # run the proxyFirst copy backstep.example.toml to backstep.toml and add your upstream server and Postgres connection string. init needs ANTHROPIC_API_KEY.