Skip to content

Blastproof a safety gateway for AI agents

Approve outcomes, not commands.

It lets AI agents take real actions safely: every risky action runs on a copy first, and humans approve what it will actually do, not cryptic commands.

Watch the demoView on GitHub (opens in a new tab)Log in

Example, replaying the Replit incident: an agent sends DELETE FROM users WHERE last_login_at < now() - interval '6 months'. Blastproof previews it on a copy: it would delete 48,213 users, including 12 paying customers (3 enterprise). The owner rejects it, and nothing changes.

The problem

Agents already have write access. When they get it wrong, the damage is fast and real.

  1. A Cursor agent deleted PocketOS's production database and its backups with one cloud API call, using a token it found in a file.

    Live Science (source for the Apr 2026 incident, opens in a new tab)

  2. An agent running Terraform commands deleted a founder's production database.

    OECD AI incidents (source for the Mar 2026 incident, opens in a new tab)

  3. A Replit agent deleted SaaStr's production database during a code freeze, then produced misleading output.

    OECD AI incidents (source for the Jul 2025 incident, opens in a new tab)

Why the usual options fail

No write access
the agent is useless for real work.
Full access
one bad guess destroys data.
Approve every command
people see raw SQL, cannot judge it, and click approve anyway.

How it works

Every write is tried on a copy before it touches production.

Reads take a fast path. Writes go through four steps, and only the last one can touch your data.

  1. 01

    Intercept

    Every tool call goes through Blastproof, over MCP or the Claude Code PreToolUse hook. Reads run directly.

  2. 02

    Preview on a copy

    A write runs first on a disposable database branch, so its effect is measured, not guessed.

  3. 03

    Explain the impact

    Row counts come from the database. The AI only writes the sentence, and every number in it is checked against the computed facts.

  4. 04

    Approve or block

    Rules run first, then an AI judge that can only make a decision stricter. Safe writes go through, dangerous ones are blocked, the rest wait for the owner.

The change request

The owner sees the outcome, then decides.

Each held write gets one page: what will happen in plain language, the numbers behind it, the exact SQL, the rules that fired and an audit trail.

Blastproof's change request page for the Replit-style delete, awaiting review. The headline reads: Deletes 48,213 rows from users (96.4% of the table), including 12 in users.paying. Below it are the per-table counts, Approve and Reject buttons, and the agent's original SQL next to the pinned SQL as it will run.
What the owner sees: the outcome, the affected rows and the exact SQL.

What makes it different

Built around what the change does.

  • Outcomes, not commands

    The owner approves “delete 12 paying customers”, not a line of SQL.

  • Real shadow execution, not predictions

    The write actually runs on a branch. The commit must reproduce exactly the diff that was approved, or it rolls back.

  • Any MCP agent, plus a Claude Code hook

    Vendor-neutral: any agent that speaks MCP connects, and Claude Code's shell and file tools are checked by the hook too.

Results

Measured on replays of real incidents.

Every scenario is a labelled action: dangerous ones must be blocked or held, safe ones must go through.

real-incident replays caught
12/12
Replit-style mass delete, DROP TABLE, delete without WHERE, a psql bypass, pg_dump, hook-settings edits, credential hunting in .env and .pgpass.
dangerous actions blocked or sent to review
51/51
A 100% catch rate across 63 scenarios.
false block rate
8.3%
1 of 12 safe actions held for review instead of allowed.

Source: rules-only eval, 63 scenarios, run Oct 28, 2026, also run in CI. Model and latency numbers are not published yet.

Architecture

One gateway between the agent and your data.

Reads go straight through. Writes take the long way, and the owner has the last word on anything risky.

  1. The agent (Claude Code) calls Blastproof's backend by an MCP tool call or through the PreToolUse hook.
  2. A read goes to the company database directly.
  3. A write is previewed on a database branch.
  4. Rules, then an LLM judge, decide: allow, block or review.
  5. Allow commits exactly what was previewed. Block stops the write.
  6. Review waits for the owner to approve in the dashboard, then commits.
  7. Blastproof's own database holds the actions, the audit trail and the knowledge.

Security

The safety does not depend on the model.

The AI explains and can make a decision stricter. Everything that keeps your data safe is plain code.

  1. Credential isolation is the boundary

    The agent never holds the company database's credentials. They live only in the backend's environment.

  2. Fail closed

    Any error, timeout or unparseable SQL blocks the write. If only the AI judge fails, the write goes to a human.

  3. Commit exactly what was previewed

    The approved statement is pinned. If the commit would change anything else, it rolls back.

  4. Sensitive columns are masked

    Emails, phone numbers and similar columns are masked before they reach logs, prompts or the dashboard.

  5. Hooks are guardrails, with an audit trail

    The Claude Code hook catches honest mistakes early; it is not the boundary. Every action keeps a full audit trail.

FAQ

Questions people ask first.

No. The company database's credentials live only in Blastproof's backend. The agent holds a Blastproof key, which can only ask for actions, never connect to the database.

Rules run first and the judge can only make a decision stricter, never looser. If the judge fails or times out, the write goes to a human for review instead of going through.

Any agent that speaks MCP. Claude Code also connects through its PreToolUse hook, which checks shell, file and search tools.

Postgres. Reads run directly; inserts, updates and deletes are previewed on a database branch; schema changes from agents are blocked. Shell sandboxes, an external app such as email or Slack, and Terraform come later.

Not yet. Accounts are created by an admin, because every account acts on one shared demo database. Watch the demo, or run Blastproof locally by following the README.

No. It works alongside the permissions you already have. It adds a preview, an explanation and an approval step in front of an agent's writes.