Overview
MCP standardizes how an AI application discovers and calls tools. Synapsor adds the database-specific commit boundary: reviewed semantic capabilities, trusted tenant and object scope, evidence-backed proposals, approval or deterministic policy, conflict-checked writeback, receipts, and replay.
Without Synapsor: connect agent to database, give it a tool, hope it behaves. With Synapsor: MCP calls a reviewed capability, Synapsor binds trusted context, reads become evidence, writes become exact proposals, and a trusted runner commits only after approval and conflict checks.
For existing Postgres/MySQL, Synapsor does not physically branch or merge the source database. The proposal/evidence/replay state lives in Synapsor, and the external database changes only when a customer-controlled trusted runner applies an approved writeback job.
Request authority versus execution authority
A model-facing MCP tool call can request or propose a database action. It should not carry tenant authority, write credentials, approval identity, arbitrary table names, or final commit authority.
The trusted runner is the execution authority. It receives an approved structured writeback job and validates primary key, tenant, allowed columns, idempotency, and conflict guard before attempting one parameterized row update.
What Synapsor protects
Synapsor protects the database state transition in the Synapsor path: no model-facing raw SQL, trusted scope outside model args, proposal-before-write, exact diff, allowed columns, conflict guard, idempotency, receipt, and replay.
Synapsor does not claim to secure every MCP server, fix prompt injection, protect a compromised MCP host, or replace general MCP security practices.
Developer notes
- Expose semantic tools, not raw SQL.
- Bind tenant, principal, source, object, allowed columns, and row version outside model args.
- Treat proposal creation as success even when approval is required.
- Use conflict receipts to show when the row changed after the agent saw it.