Working title · brand TBD

pg_brakes

Let AI agents read & write production Postgres — safely. Run them with --dangerously-skip-permissions and they can't cause disaster. Your database has nine lives.

Apache-2.0 SPEC v0.7 · converged 4 review rounds status: historical design brief
Historical design brief. This frozen pre-implementation artifact is published for decision history, not as current product copy. Its sprint state, replica/write posture, anchor maturity, and broad guarantee claims are superseded by ADR-0001 and the repository's generated capability table.

The problem · why now

AI agents now touch production databases — coding agents, text-to-SQL, internal copilots — often in YOLO / --dangerously-skip-permissions modes. Nobody has a safe way to let them.

The Replit agent deleted SaaStr's production database. The official Anthropic Postgres MCP's read-only mode was bypassed by statement-stacking (COMMIT; DROP SCHEMA…). Datadog's lesson: app-layer protection isn't enough — you need native Postgres RBAC.

Everyone else decides whether an action runs (allow/deny, masking, JIT). Nobody predicts what a write will do.

What it is

A self-hostable control plane between an AI agent and production Postgres. Reads are cost-gated & audited. Writes are rehearsed on an instant clone of prod, blast radius measured, then applied reversibly under guards.

🪞 The moat

We don't guess if a write is safe — we run it on a clone of prod first, measure exactly what it touches, then apply with an undo.

🐈 Nine lives

An agent can do its worst and the database lands on its feet: row-count guard, restore-point fence, typed-inverse.

🧱 Trust, not theater

The security wall is native Postgres roles — unbypassable even if our smart layer is wrong.

Architecture · four layers + a boundary

0
Network boundary The agent role reaches Postgres only via the proxy (pg_hba + network). No bypass, no audit holes.
mandatory
1
The Wall — native Postgres roles Hardened least-priv role: no write grant, SELECT-whitelist, member of nothing, dangerous primitives revoked. A hostile raw client physically can't write or read denied data.
unbypassable
2
Enforcement — Apache Rust proxy + out-of-band warden Inline (agent-only endpoint, fails closed): read-only, cost-gate, byte cutoff, timeouts, audit. Warden watches the DB and kills runaways · owns the circuit breaker.
our IP
3
Intent / UX — MCP server (cooperative) What the agent talks to. Executes through the proxy. Every block returns a recoverable next step — so the safe path is the easy path.
agent-facing
4
Write-safety — thin-clone dry-run (DBLab) The moat. Rehearse the write on an instant copy-on-write clone of prod, measure blast radius, apply to prod only under guards.
the moat

How a write works

01 · propose

Declare intent

Agent submits the SQL + expected rows. Nothing touches prod.

02 · dry-run

Rehearse on a clone

Run the exact statement on an instant clone of prod. Measure rows (incl. cascades/triggers), locks, duration, the affected-PK set, reversibility.

03 · apply

Guarded apply

Restore-point fence → row/PK-set guard (abort on drift) → commit → typed-inverse captured. confirm_rows forces the agent to own the blast radius.

Killer demo: UPDATE accounts SET balance=0 (no WHERE) → dry-run reports 4,823,901 rows → guard blocks it before prod. Then a slipped write → auto-reversed, with a verifiable row-diff.

Autonomy levels

L0 · observeDry-run & measure only. Always on.
L1 · human-in-loopAgent proposes; a human approves each apply.
L2 · narrow autoAuto-apply only within a closed, certified, reversible action set.
L3 · full autoDeferred — earned later, by published track record.

Scope

In the MVP

  • Thin-clone write-safety (the moat) — DML, closed action set
  • Own Apache Rust proxy + out-of-band warden
  • Native-role wall + mandatory proxy-only network path
  • MCP server (cooperative intent layer)
  • Read path: cost-gated, budgeted, audited (on a replica)
  • Autonomy L0 → L2 · tamper-resistant audit
  • Focused frozen safety benchmark + the why-now bypass repro

Deferred (fast-follow)

  • DDL & multi-statement interactive transactions
  • L3 full-auto beyond the certified set
  • Full ~120-scenario set + public multi-competitor leaderboard
  • Multi-DB · cloud / multi-tenant · web console
  • Open-core cloud tier (post-experiment)

The plan · ~12–15 weeks (solo + AI agents)

S0
2w

Skeleton + Wall + fidelity spike (red-test the moat first)

S1
3–4w

Proxy + read enforcement

S2
2.5w

Clone dry-run + blast radius (the demo)

S3
2.5w

Guarded apply + typed-inverse

S4
2w

Warden + full MCP + policy + audit anchor

S5
1.5w

Focused benchmark + launch

Riskiest assumption first: does the clone actually predict prod, and does the inverse truly restore it? Red-tested in week 1–2. If it fails, we learn the moat is invalid in week 2 — not week 10.

Testing — 0 false negatives, minimal false positives

0
data-loss false-negatives — by construction (writes bounded + reversible)
≤ B
bounded disclosure for reads — exfil capped + detected, not "impossible"
y.y%
false-positive rate, minimized via calibration (95% CI)

Honest by class: the deterministic floor guarantees the write FN=0 and bounds read disclosure; the LLM detection layer is measured statistically over labeled corpora (metamorphic + mutation, "100k runs"). Deterministic, third-party-runnable, with a public KNOWN_BYPASSES ledger that counts against the headline. Plus the marquee repro: "I deleted a database through the Anthropic MCP — here's how."

What we deliberately do not claim

  • Not "physically impossible to break" — claims are assertions over the frozen adversarial suite + the public bypass ledger.
  • Reads can't be un-disclosed — exfiltration is bounded + detected, not prevented. (Writes are prevented/reversible.)
  • Full-auto write is narrow (a certified, reversible action set), not open-ended — for years.
  • The LLM reduces friction & catches more, but is never the safety guarantee — the deterministic floor is. It can block, never grant.
  • PITR needs the customer's WAL archiving; the typed-inverse is the cheap default undo. We don't conflate them.

What success looks like (90-day experiment)

Resonance

Benchmark cited by others · ≥1 HN front page · ~1k stars · ≥500 owned-audience signups (today: zero) · ≥3 "can I run this on my DB?" inbounds.

Pull to the moat

A concierge-pilot customer asks "can it fix the data too?" · then 3–5 design partners · ≥1 non-GitLab logo at human-in-loop write autonomy (the investor trigger).