How should IAM teams classify AI agents that switch between delegated and autonomous work?

Why classification has to follow the agent’s operating mode

An AI agent can move between two very different control states in the same workflow. When it is acting under a person’s direction, the security question is about delegated authority and approval. When it is executing with its own credentials and choosing actions at runtime, the question becomes one of identity, privilege, and containment. A permanent label hides that difference and usually leads to the wrong control model.

The practical test is whether the agent is making a decision that changes its authority boundary. If the answer is yes, treat the action as a non-human identity problem for that moment. If the agent is merely carrying out a human-approved task, classify it as delegated access and govern the human-to-agent relationship, not the model itself. That is the same logic behind AI Agent Authorisation Guide.

That distinction matters because a single agent may use human session context one minute and a service credential the next. The right classification is therefore event-based, not product-based, and it should be anchored to the action that actually creates risk, such as consent, token use, tool invocation, or independent resource access. For readers who want the broader identity model, Agentic AI Identity Guide explains how delegation, registration, authentication, and retirement fit together.

What changes when the agent is autonomous versus delegated

Delegated mode means the agent is extending a human’s authority, so approvals, scope, and traceability are the main controls. Autonomous mode means the agent is acting as its own principal, so the core questions become what it can authenticate with, what it can reach, and whether its permissions are still appropriate for the runtime task. The same interface can therefore require very different governance depending on the current mode.

In delegated mode, the team should care most about consent boundaries, impersonation, and whether the agent is accidentally inheriting more access than the user intended. In autonomous mode, the team should care most about the agent’s standing privileges, how credentials are issued and revoked, and whether policy is evaluated per action rather than per application. That is why Zero Trust for AI Agents is a useful companion: verify the principal and the request each time, not just at login.

Teams also need a consistent way to describe mixed-mode behavior. If the same agent can switch between modes, the classification should follow the current trust boundary and not the most permissive historical state. A strong operational model is to register the mode with the action, log which credential or delegation chain was used, and route the event to the appropriate control owner. The Agentic AI Identity Guide and AI Agent Observability, Audit and Incident Response Guide both support that operating model.

How IAM teams should model mixed-mode AI agents

The cleanest approach is to treat mode as a first-class attribute in the identity lifecycle. When the agent is delegated, bind it to the human principal and the approved task. When the agent is autonomous, bind it to a distinct non-human identity with its own ownership, lifecycle, and review cadence. This avoids the common mistake of letting one label cover two governance models that have different blast radii.

That model should also drive policy design. Delegated actions usually need human approval gates, constrained scopes, and clear attribution back to the person who initiated the work. Autonomous actions need stronger authorization controls, tighter defaults, and narrower runtime privileges, because the agent can progress without a live human checkpoint. A practical reference point is the AI Agent Authorisation Guide, which focuses on least privilege, task-scoped access, and per-action decisions.

For teams that need to distinguish agent types at scale, the broader spectrum view in AI Agents vs Agentic AI helps separate simple assisted workflows from systems that make independent choices. That distinction is useful because the more autonomy the agent has, the less defensible it is to treat every request as if a human were still in the loop.

Practitioner Guidance

What to verify: Make sure your policy engine can tell whether the agent is acting on a user’s behalf or under its own principal at the moment of execution. If that evidence is missing, you do not yet have a reliable classification model.

Decision rule: If the agent can complete the action without a live human approval step and uses credentials that are not the user’s, classify it as autonomous for control purposes. If the user is still the accountable principal and the agent is just executing instructions, classify it as delegated.

What good looks like: Each meaningful agent action is attributable to either a human-approved delegation chain or a distinct non-human identity, with no ambiguous middle state that bypasses review.

Common mistake: Teams often assign one permanent label to an agent and then let mode switching happen informally. That usually creates overbroad access in autonomous mode and weak attribution in delegated mode.

Practitioner takeaway: The safest operating model is to classify the action, not the bot, and to force the control decision to change whenever the agent’s authority changes.

Related resources from NHI Mgmt Group

• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• What is the difference between workload identity and API keys for AI agents?
• How should security teams manage permissions for AI agents?