A data agent needs the user’s identity twice: when it retrieves context and when it runs SQL

Identity is part of the question

A natural-language query is not fully specified by its words and schema. It also depends on who is asking. dagctl’s October 12 evaluation tested an agent across 14, 100 and 1,000-table environments and concluded that the agent could find relevant data while still missing two pieces of business context: what an identifier means and who the requester is. That second miss matters before SQL is generated, because user identity can determine which definitions, examples and policy-aware context should be retrieved.

This creates a boundary that teams can easily implement only halfway. Passing identity to the warehouse at execution time can stop an unauthorized query, but it does not prevent the agent from retrieving irrelevant or sensitive context while planning. Conversely, filtering retrieval without preserving identity at execution leaves the final database call dependent on a shared agent credential.

The execution side is becoming explicit

Immuta’s Agentic Data Access documentation makes the execution half concrete. Its connection guide is framed around enabling a registered agent to run queries on behalf of users, while the product’s agent-management surface records agent activity. The important architectural point is not a particular vendor implementation: the agent and the human requester are distinct principals, and the data platform needs enough context to govern the combined session.

Google’s Data Agent Kit shows why this is a multi-system problem. The kit puts BigQuery, Spanner, AlloyDB and Cloud SQL behind IDE and coding-agent interfaces. Its overview says AlloyDB supports IAM database authentication only, while Cloud SQL supports IAM and built-in database authentication. The same natural-language workflow can therefore cross services with different identity mechanisms; “the agent is authenticated” is not a complete authorization model.

A practical two-check design

For enterprise NL2SQL, identity should be tested at two separate points:

1. Retrieval: verify that the user’s role, business domain and data entitlements constrain schemas, examples, semantic definitions and memories supplied to the model.
2. Execution: verify that the generated SQL runs with an attributable, least-privilege principal and that the audit record preserves both the agent and requesting user.

Teams should test these independently. A useful red-team case is to give two users the same prompt but different entitlements, then compare both the retrieved context and the executed query. If only the final SQL differs—or if both users see the same planning context—the identity boundary is incomplete.

The emerging lesson is simple: user identity is not metadata attached after generation. It is an input to generation and a control on execution.