AI Agent Autonomy Levels Framework: Matching Controls to How Much an Agent Decides

Most organisations approve AI agents as if they were one kind of thing, when the real risk depends on how much the agent decides and does without a person. A drafting assistant that suggests replies and an agent that wakes up on a cloud alert and changes firewall rules can run on the same model, yet they need very different identities, permissions, approval gates and monitoring. An autonomy level gives security, risk and engineering teams a shared label for that difference, so controls scale with it instead of being argued case by case. This guide compares the published autonomy schemes, sets out a working scheme NHI Mgmt Group uses for control mapping, and shows which controls belong at each level, how to assign and test a level, and how to move an agent up or down safely. It is written for security architects, IAM and NHI teams, AI platform owners and risk functions who sign off agent deployments.

Key takeaways

• Autonomy is a design choice, not a model property. The same capable model can be deployed to suggest only or to act alone; the level is set by approvals, triggers and permissions around it.
• Separate autonomy from agency. Agency is what the agent can touch (tools, scopes, systems); autonomy is how much it decides without a person. Both must be bounded, and a low autonomy level does not excuse broad permissions.
• Controls should step up with the level. Read-only agents need least privilege and logging; agents acting without per-action approval need budgets, behavioural baselines, a tested kill switch and their own identity.
• Assign the level to a deployment, not a product. Record it per agent, per environment and per action class in the inventory, and re-assess when tools, prompts, model or data access change.
• Move up on evidence and down automatically. Promotion should follow a measured period at the lower level; demotion to an approval-gated level should be automatic when anomalies or security events occur.

Why autonomy levels, and what they are not

An autonomy level answers one question: for a given class of action, who decides and who acts, the agent or a person? It is useful because most agent controls are only proportionate once that is known. EU AI Act Article 14(3) makes the same point for high-risk systems, requiring human oversight measures commensurate with the risks, the level of autonomy and the context of use.

• Not capability: Feng, McDonald and Zhang treat autonomy as separate from capability (how well an agent performs on tasks). A highly capable agent can still be designed to seek approval for every action.
• Not agency: the AWS Agentic AI Security Scoping Matrix defines agency as the scope of actions the system can take and autonomy as how much it decides and acts without human intervention. Feng and colleagues similarly note that tools mainly change agency, while approval-seeking behaviour mainly changes autonomy.
• Not one number per agent: an agent can act alone on reads, draft writes for approval, and be blocked entirely from payments. Record the level per action class.
• Not a risk score: a low-autonomy agent with a production database credential can still cause severe harm if its approval gate is a rubber stamp. Autonomy is one input to risk, alongside data sensitivity, reversibility and blast radius.

For the terminology itself, see AI Agents vs Agentic AI and the Agentic AI Glossary.

Published autonomy schemes compared

There is no single standard scale for AI agent autonomy. The schemes below are the ones read for this guide; each is attributed to its authors. Driving-automation scales are often cited by analogy, but they describe vehicles, not software agents, and are not used here.

Feng, McDonald and Zhang: the user's role

• L1 Operator: the user stays in charge of the workflow; the agent may suggest actions but does not execute them without approval.
• L2 Collaborator: user and agent plan and execute together, and the user can take over at any time. The authors place OpenAI's Operator here.
• L3 Consultant: the agent leads planning and execution over longer periods and consults the user for feedback; the user can pause it or request changes but does not directly control it.
• L4 Approver: the agent works independently and involves the user only at blockers, such as a failure, a missing credential or a consequential action that needs sign-off. The user can specify in advance which actions require approval.
• L5 Observer: the agent plans and decides over long horizons; the user can monitor logs and use an emergency off-switch. The authors suggest L5 may be justified mainly in closed or sandboxed environments.

The paper also proposes "AI autonomy certificates": a third-party body would set the maximum level an agent may operate at, based on its technical specification (model, prompts, tools) and operating environment, with renewal when either changes. No such scheme is in operation that we are aware of, but the idea of a maximum level that is renewed on change translates directly into internal governance.

AWS Scoping Matrix: agency and autonomy together

