Most database MCP servers hand your AI agent execute_sql â full read/write authority, one prompt injection away from disaster. Synapsor Runner replaces that with reviewed business actions: tenant-scoped semantic tools like billing.propose_late_fee_waiver. Writes become proposals a human approves outside the model's reach, then apply with guards, receipts, and replay. Run npx @synapsor/runner audit to score your current MCP setup's risk in 60 seconds. Local-first, Apache-2.0, no account needed.

Hi Product Hunt! I'm Sandesh, the founder of Synapsor. I built this after watching how casually teams were wiring AI agents straight into their databases with execute_sql. One prompt injection away from a very bad day and realizing the missing piece wasn't a better model, it was a real boundary. The fastest way to connect an AI agent to a database is also the most dangerous: hand it execute_sql(sql: string) and hope it behaves. Most database MCP servers work exactly this way. We built Synapsor Runner around a different boundary. The model never sees raw SQL. It gets reviewed business capabilities like support.propose_plan_credit. It can inspect tenant-scoped data and create an exact proposal, but it cannot approve or commit the write. A human approves outside the model's reach; guarded writeback then checks the row, tenant, allowed columns, and expected version before applying, and every step leaves a receipt and a replay trail. You can see your current risk before adopting anything. This scores a typical raw-SQL setup in about 60 seconds, no database or account needed: npx -y @synapsor/runner audit --example dangerous-db-mcp And the full proposal, approval, and receipt loop, also with no database: npx -y @synapsor/runner demo --quick It's local-first and Apache-2.0. Your database credentials never leave your machine. The contract spec and SQL-like authoring DSL are separate open-source packages, so capabilities get reviewed in Git like any other code. We deliberately don't claim safe arbitrary SQL, prompt-injection prevention, or unbounded multi-row writes. It's a scoped safety layer, not magic. If you're already letting agents touch a staging database: which business action is hardest to expose without handing the model too much authority? That's the question we keep running into, and I'd love to hear yours. Code and demo: https://github.com/Synapsor/Syna... Why we built it: https://synapsor.ai/blog/stop-gi...

🎯 Synapsor Runner

Interesting approach.

What made you choose reviewed database actions instead of letting AI generate SQL with safeguards?

Feels like that decision says a lot about the users you're optimizing for.

Finally ran the audit on my setup and the risk score genuinely surprised me. Love that the proposal-then-approve pattern keeps writes out of the model's reach, such a sensible approach.