Veto vs read-only Postgres MCP servers
Servers like Postgres Scout MCP, mcp-server-postgres, and similar listings on Glama expose Postgres to AI agents with read-only mode, SQL-injection guards, and schema exploration. That is an access-control strategy. Veto is a statement-level safety gate — complementary, not a replacement.
At a glance
| Read-only MCP | Veto | |
|---|---|---|
| Primary mechanism | Role / connection limits — agent can't write | Deterministic analysis — agent gets block on dangerous SQL |
| Legitimate writes | Blocked entirely (or separate write connection) | Allowed when SQL passes — Veto doesn't execute |
| Ad-hoc agent SQL | SELECT-only | DELETE/UPDATE/migrations vetted before run |
| Bypass risk | Misconfigured roles, wrong connection string | Agent skips the tool — mitigated by workflow + Pro policies |
| Cost / seq scans | Usually not the focus | warn on large scans when schema supplied |
| Connects to prod | Yes (read-only) | Never |
When read-only MCP fits
Agents should only query production — analytics, schema discovery, support lookups. Read-only Postgres MCP servers are a proven pattern (often self-hosted).
When Veto fits
Agents write migrations, run fixes, or touch staging with write access. Read-only roles block legitimate work and have been bypassed. Veto answers: "given this exact ALTER TABLE / DELETE, what's the verdict?" — including destructive statements hidden in CTEs.
Why not just read-only?
Read-only is coarse: it can't catch a costly SELECT on a billion-row table inside a write-allowed role, and it doesn't help when the agent has a migration connection. Veto adds fine-grained, reproducible findings the agent (or human) acts on before execution.
Recommended stack
Read-only MCP for prod exploration + Veto on any connection where the agent can write. Roles define what's possible; Veto judges each statement.