The AWS matrix combines both axes. At Scope 2 a human starts the agent and approves each consequential action, and autonomous actions are limited to read-only tasks. At Scope 3 a human sets the objective and the agent acts across connected systems without approval. At Scope 4 the agent initiates its own activity from environmental triggers and runs continuously. It recommends starting deployments at Scope 1 or 2 and reducing autonomy gracefully when security events occur.

A working scheme for control mapping (NHI Mgmt Group)

The scheme below is NHI Mgmt Group's own working scheme, not a published standard. It is deliberately security-centred: each level is defined by who triggers the agent and what happens between the agent's decision and the effect on a system, because that is where controls attach. The mapping columns are our reading of how the published schemes line up, not the authors' own mapping.

Two rules make the scheme usable. First, levels apply per action class: a deployment record might read "A3 for ticket updates, A1 for user account changes, prohibited for payments". Second, an action that is irreversible, moves money, changes privileges or sends data outside the organisation defaults to A1 unless a named risk owner signs off a higher level. For how approval gates themselves should be designed, see the Human-in-the-Loop for AI Agents Guide.

Controls by level

Controls are cumulative: each level keeps those below it. Control names follow NIST SP 800-53 Rev. 5 where one fits. The scope-specific items reflect the AWS matrix recommendations, which list, for example, multi-factor authentication for approvers and time-limited approval tokens at Scope 2, and automated kill switches and behavioural baselines at Scope 3.

• Complete mediation: at every level, authorisation must be enforced in the downstream system or a policy enforcement point, not by the model deciding whether an action is allowed. OWASP LLM06:2025 Excessive Agency lists this as a mitigation alongside requiring user approval for high-impact actions. See the AI Agent Authorisation Guide.
• Interruptibility: OpenAI's governance paper stresses that a graceful shutdown should always be available and that sub-agents an agent spawns must also be terminable. See the AI Agent Kill Switch and Containment Guide.
• Spend and action limits: from A2 upwards, budgets carry more of the safety load than approvals do. See the AI Agent Action Approvals and Spending Limits Guide.

Where identity fits

Autonomy level changes which identity an agent should act under. At A0 and A1 the agent can usually act in the user's context, because a person sees and approves each effect; OWASP LLM06 recommends executing extensions in the user's context with minimum privileges. From A2 upwards the agent takes actions no person reviewed at the time, so it needs its own identity that records the delegating user, a named owner and a purpose, otherwise actions cannot be attributed. OpenAI's governance paper makes the same argument for attributability: an agent identifier linked to a responsible human.

• A2 and above: register the agent as a non-human identity with owner, purpose, autonomy level and environment, and issue short-lived credentials. See the Agentic AI Identity Maturity Model.
• A4: self-initiating agents are effectively scheduled service accounts with reasoning. Trigger sources (queues, webhooks, alert feeds) become part of the attack surface, because whoever can write to them can start the agent.
• Commerce: agents that buy on a user's behalf need delegated payment credentials with their own limits. See the Agentic Commerce Identity Guide.

Assigning a level: decision guidance

Choose the lowest level that still delivers the business value, then justify each step up. These questions decide where an action class sits.

• Small organisations: keep most agents at A0 to A2, use the approval and permission features built into agent platforms, and rely on platform spend limits. Avoid A4 unless the agent runs only in a sandbox.
• Large organisations: make the autonomy level a mandatory field in the agent registry and the architecture review, tie each level to a control baseline, and have an AI risk committee approve anything at A3 or A4 in production.
• Security operations: autonomous triage and response is a common early A3 and A4 use case. See the AI SOC Guide for SOC-specific patterns rather than repeating them here.

How to implement autonomy levels

