Database-agent security is splitting into four control planes—and none can replace the others

Three releases and implementation guides from Google Cloud, WrenAI and Starburst point to the same design lesson: “read-only” is not one control. A production database agent crosses distinct boundaries for identity, semantic planning, SQL execution and observability. Each catches a different failure mode, and evidence at one layer does not prove the others are safe.

1. Identity limits the blast radius

Google warns that coding agents commonly operate with authority delegated by a user and can mistake data in BigQuery or Cloud Storage for instructions. Its mitigation guidance recommends constrained workstations, organization restrictions, Principal Access Boundaries, VPC Service Controls and Model Armor. Those controls restrict reachable resources or inspect retrieved content; they do not make the model reliably distinguish evidence from commands. (Google Cloud)

Starburst takes a related identity-first approach for its hosted MCP service. OAuth carries the logged-in user into Galaxy, where RBAC and ABAC determine what the agent may access. The company’s architecture explicitly says agents are limited to operations available to that user. (Starburst)

2. Planning is where business policy becomes query shape

WrenAI’s semantic-core 0.5.0 adds a separate planning boundary. Its AccessControlProvider can inject row filters, omit denied columns from wildcard expansion and reject explicit references before semantic SQL is finalized. Provider errors propagate instead of falling back, while subqueries introduced by a policy are analyzed recursively. (WrenAI implementation)

But the implementation leaves identity binding to the application: request-specific identity must be attached to the provider or read from session properties. That makes identity and planning complementary. A correctly written row filter is useless if it is evaluated for the wrong principal. (WrenAI implementation)

3. Execution must distrust tool metadata

Starburst draws the execution boundary more sharply. MCP’s readOnlyHint is advisory, so Galaxy parses each proposed statement with Trino’s SQL parser and permits an allow-list of read-only operations such as SELECT, supported SHOW statements and non-destructive EXPLAIN plans. Data-modifying SQL is rejected before it reaches the cluster. (Starburst)

That protects against a client or model ignoring a label. It does not validate the business meaning of a permitted SELECT, which is why planner-level row and column policy remains a separate concern.

4. Audit is the evidence layer

Galaxy records MCP operations in its audit system and tags agent-originated SQL as mcp-query-tool; client information and trace tokens can follow the execution path. That makes agent traffic distinguishable from interactive or BI queries after the fact. (Starburst)

The practical review checklist is therefore four questions, not one: Which identity is bound to this request? Which rows and columns can the planner expose? Which statement classes can the executor run? Can operators reconstruct what happened? Add Google’s fifth warning—can retrieved data itself manipulate the agent—and “read-only” becomes a layered claim that has to be tested end to end, not accepted from a tool description.