Why Human-Centric Access Controls Will Never Work for AI

AI agents are not just another type of user. They break the assumptions behind roles, standing privileges, and periodic access reviews.

Every major architectural shift exposes the limits of the access control models that came before it. Multi-tenant SaaS challenged filesystem permissions. Microservices challenged monolithic session management. Cloud challenged perimeter-based security. Now AI agents are breaking the authorization patterns organizations have spent the last decade standardizing.

The problem is not that AI introduces one more application that needs access. The problem is that AI changes who is asking, how often they are asking, what they need, and how quickly the answer must be delivered.

Human-centric access controls were built for people:

• A person requests access.
• A person receives a role.
• A person performs a known task.
• A person uses standing permissions.
• A person’s access is reviewed periodically.

Agents do something fundamentally different. They operate in loops, reasoning over a task, calling tools, querying data, evaluating the result, and repeating until the task is complete. An agent may issue hundreds of requests across multiple systems without a human reviewing every step.

The old model cannot safely support that behavior by simply adding more roles, service accounts, tickets, and approval workflows.

Human-centric access controls will never work for AI at scale because they assume access can be decided before the work begins. Agents need access decisions while the work is happening.

The human access model depends on predictability

Enterprise access management has traditionally followed a familiar pattern:

1. Create a role.
2. Assign permissions to the role.
3. Add users to the role.
4. Review membership periodically.
5. Report on access for compliance.
6. Expand the role when someone needs more.
7. Create another role when the exception becomes common.

This model is not inherently irrational. It works reasonably well when users, applications, and data needs are predictable.

A finance analyst may need durable access to a known set of financial data. A business application may need a consistent permission set to perform a well-defined function. A team may have a stable operating responsibility that maps cleanly to a role.

But the model depends on assumptions that AI agents invalidate:

• The consumer is known.
• The application is known.
• The task is known.
• The data needed is predictable.
• The access duration is understood.
• The permission can remain valid until someone revokes it.
• Future exceptions can be represented through another role or approval path.

As long as those assumptions hold, static access models can appear manageable.

When they fail, organizations are forced to turn uncertainty into permanent permission.

AI changes the access problem itself

Generative AI has made everyone a potential data consumer.

A business user can ask for a performance summary in natural language. An executive can ask an assistant to compare regional results. An operations team can ask an agent to investigate an anomaly. A quality engineer can ask an agent to correlate warranty claims, manufacturing data, supplier records, software versions, and telemetry.

The user does not need to know where the data lives or how to write the query. The agent handles the reasoning and execution. That is the value of the technology. It is also the access control problem.

Behind every natural-language request is a governance decision:

Should this person or agent be allowed to see this data, under what conditions, and for how long?

For human users, organizations have often answered that question through identity, role, and standing entitlements.

For agents, the system also needs to understand:

• Which human delegated the work
• Which agent is acting
• What task is being performed
• Why the data is needed
• What data is required
• How long the access should remain active
• What should happen when the task ends

AI agents are a new class of data consumer that requires explicit identity, delegated authorization, temporary provisioning, and a dual-identity audit trail. This is not just more access demand. It is a different access decision.

An agent is not a user with a faster keyboard

An agent operates differently from a human.

A human generally performs a deliberate action, waits for a result, and decides what to do next. An agent may:

1. Receive a goal.
2. Break the goal into subtasks.
3. Call a tool.
4. Query a database.
5. Inspect the result.
6. Form another query.
7. Call another tool.
8. Repeat until it believes the task is complete.

This loop changes the scale, speed, and autonomy of data access. The governance model must support continuous, multi-step access rather than the occasional, deliberate request that legacy workflows were built to handle.

A human-scale approval process cannot be inserted into every step of an agent loop without making the agent unusable. But removing the human process entirely and giving the agent broad standing access creates a different problem.

Organizations end up choosing among three bad options:

• Slow the agent down with human approval queues.
• Give the agent broad access to avoid delays.
• Let the agent impersonate users and inherit their existing permissions.

None of these solves the underlying mismatch.

Role explosion is not a cleanup problem

When a new AI use case appears, organizations often respond by extending the existing access model. They add users to existing roles. They create new agent roles. They add exceptions. They create more service accounts. They build new approval paths. They schedule more reviews.

Each individual decision may seem reasonable. The problem is the cumulative effect.

Every combination of user, agent, data domain, task, sensitivity level, region, purpose, and duration creates pressure for another permission or exception.

The result is familiar:

• Role and permission sprawl
• Stale access
• Overprovisioned identities
• Conflicting entitlements
• Approval backlogs
• Duplicated controls
• Unclear ownership
• Increasingly difficult audits

Role-based access turns uncertainty about the future into permanent permission.

The more important problem is not that there are too many roles. It is that roles are being used to precompute access for tasks that cannot be predicted in advance. The organization is trying to anticipate every dataset every user might ever ask an agent to access. That is an impossible requirement.

The “all-knowing” barrier

Consider an agent that acts on behalf of every employee in an organization.

If the agent authenticates as the user, it appears to inherit the user’s existing permissions. That sounds reasonable until the organization asks what must be provisioned in advance. Every user needs an account in every relevant data platform. Every user must have access configured for every dataset they might ever ask about. Every new dataset or use case must be anticipated before the agent can access it.

The organization must become all-knowing about future demand.

That creates several practical problems.

The agent inherits too much

If a user has administrative or highly privileged access, the agent may inherit it as well. The agent does not understand which parts of the user’s access are relevant to the current task. It simply receives the full permission footprint.

The platform cannot distinguish the human from the agent

If the agent authenticates as the user, the data platform may record the user identity even when the agent performed the action. That makes it difficult to determine whether the user acted directly or whether an agent acted on the user’s behalf.

Every user needs a platform account

If an agent acts as the user, that user must exist in every data platform the agent may access. That creates account sprawl, standing privileges, OAuth dependencies, and a larger attack surface. Offboarding becomes dangerous: disable the user and an automated workflow may break, or keep the account active and preserve access that should no longer exist. The agent inherits the user’s entire platform footprint, even when the task requires only a fraction of it. 

Standing access remains in place

The permissions exist before the task, during the task, and after the task. That is incompatible with a zero-standing-privilege model. The result is a system that may be familiar, but is neither truly least privilege nor clearly attributable.

The three ways organizations try to give agents access

Most organizations fall into one of three access patterns.

Shared service account

The agent uses a shared identity with a predefined set of permissions.

This is easy to start with, but the access is usually coarse and persistent. Every agent action may look the same in the logs. New use cases require more permissions, more service accounts, and more control-plane logic.

The result is role explosion with an agent attached to it.

Human impersonation

The agent authenticates as the user through OAuth or a similar mechanism.

This is familiar, and existing permissions may appear to work. But it creates rights inflation, account sprawl, and audit ambiguity. The agent inherits the user’s permissions without necessarily understanding which ones are relevant to the task.

Just-in-time delegated access

The agent authenticates as itself and acts on behalf of the user.

A policy engine evaluates the relationship between the agent, the user, the task, and the data. It provisions a temporary permission at the data tier, scoped to the work at hand. When the task or session ends, the permission is removed.

This is the only one of the three patterns designed around temporary authority and explicit delegation – it is the correct pattern.

The model is simple:

The agent acts for the user, but it does not become the user.

Authorization must be externalized

Traditional systems often assume that authorization belongs inside the application or data platform making the access decision. That assumption is increasingly difficult to maintain when agents operate across multiple platforms and tools. Agent identity, orchestration, reasoning, and data access are separate concerns.

A control plane may determine which agents are allowed to invoke which tools. A logic plane may translate a user’s request into queries or API calls. The data plane ultimately determines which tables, rows, columns, and fields the agent can access.

These layers need to work together.

Identity systems and agent gateways can answer important questions:

• Is this agent registered?
• Is it approved to authenticate?
• Which tools can it invoke?
• Who owns it?
• Is its behavior anomalous?
• How should it be decommissioned?

But those systems do not necessarily determine which data the agent should receive after it reaches the data platform.

Likewise, the data platform can enforce the role or token presented at query time. It may not know the full human-to-agent delegation, the task purpose, the applicable policies across other platforms, or when the authority should expire.

This is why authorization needs to be defined externally from individual platforms.

The authorization layer connects:

• Human identity
• Agent identity
• Delegation
• Policy
• Data sensitivity
• Task context
• Temporary provisioning
• Audit evidence

The data platform remains the enforcement point. The authorization layer determines what should be enforced.

This is complementary to native platform security, not a replacement for it. Native data platform controls provide important enforcement capabilities. An authorization layer adds centralized policy, provisioning orchestration, cross-platform consistency, and agentic access patterns on top of those foundations. :cite[dk9]

What permission on demand looks like

A just-in-time delegated access flow can work like this:

