The Confused Deputy Problem in MCP — and How to Fix It

When you connect an AI agent to a database over the Model Context Protocol, two security flaws do most of the damage: the confused deputy problem and overprivileged tokens. Neither is exotic. Both show up in the default way people wire up an MCP server. And both are why 88% of organizations reported at least one AI-agent-related security incident in the past year.

This post explains both flaws in plain terms and shows why a governed, read-only gateway removes them by design.

The confused deputy problem

A “deputy” is any program that acts on behalf of someone else. It becomes confused when it uses its own privileges to carry out a request instead of the requester’s.

Here’s the MCP version. Your MCP database server holds an admin connection string — it has to, to introspect schemas and run queries. A user without admin rights asks the agent, “delete the test rows in the orders table.” The agent calls the MCP server’s query tool. The server, running with its own admin privileges, happily executes the DELETE. The user never had permission to do that — but the server did, and it never checked whether this user should.

The agent became a confused deputy: it lent its elevated access to a request that should have been denied. Multiply this across an org where one MCP server can reach customer databases, internal tools, and production code in a single session, and a single confused deputy is a breach.

Overprivileged tokens

The second flaw is quieter. Most naive MCP setups store the database password or API key in plaintext in a local config file — the same file that gets copied to every laptop and CI runner that talks to the server. Worse, that one credential usually has far more access than any single agent task needs: full read and write, every table, every schema.

The principle that fixes this is least privilege: each agent should get a dedicated principal scoped to exactly the tools and data its job requires. In practice, almost nobody does this by hand — it’s tedious, and the default is one fat credential.

Why a read-only gateway removes both

A governed gateway sits between the agent and the database and changes the trust model:

  • Read-only by default. A SQL guard rejects every DROP, DELETE, UPDATE, and DDL statement before it reaches the database. The confused deputy can no longer be tricked into a destructive write, because the write path doesn’t exist. See why “read-only” is often not actually read-only in setups that skip this.
  • Per-connection keys instead of raw credentials. The agent authenticates with a scoped API key, not your database password. The real credential never leaves the gateway, so there’s nothing to leak from a config file.
  • Audit logging. Every query is attributable. When 33% of organizations admit they lack evidence-quality audit trails for AI operations, having one is the difference between an incident you can investigate and one you can’t.

This is exactly the architecture the AI2SQL MCP SQL server implements. You connect a database once, get a scoped key, and point Claude, Cursor, or ChatGPT at it — read-only, auditable, no admin credential in sight.

The takeaway

Confused deputy and overprivileged tokens aren’t edge cases; they’re the default failure modes of MCP database access. You don’t fix them with a policy doc — you fix them by making the destructive and overprivileged paths structurally impossible. A read-only gateway does that.

Compare approaches in AI2SQL gateway vs. a Postgres MCP server, or set one up for Claude or Cursor.