Give data agents their own identities before they reach the warehouse

The access-control question comes before the model question

Enterprises evaluating natural-language data agents tend to start with accuracy: Can the system find the right tables, generate valid SQL and return a useful answer? Microsoft’s Entra Agent ID documentation makes a prior question concrete: Who, exactly, is acting when the agent touches enterprise data?

Microsoft defines an agent identity as a unique account for an AI agent, distinct from workforce, customer and conventional workload identities. That distinction matters for NL2SQL because database access is a tool call with consequences. Entra’s documentation says agent identities are intended to distinguish AI-performed operations, support right-sized access and keep agents away from critical roles and systems. It also separates two modes: autonomous access granted directly to the agent, and delegated access in which the agent acts on a human user’s rights and the user controls what is delegated.

Keep the agent and the human in the same audit story

This is not just naming. Microsoft says Copilot Studio creates an agent identity for each agent, records the creating user as its sponsor and logs agent authentication in Entra. Its conditional-access optimization agent likewise records queries as having been performed by an AI agent and subjects that activity to agent-identity security policies.

For a warehouse team, those examples establish the useful minimum: do not collapse the software actor and the human requester into one generic application principal. The agent identity answers what software acted; delegated identity and sponsorship answer which human authority or owner was involved. The warehouse still has to enforce the actual database permissions.

A practical pre-production review can therefore ask:

1. Is this tool call autonomous or delegated, and is that choice explicit?
2. Does the deployed agent have a unique identity where the platform supports one?
3. Are its warehouse permissions right-sized to the schemas and operations required?
4. Can an investigator recover both the agent and the human requester or sponsor from the identity trail?
5. Does the application log the generated SQL, selected tool and result destination alongside that identity trail?

The first four checks follow from Microsoft’s documented identity model. The fifth is the desk’s derived operational checklist: the source does not prescribe an NL2SQL logging schema, but identity without query evidence still leaves an investigation incomplete.

What this does not prove

The source does not demonstrate that agent identity improves SQL-generation accuracy, and Microsoft’s page does not say every Fabric, Power BI or third-party data agent already uses Entra Agent ID for warehouse execution. The documentation describes the available identity primitive and two Microsoft implementations, not a universal deployment state.

That limit is useful. “Give the agent an identity” is not a substitute for database policy, semantic validation or query review. It is the prerequisite that lets those controls produce an attributable record. If a team cannot say which agent acted, under whose authority, with which warehouse permissions, it has not finished the access design—even if the SQL is correct.