1. Inventory: list every agent in use, including those embedded in SaaS products and developer tools, with its tools, credentials, triggers and data access.
2. Classify actions: for each agent, group its tools into action classes (read, reversible write, irreversible or destructive, financial, privilege change, external communication).
3. Assign levels: set the level per action class using the decision table, record a named risk owner, and note the maximum level the deployment is approved for, an internal version of the autonomy certificate idea.
4. Apply the baseline: implement the control set for each level. Enforce gates and prohibitions outside the model, in the tool layer, API gateway or downstream authorisation.
5. Pilot one level down: run a new agent first at one level below its target (for example A2 before A3) and in a non-production environment, capturing what it would have done.
6. Test: run prompt-injection and misuse tests against each gate and limit; confirm the kill switch stops the agent and any sub-agents within the target time. See the AI Agent Threat Modelling Guide.
7. Promote on evidence: move up only after a defined period with acceptable error and override rates, and record the decision with the evidence.
8. Roll back: define demotion triggers (anomaly alert, failed control test, security incident, model or tool change) that drop the agent to A1 automatically, and re-assess before restoring.

Detection and measurement

Log enough to reconstruct who decided what: the agent identity, delegating user, autonomy level in force, the action class, parameters, whether an approval was required and who gave it. See the AI Agent Observability and Incident Response Guide.

• Level coverage: percentage of production agents with a recorded autonomy level and risk owner (target 100%).
• Level drift: number of agents observed performing actions above their approved level (for example an ungated write by an A1 agent). Any non-zero value is a finding.
• Override and reversal rate: share of agent actions a human later reversed or corrected, per level. Rising rates argue for demotion.
• Approval quality: approval rate, median time-to-approve and denials per approver. Near-100% approvals in a few seconds suggest rubber-stamping.
• Kill switch time: measured time from decision to full stop in the last test, including sub-agents.
• Re-assessment lag: days between a model, prompt or tool change and the autonomy re-assessment.

Framework mapping

Common failure patterns

• Instructions instead of controls: telling an agent in its prompt not to change production is not an A1 gate. In the Replit AI agent database deletion the agent ran destructive database commands during a declared code freeze despite repeated instructions; Replit's response included separating development and production databases and a planning-only mode, both controls outside the model.
• One level per agent: labelling a whole agent "supervised" hides the one tool that can delete data or move money at the same autonomy as harmless reads.
• Rubber-stamp approvals: an A1 agent whose approvals are clicked through in seconds is effectively A3 without A3 controls. OpenAI's governance paper warns that frequent or context-poor approvals invite this.
• Silent promotion: users grant "always allow" or persistent permissions for convenience, moving the agent up a level with no review. Anthropic notes Claude Code lets users grant persistent permissions for routine tasks; those grants need the same governance as a level change.
• Autonomy without identity: A3 and A4 agents running under a shared service account or a human's token, so actions cannot be attributed or revoked separately.
• Untested off switch: a kill switch that stops the main process but not scheduled triggers or spawned sub-agents.

Practitioner checklist

• Adopt one autonomy scheme internally, state its source, and label any in-house scheme as your own.
• Record the autonomy level per agent and per action class in the agent inventory, with a named risk owner.
• Default irreversible, financial, privilege-changing and external-communication actions to approval-gated.
• Enforce gates, prohibitions and limits outside the model, at the tool layer or downstream authorisation.
• Give every agent at A2 or above its own identity, owner and short-lived credentials.
• Attach a control baseline to each level and check it at architecture review.
• Pilot new agents one level below target and promote only on recorded evidence.
• Define automatic demotion triggers and test them alongside the kill switch, including sub-agents.
• Re-assess the level whenever the model, prompts, tools, data access or environment change.
• Track level drift, override rate, approval quality and kill switch time monthly.

Standards and references

• EU AI Act: Article 14, Human Oversight
• OWASP: Top 10 for LLM Applications 2025 (LLM06 Excessive Agency)
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• arXiv (Feng, McDonald, Zhang): Levels of Autonomy for AI Agents
• AWS Security Blog: The Agentic AI Security Scoping Matrix
• OpenAI: Practices for Governing Agentic AI Systems
• Anthropic: Our Framework for Developing Safe and Trustworthy Agents

Related NHI Mgmt Group resources: Human-in-the-Loop for AI Agents Guide · AI Agent Kill Switch and Containment Guide · AI Agent Authorisation Guide · Agentic Commerce Identity Guide · AI SOC Guide