Self-hosted safety layer for AI agents
Your agent edits files, writes to your database, runs commands and calls paid APIs. gmonk records what every change replaced, so a bad run can be undone exactly — and blocks the actions that nothing could undo.
# every action the agent takes, judged as it happens
✓ capture file src/api/billing.ts snapshot
✓ capture sql UPDATE accounts SET balance = balance - 30
✓ capture s3 PUT invoices/2026-07.pdf by version
⚠ hold shell rm -rf ~/.config outside workspace
⚑ flagged extl stripe.createCharge compensation declared
✗ block sql TRUNCATE audit_log no undo exists
# the run went sideways — preview the undo, drift-checked
$ gmonk reverse-run 8f3a --dry-run
✓ ready file src/api/billing.ts restore snapshot
✓ ready sql accounts (id=1) +30, concurrency-safe
⚠ drift sql users (id=5) changed since — skipped
✗ blocked extl stripe.charge needs a human
$ gmonk reverse-run 8f3a
↩ reversed 9 · drift untouched · 1 held for reviewHow it works
The agent thinks it's talking to your database. It's actually talking to gmonk, which records how to undo each write before passing it through — and refuses the writes it couldn't undo.
UPDATE accounts SET balance = balance - 30 WHERE id = 1 TRUNCATE audit_log waiting… accounts(id=1).balance = 120 · undo ready Every statement is classified before it runs. Reversible writes are journalled with their before-image and then forwarded; irreversible ones are refused at the wire. Step through it below.
Your agent's connection string points at gmonk, not at the database. Every statement arrives here first.
The reversibility oracle parses the statement and asks one question — can this be undone?
Reversible. Before anything runs, gmonk reads the exact rows the statement will touch and records their before-image.
Only now is the statement forwarded. The capture and the write commit together, so a journal entry can never go missing.
A statement with no possible undo — TRUNCATE, DROP, a DELETE with no WHERE — is refused at the wire. It never reaches the database.
On reverse-run, gmonk re-reads the live row, confirms nothing else has changed it, then writes the before-image back.
The diagram above is the database channel. There's a second one, and both land in the same run with the same undo.
Channel 1 · your database
gmonk protect
Postgres and MySQL. Sits in the connection, so it both prevents and captures. The main path.
gmonk protect-db captures
out-of-band via WAL or triggers.
Undo, but no prevention — they're not in the write path.
gmonk enforce revokes the
agent's direct write grants, so the proxy is the only way in.
Channel 2 · your agent
gmonk install-hook · gmonk run
Everything the agent does outside the database: file writes, shell commands, MCP tool calls.
dd/mkfs — are
paused for your approval before they run.
External effects are different again. A charge has no before-state to restore, so it's reversed by a compensating call you declare — and gmonk never calls a third party on its own. Undeclared, it's flagged for a human.
Protect a database Capture an agent Reverse external effects
Three failure modes, again and again. None of them require bad intent.
A confused or prompt-injected agent runs a DELETE with no WHERE. It commits before anyone reviews it.
A snapshot restore throws away every legitimate write since. You want the damage gone, not the whole database back.
The run is over by the time you notice. What changed? Which rows? Can it be undone at all?
What gmonk is
Not "is this allowed?" but "can this be undone?" — a property of the action itself. That one question drives both halves.
Prevention
The reversibility oracle scores every write before it
runs. block mode refuses what it can't undo;
guarantee mode rolls the write back unless the undo is
provable.
DROP, TRUNCATE, no-WHERE deletes at the wireRecovery
The before-state is captured as each change happens. Before undoing, gmonk checks the live system and refuses to clobber anything a human changed since.
Not just your database
Not just SQL — files, shell commands, object storage and paid APIs.
Why reversibility
Policy engines answer "is this allowed?" — a list someone has to keep correct. gmonk answers "can this be undone?" — a property of the action itself. That's a guarantee you don't have to author, and it welds prevention to recovery: the same engine that scores an action pre-flight is the one that reverses it after.
Before-state captured, system unchanged. One-click undo, exactly.
Something changed since. gmonk preserves the concurrent write and flags the conflict rather than clobbering it.
No safe undo exists. This is exactly what the gate refuses to run in the first place.
In the image
Quick start
# your database URL lives in an env var (never passed on the CLI)
export APP_DB_URL=postgres://user:pw@db-host:5432/appdb
# run gmonk in front of your DB with undo capture ON
gmonk protect --backend-ref APP_DB_URL --listen 6432
# then point your agent at gmonk instead of the database:
# postgres://agent@localhost:6432/appdbQuestions
Deeper detail lives in the documentation — capture modes, the gate, drift semantics, and the CLI.
gmonk is a self-hosted safety and disaster-recovery layer for AI agents. It sits in front of an agent's actions on your database, files, and external APIs, records each one, blocks the ones that can't be undone, and lets you reverse a run — per action and drift-aware — when the agent misbehaves.
Backups are all-or-nothing and blind to individual agent actions. gmonk captures the before-state of every single write as it happens, so you can undo exactly the damage — one action, or one action plus only its dependents — without rolling the whole database back to a snapshot. It also checks live drift first and refuses to clobber changes it didn't make.
No. gmonk is fully self-hosted. It runs as a Docker image inside your own infrastructure against your own Postgres or MySQL database. Your code, prompts, and data never leave your network.
Through two separate channels. For a database — the main use — gmonk runs as a wire proxy in the connection: the agent thinks it is talking to Postgres or MySQL but is actually talking to gmonk, which gates each statement and records how to undo it before passing it through. If you cannot run a proxy in front of the database, gmonk can instead capture out-of-band from the write-ahead log or from in-database triggers, which gives you undo but not prevention. Separately, for what an agent does outside the database — file writes, shell commands and MCP tool calls — gmonk installs a capture hook into Claude Code, or runs as an MCP gateway for agents that speak tool calls. In gmonk, the word proxy always means the database one; the MCP gateway is a different interception point and is not a proxy.
Yes. gmonk's reversibility oracle scores how recoverable each action is before it runs. In block or guarantee mode it refuses statements it can't undo — DROP, TRUNCATE, a DELETE with no WHERE clause — at the wire, before they reach the database.