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
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 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.
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:
The result:
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.
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.
A proposal records the requested before-and-after state but does not modify the source database.
Approval and writeback happen outside MCP.
When an approved proposal is applied, Runner rechecks:
A stale row becomes a conflict instead of a silent overwrite.
Every apply operation is recorded with a receipt and replay linkage.
By default, activity is stored in a local SQLite ledger.
A shared PostgreSQL runtime store is also available for multi-process deployments.
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.
For reviewed batch operations:
This is not a path to arbitrary UPDATE
statements.
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.
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
The DSL compiles to the same JSON format.
Either way, contracts can be reviewed and versioned in Git like application code.
This is a security tool, so I would rather under-claim.
Synapsor Runner:
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:
UPSERT
Those operations need an application-owned executor that is invoked only after approval, with the application retaining ownership of the transaction and security checks.
A side benefit is that this approach also tends to use fewer tokens.
Because the model calls semantic tools instead of writing SQL:
list_tables
and describe_table
round trips.MAX ROWS
.COUNT
instead of sending many rows back into context.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.
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.