Blog

Is read-only MCP access to your database safe?

Agentic Analytics · July 7, 2026 · 5 min read

Read-only access sounds like a safe way to let an AI agent query your database. On its own, it is not. The clearest proof is a real vulnerability found in one of the most-used database connectors for AI agents, where a “read-only” server could be tricked into dropping an entire schema. If you are wiring an agent to your data, this is the failure mode to understand first.

The read-only illusion

The usual plan for connecting an agent to a database is to give it a read-only role, often through an MCP server. MCP, the Model Context Protocol, is the emerging standard for connecting agents to tools and data sources, and a database MCP server is how many agents get warehouse access.

The idea is that a read-only role cannot change anything, so the worst an agent can do is run a bad SELECT. The problem is that read-only gets enforced in more than one place, and those places do not always agree.

What actually happened

In 2025, Datadog’s security team found a SQL-injection vulnerability in Anthropic’s reference Postgres MCP server, one of the most widely used connectors for giving an agent database access. The server wrapped every query in a read-only transaction, which seems safe. But it passed the model’s SQL straight through, and it accepted multiple statements separated by semicolons.

That combination is the hole. Anything that could shape the agent’s input could send:

COMMIT; DROP SCHEMA public CASCADE;

The COMMIT ends the read-only transaction. Everything after it runs with the connection’s full privileges. The “read-only” server just deleted the schema.

Anthropic patched it and archived the server as not ready for production. The uncomfortable part is what came next. The deprecated package still gets around 21,000 downloads a week on npm. A lot of agents are still wired up with a connector that has a known way past its own read-only guard.

Why read-only is not the safeguard people think

The bug is patched, but the lesson is general. Read-only at the connector is not the same as read-only at the database, and neither one covers the real risks of an agent with data access.

  • The connector can be bypassed. A read-only wrapper is only as good as its parsing. Semicolons, comments, and transaction control are all ways around a naive guard.
  • Read-only still exposes everything readable. Even a perfect setup lets the agent read every table its role can see. If that includes salaries, PII, or another team’s data, a single question can surface it.
  • The agent is not the only actor. Prompt injection means the “question” can come from a document, a webpage, or a row of data the agent reads. Give it a live SQL connection and a way to be steered, and read-only is a thin defense.

What safe access actually looks like

Safe access is not one setting. It is a few layers, and none of them is “trust the model.”

  • Least privilege at the database. A dedicated role with access only to the specific tables and views the agent needs, not the whole warehouse. This is ordinary data governance, and it caps the blast radius no matter what the connector does.
  • Do not hand the model raw SQL execution. The safer pattern is to let the agent select from a defined, governed set of metrics rather than composing and running arbitrary SQL. A semantic layer does this, and as a side effect it removes the free-form SQL that injection relies on.
  • Run it in your environment. A self-hosted, open-source agent keeps the data and the queries inside your infrastructure, so a connector flaw is not also a path off your network.
  • Scope, log, and review. Log every query the agent runs, and make sure a person can audit what it touched.

This is the difference between wiring a model to a database and building an analytics agent you can trust. Open-source agents like nao are built around the governed version, where the agent works from defined context and permissions rather than an open SQL connection. There is more on the trust side in is it safe to give an AI agent your data.

Is read-only access safe for an AI agent?

Not by itself. Read-only limits writes, but it still exposes every table the agent’s role can read, and read-only wrappers can be bypassed. A real SQL-injection flaw in Anthropic’s Postgres MCP server let a read-only connection run COMMIT; DROP SCHEMA public CASCADE; and delete data. Safe access needs least-privilege roles, a governed query layer, and logging, not just a read-only flag.

Is the Postgres MCP server safe to use?

Anthropic’s reference Postgres MCP server had a SQL-injection vulnerability that bypassed its read-only restriction. Anthropic patched it and archived the project as not production-ready, but the deprecated npm package still gets around 21,000 downloads a week. If you use it, move to a maintained fork and do not rely on its read-only guard as your only protection.

How do you give an AI agent safe access to a database?

Use least privilege so the agent’s role can only reach the tables it needs, prefer a governed semantic layer over letting the model run arbitrary SQL, run the agent in your own environment, and log every query for review. Read-only alone is not enough, because it still exposes readable data and can be bypassed at the connector.