When "Read Only" in the AI Connector Does Not Mean Read Only in the Database | G360 Technologies

Someone outside an organization places crafted SQL into content that eventually reaches an employee using an AI assistant. The employee is authenticated and asks the assistant for information. Behind the chat window, an MCP server prepares to send a query to PostgreSQL.

The connector is configured as read only.

It lets the query through.

That is the failure at the center of CVE-2026-85787, disclosed by AWS on September 4. The vulnerability affected versions of the AWS Labs PostgreSQL Model Context Protocol server before 1.1.7, which connects MCP-compatible AI clients to Aurora PostgreSQL and RDS for PostgreSQL. AWS identifies version 1.1.7, released on June 25, as the remediated version.

The flaw sat inside a control that was supposed to stop the AI integration from crossing from retrieval into modification. In read-only mode, the server inspected SQL and rejected operations it considered capable of changing data or database state. Its list of prohibited inputs was incomplete. Crafted SQL could escape that check and continue toward PostgreSQL.

How the Mechanism Works

Passing the connector did not give the query new database privileges. PostgreSQL still evaluated it using the account through which the MCP server was connected. A query reaching a role limited to CONNECT, schema USAGE, and SELECT would still encounter the database's own authorization boundary. A connector using a more privileged account presented a different problem: authority that was supposed to be unreachable through the AI interface was still available underneath it.

So the effective security path was not simply “AI connector equals read only.” It was:

AI interaction → connector validation → database authorization → execution

The connector controlled one gate. PostgreSQL controlled another.

That distinction is easy to miss because both can look identical from the user's side. Ask the assistant for information and it returns information. Nothing in that normal interaction reveals whether writes are impossible because PostgreSQL will reject them, or because a piece of connector code intends never to send them.

CVE-2026-85787 made the difference visible. Once the connector's validation could be bypassed, the permissions assigned farther down the stack became decisive.

AWS's mitigation reflects that architecture. It recommends a dedicated, minimally privileged PostgreSQL role for the MCP server, with only the permissions required for the workload, and recommends forcing default_transaction_read_only at the role level. It specifically warns against connecting the server as a PostgreSQL superuser, rds_superuser, or cluster master user.

Analysis

This is a familiar security principle appearing in a newer integration layer. A policy enforced by an intermediary is different from authority denied by the system that owns the resource. AI connectors now sit between users and databases, document stores, APIs, SaaS applications, and other enterprise systems, which means they add another place where those two ideas can be confused.

AWS had already disclosed a related example in August. A separate vulnerability in the AWS Labs DocumentDB MCP Server (CVE-2026-18954) allowed write-capable aggregation stages to bypass its default read-only enforcement. The technical mechanism was different, but AWS again recommended using database credentials belonging to a genuinely read-only user.

Two disclosures do not establish that MCP servers generally suffer from the same defect. They do show why the location of an access control matters.

Implications for Enterprises

For security and platform teams, that changes what it means to review an AI integration. Checking that a connector's configuration says “read only” is only one part of the exercise. The review also has to follow the identity the connector carries into the system behind it.

What database account does it use? Which schemas can that account reach? Can it insert, update, delete, execute functions, or change database state? Which restriction survives if the connector makes the wrong decision?

The same separation matters for monitoring. The AI layer can record what a user asked. The connector can record what it attempted to send. Database audit records can show what actually arrived and what the backend permitted. Those logs describe different points in the same chain.

Risks and Open Questions

There are limits to what can be concluded from this particular vulnerability. The public disclosure does not identify the exact SQL construct used to escape validation, and it does not establish production exploitation. It also does not disclose whether the researcher demonstrated successful modification in an end-to-end test.

None of those unknowns requires a hypothetical breach to make the architectural lesson useful.

As enterprises give AI systems access to infrastructure that already has mature authorization controls, “What is the AI allowed to do?” is only the first question.

The harder one is: when the AI-facing control gets it wrong, what is the system underneath still capable of stopping?

How the Mechanism Works

Analysis

Implications for Enterprises

Risks and Open Questions

Further Reading