Interactive Space

Product · Dev / Infra

DB Safe Execution Layer

Before any AI-generated SQL touches your database, it should pass through a Safe Execution Layer — a deterministic pre-DB boundary for risk detection, dry-run impact estimation, and replayable auditing.

View demo flowGitHub · Dev Edition

Works with PostgreSQL / SQLite · Designed for LLM agents, coding tools, and internal automation.

AI tools now generate SQL. Most teams still execute it on trust.

LLM-assisted development tools generate production-grade SQL — but they also hallucinate schemas, produce destructive writes, and behave nondeterministically. Most teams respond with manual review, backups, and shadow databases.

That doesn't scale when you have coding agents, internal assistants, and automated workflows generating SQL every minute.

"Any SQL generated by AI tools must be manually checked. We back up tables before running anything."

— Senior Analytics Engineer, data consulting (reported workflow pattern)

Why now

  • Coding agents and AI IDEs are exploding, and many now ship with direct SQL generation and execution.
  • Large organizations are starting to ban third-party tools over data safety and compliance concerns.
  • Regulators increasingly expect auditability, traceability, and reproducible execution for AI-driven workflows.

Our view

AI can propose SQL. A deterministic Safe Execution Layer should decide what actually runs.

What it is

A deterministic SQL firewall for AI-generated queries.

DB Safe Execution Layer sits between any SQL-generating client (LLM agents, coding tools, internal scripts) and your database. It parses, simulates, classifies, and logs every statement before deciding whether it is allowed to execute.

It doesn't change your database engine or ORM. It is a thin, explicit execution boundary that makes AI-driven SQL safe, auditable, and replayable.

Core capabilities

Works out-of-the-box with PostgreSQL / SQLite

Static SQL analysis

AST-based parsing detects statement type, accessed tables, predicates, and destructive patterns before execution.

Dry-run impact estimation

Rewrite DELETE / UPDATE into SELECT COUNT(*) to estimate affected rows without touching data.

Risk classification & gating

Rule-based LOW / MEDIUM / HIGH / CRITICAL levels, with approval required for high-risk operations.

Snapshot reference

Record a database snapshot reference (e.g. txid / point-in-time marker) before executing approved writes.

Replayable audit log

Every step — precheck, dry-run, classification, snapshot, execution result — is captured in a structured log.

LLM & tool agnostic

Treats SQL as input. Works with any LLM, coding agent, or automation framework that emits SQL.

Demo flow

From raw SQL to safe execution, step by step.

A developer or agent sends:

-- LLM-generated SQL

DELETE FROM visits
WHERE visit_date < '2010-01-01';
1

Static pre-check

Parse SQL, detect DELETE, target table visits, and the filter predicate.

2

Dry-run rewrite

Generate SELECT COUNT(*) FROM visits WHERE visit_date < '2010-01-01' and execute safely.

3

Risk classification

If affected_rows > threshold → classify as HIGH risk.

4

Snapshot reference

Record a snapshot reference (e.g. postgres:txid:7428812) before any potential write.

5

Gated execution

Show: 'This operation will delete 3214 rows from visits. Approve? (yes/no)'. Block by default.

6

Audit + replay

Write a JSON log with all steps and decisions. Replay later without touching the LLM or re-executing writes.

Dev edition

Try it locally in minutes.

1. Clone the repository

git clone https://github.com/interact-space/database-safe-layer.git

2. Create virtual environment & install dependencies

cd database-safe-layer
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate
pip install -r requirements.txt

3. Configure database connection (.env)

DB_URL=postgresql://user:password@localhost:5432/db_name

4. Run the demo

python -m db_safe_layer.app

Roadmap

From DB Safe Layer to deterministic agents.

Phase 0 · Now

DB Safe Execution Layer (Dev Edition)

  • Open-source SQL Safe Layer for Postgres / SQLite.
  • Static analysis, dry-run, risk classification, snapshot reference, audit + replay.
  • Early testers: teams experimenting with AI → SQL.

Phase 1 · Next

Enterprise features with design partners

  • Service integration, policy configuration, and team-level audit dashboards.
  • Tighter integration into AI coding tools / internal platforms.

Phase 2

Deterministic Execution DAG for agents

  • LLM as semantic interface only (NL → intent).
  • Deterministic DAG as the formal execution model.
  • Replayable, comparable agent runs across DB / code / infra surfaces.

Design Partner Program

We're inviting design partners for the Phase 1 enterprise edition.

If your team is exploring AI → SQL automation, coding agents, or internal developer tools, and you need guaranteed safety before touching databases, we'd like to co-build with you.

You get early access, direct collaboration with our engineering team, and influence over the product. We gain real workload insights to shape the enterprise edition.

Apply as Design Partner

About

DB Safe Layer was not born as a generic infra product.

We originally built it as an internal tool while working on OMOP-based analytics and AI-assisted SQL in medical R&D. Every query had to satisfy two constraints:

  • “If this goes wrong, can we explain exactly what happened?”
  • “Can we recover state without guessing what the agent did?”

The answer in most existing tools was “no”, so we built a pre-DB Safe Execution Layer: dry-run, risk analysis, snapshots, and replayable audit — before any SQL touched a real database.

Only later did we realize the same pattern is needed far beyond healthcare.