Your data access model assumes a human is asking

Before a team I worked with deployed an internal AI assistant on their data platform, we ran the AI agent in a sandboxed environment with query logging enabled and compared what it actually read against what its documented task required. The task was to summarise product usage data for weekly reporting. The agent had queried HR tables — not because it needed them, but because they were visible and it enumerated what was available before deciding what to query. Nobody had restricted the HR tables. Nobody had thought to.

The data access model the agent inherited was designed for a data consumer who searches intentionally. A human analyst approaches a data platform with a specific question and forms a query to answer it. Their data access is governed at the query level — can this role read this table? Agents do not work that way. They discover what exists before they decide what to query. That enumeration pattern is the behaviour the permission model was never designed for.

The enumeration gap

RBAC answers one question: can this role read this table? It was designed for a data consumer who arrives with a formed query. An agent arrives with a task and discovers what data is available before deciding what to query. Those two behaviours are indistinguishable at the query level but produce different access risks — a human data consumer is unlikely to query a table they did not know existed; an agent's enumeration is how it finds out what exists.

The practical consequence is that an agent with a reasonable-sounding RBAC role can discover and read data its task has no need for — not by circumventing any permission, but by doing exactly what the data access model permits, in a pattern the data access model was never designed to govern.

The inherited credential

The most common data access profile for a production agent is the credential its developer used during testing. The reasoning follows a familiar pattern: the credential worked during development, scoping it down requires knowing exactly what the agent needs, and that question was never formally answered. Restrictions deferred to avoid slowing the build are rarely revisited before deployment.

Across the agent deployments I have reviewed, the development credential has almost always become the production credential unless someone had already thought specifically about data access scoping before the build started. It is not negligence — it is the absence of a defined moment when the question is formally asked.

The three unanswered questions

When I review an agent's data access model, three questions have almost never been formally addressed: what data can the agent discover — which schemas, tables, and metadata are visible to it without an explicit query? What can it read without a per-query permission grant — what is ambient versus gated? And who is accountable when it reads data it should not have?

Every deployment has answers to these questions. They are just not answers anyone designed. The agent can see what its inherited credential permits. It can read what it can see. Accountability defaults to whoever deployed it — a provisioning decision treated as a governance outcome.

No existing role owns these three questions by default. Data governance owns data lineage, access control, and the data dictionary. Security owns threat modelling and access logs. Neither function has been asked to define what a specific agent should and should not be able to see — because until recently, every data consumer the platform served was human, and human data consumers have never needed that level of credential scoping.

The leadership mandate

The gap is not technical. Attribute-based access control, per-agent scoped credentials, and semantic access layers are available primitives — none of them are new engineering problems. The gap is that no one has been asked to design the agent's data access model deliberately, as a governance step that precedes deployment rather than a provisioning decision made once and never revisited. The question of what the agent should be able to see has been left to default, and the default was never designed for a data consumer that enumerates.

The path forward

Before the next agent reaches production, one step closes most of the gap: run the agent in a sandboxed environment with query logging enabled, map what it actually reads against what its documented task requires, and scope the production credential to the minimum. This is the 2026 application of the principle of least privilege — applied to a data consumer type the original data access model never encountered.

Most teams discover what their agents can actually read when something goes wrong in production. The data access audit makes that discovery deliberate — and considerably less consequential.