1. A human asks an agent to perform a task.
2. The agent submits a request with its own identity, the human’s identity, and a justification.
3. The authorization layer evaluates the request against policy, identity, data sensitivity, and available context.
4. A short-lived role, token, or scoped permission is provisioned into the data platform.
5. The platform enforces the permission as the agent performs the task.
6. The access expires when the task or session ends.
7. The audit trail records who delegated, which agent acted, what policy applied, and what data was accessed.

The long-term direction is to evaluate access closer to the moment of the question, based on the specific task and context. The current foundation includes delegated authorization, justification tokens, role vending, ephemeral provisioning, and pre-approved criteria matching. This gives the organization a more precise control boundary.

The user’s existing entitlements still matter. The agent’s identity still matters. The task still matters. But the agent does not receive every permission the user happens to possess. It receives the authority required for the work.

A large manufacturing customer shows what can change

A large manufacturing customer provides a useful example of this transition.

The company had grown beyond a model based on manually maintained, platform-specific policies. A central governance team managed roughly 20,000 legacy policies and handled access requests across cloud environments and legacy data infrastructure. Engineers routinely waited more than five days for domain-specific data. Cross-domain access and sensitive-field unmasking could take several weeks.

The company’s governance vision centered on centrally managed policy and dynamically evaluated access. Instead of managing permissions table by table, the organization could define access through attributes, identity, context, and intent.

That created a foundation for several improvements:

• Approximately 20,000 legacy policies were consolidated into roughly 20 attribute-based rules.
• Standard access workflows were automated.
• Time to data was reduced from more than five days to approximately two minutes for many standard requests.
• Data discovery and access were connected through the company’s existing catalog experience.
• The same policy model created a path for human and agent access.

The agentic use case extended that model further. With on-behalf-of access, the company opened a path to support tens of thousands of users through an enterprise AI assistant without requiring an individual data platform account or standing privilege for every user.

The important point is not simply the number of users. It is that the organization did not need to create a permanent role for every possible user and agent combination. It could use centralized policy to determine access dynamically, provision the appropriate authority into the data platform, and remove that authority when the task ended.

That is the difference between asking:

Which role should this person belong to?

And asking:

What access is justified for this person, this agent, this task, and this moment?

Roles still have a place, but they cannot be the whole model

The answer is not to eliminate roles or replace every standing entitlement with a dynamic decision.

Stable and predictable needs can continue to use standing access. Durable human entitlements, known application workflows, and established business processes do not need to become dynamic simply because agents exist.

The access model needs to become dual:

• Standing access for stable needs
• Governed requests for exceptions
• Just-in-time provisioning for dynamic agent tasks
• Human approval for ambiguous or high-risk decisions
• Continuous audit across every access path

Roles are useful for what is stable. They are not enough for what is dynamic.

Compliance cannot remain entirely periodic

Periodic recertification remains valuable for durable access. But it cannot provide all the evidence required for agentic workflows.

Agentic access introduces new questions:

• Which human delegated the action?
• Which agent acted?
• What task or justification was submitted?
• Which policy applied?
• What access was provisioned?
• What data was accessed?
• When did the access expire?
• What result was returned?

A complete audit trail must connect the human, the agent, the policy decision, the temporary permission, the data accessed, and the result.

Recertification tells you whether access should still exist. Runtime audit tells you why access existed.

As access becomes faster and more dynamic, compliance must become more continuous and contextual. An organization needs to know not only who has access, but what actually happened during each agent session.

The old model is not going to become agent-ready

Human-centric access controls were designed for people, applications, and predictable workflows.

They assume that:

• A person is requesting access.
• The task is known in advance.
• The data need is relatively stable.
• A human can review the request.
• The resulting permission can persist.
• The platform only needs to evaluate one primary identity.

AI agents break those assumptions. They operate continuously, generate dynamic requests, act on behalf of other identities, and need access decisions at machine speed. That is why organizations cannot make the old model agent-ready by adding more roles, more service accounts, more tickets, or more review cycles.

The authorization pattern itself has to change.

Organizations need to:

• Treat agents as distinct identities
• Make delegation explicit
• Evaluate access in context
• Provision permissions temporarily
• Enforce policy at the data layer
• Work across data platforms
• Preserve human oversight for sensitive decisions
• Capture a complete human-to-agent audit trail

The conclusion is unavoidable:

Human-centric access controls will never work for AI at scale because they were designed to decide access before the work begins.

AI requires access decisions while the work is happening.

The question is no longer simply whether a person has a role or whether an agent can authenticate. The question is whether the organization can govern what an agent is allowed to answer, on behalf of whom, for what purpose, and with what evidence.

That is the authorization model required to move AI from experimentation to production.