How are you giving your agents database access without handing them write privileges?

Discussion

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 ONLY transaction — 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

111
Loading comments…