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 CONTEXTCREATE 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_tablesanddescribe_tableround 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
COUNTinstead 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.
Top comments (2)
This framing is exactly the bit I wish more MCP/database tooling made explicit: "no SQL tool" and "no commit tool" are stronger than asking the model to be disciplined.
The proposal/evidence/replay boundary is especially useful because it gives reviewers something concrete to inspect. One extra check I'd add in production is drift handling at approval time: re-read the source row/version and fail closed if the evidence no longer matches. Otherwise a perfectly reviewed proposal can become stale between review and writeback.
The portable contract idea is interesting too. It makes the security review about a small capability surface, not an infinite set of possible SQL strings.
Good point. We already fail closed on target-row drift, but the final freshness check happens at apply rather than as a database read during approval. The proposal captures the expected source version; apply locks and re-reads the row under trusted tenant/principal scope, and the guarded mutation includes the primary key, scope, and expected version. A mismatch returns VERSION_CONFLICT with zero rows changed and requires a new proposal.
That timing is intentional because the row could also change after approval. Approval itself binds the reviewer to the immutable proposal hash version and stored evidence; it does not currently refresh every supporting evidence source. A pre-approval freshness check would still be useful
for reviewer UX and for explicitly versioned evidence dependencies, while apply-time validation remains the final safety gate.