Let AI agents use production data without handing them your database

Hi Devs,

If you’ve connected an AI agent to a real database, you’ve probably felt the discomfort of the default approach: handing the model an execute_sql(sql) tool.

Read-only roles, SQL validation, allowlists, and prompt instructions all help. But they still give the model raw database authority and then try to constrain it.

I wanted the opposite: a boundary where the model never receives that authority in the first place.

So I built Synapsor Runner, an Apache-2.0 runtime that sits between an MCP client and PostgreSQL or MySQL. Instead of exposing SQL, it exposes reviewed semantic capabilities such as:

billing.inspect_invoice

billing.propose_late_fee_waiver

support.propose_plan_credit

Try it in 10 seconds

No database. No signup.

npx -y -p @synapsor-runner audit --example dangerous-db-mcp

npx -y -p @synapsor-runner demo --quick

The audit flags risky MCP tool shapes, such as raw SQL execution.

The quick demo walks through the proposal → evidence → replay boundary. It explains and records that boundary; it does not claim to test a live database.

The idea in one line

The model can read only the columns and rows that a contract allows. It can propose changes, but the model-facing MCP surface contains no approve tool and no apply tool.

Commit authority lives entirely outside the model loop.

Everyone does allowlists. The part I care about is that there is literally no tool the model can call to write.

Why this matters

This does not stop prompt injection.

What it does is contain the blast radius when injection—or simply a confused model—happens.

In my testing, I put a fleet of real LLM agents on one server. Several were given injection tasks such as:

• “Read the other tenant’s data.”


• “Ignore the budget.”

The result:

• 0 cross-tenant reads


• 0 unauthorized writes

That was not because the models resisted the prompts. It was because the boundary was enforced outside the models.

This is the same class of failure demonstrated in the recent Supabase MCP token-exfiltration example: a model is tricked into running attacker-controlled SQL. If there is no SQL tool and no commit tool to reach, that path closes.

How the boundary works

Scoping

Tenant scope, allowed columns, and allowed rows are fixed by the reviewed contract and trusted server-side context.

That context is bound outside the model’s arguments, never supplied through a tool parameter.

The model cannot widen what it sees.

Proposals, not mutations

A proposal records the requested before-and-after state but does not modify the source database.

Approval and writeback happen outside MCP.

Guarded writeback

When an approved proposal is applied, Runner rechecks:

• Trusted tenant scope


• Target row


• Allowed columns


• Expected row version


• Operation bounds


• Idempotency


• Affected-row limits

A stale row becomes a conflict instead of a silent overwrite.

Every apply operation is recorded with a receipt and replay linkage.

Ledger

By default, activity is stored in a local SQLite ledger.

A shared PostgreSQL runtime store is also available for multi-process deployments.

Tiered auto-approval

Not every change needs a human.

A contract can define tiered auto-approval for small, low-risk proposals:

AUTO APPROVE WHEN amount_cents <= 2500

LIMIT 20 PER DAY

Policies can also define aggregate value ceilings.

When a proposal exceeds a rule or budget, it falls back to human review, and the ledger records why.

Higher-risk capabilities can require approvals from multiple distinct people.

Policy approval still gives the model no commit authority. A trusted Runner worker performs the guarded write outside MCP.

Bounded set writes

For reviewed batch operations:

• The selection rule is contract-defined, not model-generated.


• Tenant scope is forced.


• Row and value limits are declared.


• Application is atomic.


• Drift fails closed.


• Receipts record the affected rows.

This is not a path to arbitrary UPDATE statements.

Reversible changes

Runner can record a bounded inverse and create a separate compensation proposal.

Reverting is not rollback or time travel. It is another reviewed proposal that passes through the same approval and writeback boundary.

Portable contracts

Contracts are portable JSON documents.

You can hand-author the JSON or use an optional SQL-like DSL with constructs such as:

• CREATE AGENT CONTEXT


• CREATE CAPABILITY


• Approval policies

The DSL compiles to the same JSON format.

Either way, contracts can be reviewed and versioned in Git like application code.

Explicit limitations

This is a security tool, so I would rather under-claim.

Synapsor Runner:

• Does not make arbitrary SQL safe


• Does not prevent prompt injection


• Does not replace least-privilege database roles


• Does not replace restricted views


• Does not replace row-level security


• Does not replace staging data

It is a scoped enforcement boundary that limits what a compromised or mistaken model can read, propose, and change.

The built-in guarded path intentionally excludes:

• Free-form or model-generated predicates


• UPSERT


• DDL


• Unbounded writes


• Multi-table transactions


• External side effects

Those operations need an application-owned executor that is invoked only after approval, with the application retaining ownership of the transaction and security checks.

Token-cost benefits

A side benefit is that this approach also tends to use fewer tokens.

Because the model calls semantic tools instead of writing SQL:

• It does not need the database schema in context.


• It does not need table and column dumps.


• It avoids list_tables and describe_table round trips.


• It avoids “write SQL → column error → retry” loops.


• Typed arguments can fail before a database round trip.


• Results are bounded by column allowlists and MAX ROWS.


• Aggregate reads can return a scalar such as COUNT instead of sending many rows back into context.


• Approval and writeback happen off-model, so those steps use zero model tokens.

There is a caveat: every capability appears in the model’s tools/list.

A contract that exposes hundreds of tools to one agent can lose the token savings through tool-definition bloat.

The real claim is:

Well-scoped contract → net cheaper

I would treat that as directional rather than a benchmarked number, but “safer and cheaper per run” appears to hold for the common case.

Repository

github.com/Synapsor/Synapsor-Runner

I’m the maintainer, and I would genuinely value feedback from people already connecting MCP clients to real databases:

What workflow did you want to give an agent, but held back because raw SQL or direct API authority felt like too much?

Even a reply such as “this shape wouldn’t fit because…” would be useful.