Enterprise access control was built around a familiar question: is this person allowed to do this? Identity providers authenticate the person, roles and groups describe what they may do, and reviews periodically confirm that those permissions are still appropriate.

AI agents complicate every part of that model. An agent may act for a person, for a team, or for another agent. It may decide at run time which tools to call and which systems to reach. It may hand part of a task to a second agent that the original requester never sees. Each step carries an implicit claim of authority, and in many current deployments that claim is never written down, constrained, or checked.

Three questions every agent action should answer

A useful starting point is to require that every consequential action taken by an agent can answer three questions:

  • On whose behalf? The human or organizational principal whose authority the agent is exercising.
  • Under what scope? The specific permissions delegated for this task, rather than everything the principal could do.
  • Approved by what policy? The rule that permitted the action, evaluated at the moment the action was taken.
A request passes from a person to a primary agent, then to a sub-agent and finally to a business system. A policy decision point evaluates each hop, and the permitted scope narrows at every step.
Delegated authority should narrow at each hop, with a policy decision evaluated before every consequential action.

Delegation should only ever narrow

The principle of least privilege translates naturally to delegation chains: authority should only ever narrow as it passes from one party to the next. A person who can read and approve invoices might delegate read access to an agent preparing a summary. That agent, in turn, should not be able to pass approval rights to a sub-agent it creates, because it never held them.

Enforcing this requires authorization to be evaluated continuously, close to the action, rather than granted once at the start of a session. This is consistent with the Zero Trust principle that access decisions are made per request, using current context, rather than assumed from network location or a previous login.

Segregation of duties for software that decides

Segregation of duties exists so that no single person can complete a sensitive action alone. Multi-agent systems create a new way to defeat it: one principal, acting through several agents, can request, approve, and execute the same transaction. The control is still satisfied on paper because each step was performed by a different identity.

Closing that gap means tracking the principal behind each agent, not just the agent itself, and evaluating segregation rules against the full delegation chain. It also means defining points where a human approval is required, and ensuring that an agent cannot satisfy that approval on its own behalf.

Policy as code as the enforcement layer

Policy-as-code offers a practical way to make these rules explicit. Authorization rules written as versioned, testable code can be reviewed like any other change, evaluated consistently at run time, and produce a decision record for every action. That record is what makes an agent's behavior auditable after the fact.

The open questions are substantial. How should delegated scope be represented and verified across organizational boundaries? How much context should a policy engine trust when the request itself was composed by a model? What does a meaningful access review look like for an identity that exists for only a few minutes? These questions define a research agenda, and an operational one, for the next generation of identity security.