How are you giving your agents database access without handing them write privileges?
Building agents that need to read from a database keeps running into the same tension: to let the agent query your data, you usually give it a connection string — and now your agent can also UPDATE, DELETE, or DROP if it hallucinates a "fix" or gets prompt-injected into one.
For most agent use cases the actual need is read access: look up a record, check the schema, pull some rows to reason over. The write capability is pure downside — it's where all the blast radius lives and almost none of the value.
So I built an MCP server that gives an agent read access and makes writes impossible, not just discouraged:
- Point it at a Postgres connection string, it exposes an MCP endpoint your agent connects to.
- Every query runs inside a
READ ONLYtransaction — even if the agent generates a destructive query, the database refuses it. - A guard rejects mutation statements and dangerous functions (file reads, SSRF-style calls) before they execute.
- Returns schema + results as structured content the agent can act on, no second round trip.
The thing I keep coming back to: an agent with read-only data access is useful; an agent with write access to prod is a liability you haven't been billed for yet.
Curious how others here handle this — separate read replica? Restricted role? App-layer wrapper? Just trusting the model? There's a sandbox to try the approach without connecting your own DB (link in comments).
Posted Jun 3, 2026, 1:15 PM UTC