Levels of Agent Autonomy by Approval Requirements

Hello. In the previous lesson, you separated the components that make an agentic system work: prompts guide the model, tools provide controlled capabilities, retrieval supplies current knowledge, memory preserves selected state, and orchestration decides what actually executes.

That last component is central here. An agent may be able to propose many actions, but its autonomy level depends on which of those actions orchestration permits it to take without returning to a person for direction, consultation, or approval. You will learn to classify an agent by the user’s operational role and, more concretely, by the approval boundary around its actions.

---

Autonomy is authority, not capability

A highly capable model is not automatically highly autonomous. A strong agent can be deliberately configured to pause for a person before every consequential action. Conversely, a relatively simple agent can run independently in a narrow, repetitive workflow.

So distinguish two questions:

1. Capability: What could the model potentially reason about or propose?
2. Autonomy: What decisions and tool actions may the deployed system actually take without human involvement?

For security purposes, autonomy is mostly a question of delegated authority. Consider a security-operations agent that can:

• read authentication logs;
• retrieve an incident runbook;
• create a case in a ticketing system;
• send a notification to an employee;
• disable an account;
• update a firewall rule.

These do not all carry the same consequence. Yet each is an action in the relevant sense: it accesses data, changes a system, communicates externally, or triggers a process. Autonomy classification must therefore consider tool calls and delegated workflows, not merely whether the agent produces text.

A useful rule is:

Classify an agent by its actual permission to decide and execute, not by its marketing label, model size, or apparent intelligence.

The five-level framework used in this course is user-centered: as autonomy increases, the user’s role shifts from directing the work toward observing it.

---

The five levels: what may happen without approval?

The levels below describe a progression in how much independent work an agent may perform. They are best understood as a set of interaction patterns, rather than a promise that every action at a given level is safe.

Level	User role	What the agent may do independently	When human involvement occurs
L1	Operator	Provides assistance, suggestions, or explicitly requested subtasks	The user directs the workflow and invokes or approves actions
L2	Collaborator	Performs delegated work while the user works in parallel	Frequent coordination; the user can modify work or take over
L3	Consultant	Leads planning and execution across much of the task	The agent actively consults the user for expertise, preferences, and direction
L4	Approver	Handles routine planning and execution on its own	The agent asks only for blockers, pre-specified conditions, or consequential actions
L5	Observer	Plans, adapts, and acts independently throughout the task	The user monitors; intervention is limited to an emergency stop or equivalent control

The essential question is not, “Does a human ever see the agent?” It is:

At which decisions and actions must the agent stop and obtain meaningful human input before continuing?

Logs, dashboards, and after-the-fact reviews are valuable, but they do not make an otherwise autonomous agent “human in the loop.” A person who learns about an action only after it has executed was an observer for that action.

L1: User as operator

At Level 1, the person owns the plan and remains responsible for deciding what happens next. The agent behaves like an on-demand assistant: it can summarize a log, draft a response, suggest a search query, or generate a command for the user to review.

For example, an analyst might ask:

“Summarize the suspicious sign-in events in this case.”

The agent can inspect the material the analyst provides and return a summary. If it proposes searching an additional data source or creating a ticket, the analyst must explicitly direct or approve that step.

An L1 security agent should not silently decide that an unfamiliar IP address is suspicious, search unrelated employee records, or contact a user. It can assist with the analyst’s judgment, but does not replace it.

Security implication: L1 is appropriate when expertise, accountability, or consequence makes independent judgment undesirable. The main controls are clear invocation, narrow tool access, visible proposed actions, and audit logs.

L2: User as collaborator

At Level 2, the user and agent jointly plan, divide work, and work in parallel. The agent may independently complete delegated tasks, but the relationship is still hands-on and highly interactive.

Suppose an incident responder and an agent agree on a division of labor:

• The responder assesses business impact and decides whether to escalate.
• The agent gathers authentication records, summarizes recent changes, and drafts a timeline.
• Both contribute findings to a shared case record.

The agent need not ask for approval before each delegated read-only lookup. However, the responder can see progress, revise the plan, edit the agent’s output, or take control if the investigation heads in an unhelpful direction.

The distinguishing feature is shared control, not merely a plan that someone approved at the beginning. If the human can actively reallocate tasks and directly alter the agent’s work throughout the process, L2 is a good description.

Security implication: L2 needs transparent progress, reliable handoff or takeover mechanisms, and a shared representation of task state. An agent that is running independently but provides only occasional status updates is probably not L2.

L3: User as consultant

At Level 3, the agent takes the lead. It develops and executes a plan over a longer period, while the user supplies judgment the agent cannot safely infer: priorities, domain expertise, preferences, or a choice between acceptable tradeoffs.

Imagine an investigation agent that receives the goal:

“Determine whether this account anomaly warrants escalation and prepare a case summary.”

It independently collects authorized evidence, retrieves the relevant runbook, and drafts a timeline. It then asks the incident lead:

“The login was from a previously unseen location but occurred during approved travel. Should I treat approved travel as a mitigating factor for this case?”

That is consultation, not a narrow approval request. The agent has taken responsibility for progressing the work, but it recognizes that a contextual judgment belongs to the human.

At L3, the user may usually pause the agent or request changes, but may not have the same direct, continuous ability to take over and edit every intermediate step that characterizes L2.

Security implication: consultation must be timely and intelligible. If an agent asks vague questions after it has already made a consequential decision, the consultation is not a meaningful control.

L4: User as approver

At Level 4, the agent carries out most of the workflow independently. The user is not expected to collaborate continuously or provide routine preferences. Instead, the agent contacts the person when it faces:

• a missing credential or other genuine blocker;
• a condition the organization pre-defined as requiring review;
• a high-impact or irreversible action;
• a decision that exceeds its authorized scope.

For example, a security agent might automatically collect evidence, correlate alerts, enrich low-risk cases, and create routine internal tickets. It may be required to seek approval before it disables an account, sends an external notification, exports sensitive data, or changes a production security control.

The agent may display its plan for transparency, but it does not wait for feedback on every ordinary step. The approval is focused on specified consequential decisions.

This is an important distinction:

• L3: “Which of these priorities best reflects your intent?”
• L4: “I am ready to disable this account. Approve or reject?”

In the first case, the user provides expertise that shapes the work. In the second, the agent has already progressed independently and needs authorization for a defined boundary.

Security implication: L4 requires robust technical enforcement around those boundaries. A prompt saying “ask before disabling accounts” is insufficient. The account-management tool, authorization layer, and orchestrator must prevent execution until an authenticated authorized approver has acted.

L5: User as observer

At Level 5, the agent plans, executes, adapts to obstacles, and continues pursuing its task without user participation. People can monitor activity and inspect logs, but cannot direct the live workflow. An emergency stop is the principal means of intervention.

An L5 agent investigating infrastructure might choose which sources to inspect, change its strategy when a source is unavailable, produce reports, and continue its work without consultation or approval.

L5 does not mean “an agent with a dashboard.” It means no ordinary human steering mechanism exists during operation.

This level is especially difficult to justify where actions affect people, money, production systems, sensitive data, or safety. Small errors can compound across many tool calls, and an attacker who influences one step may affect later decisions.

Security implication: monitoring, detailed audit logs, strong scope limitations, recovery procedures, and a dependable emergency stop become indispensable. In most enterprise deployments, fully autonomous operation should be confined to tightly bounded, low-consequence, or isolated environments.

---

Approval models and naming traps

Autonomy frameworks do not all use the same numbers. Some begin with Level 0 for an information-only system that cannot act at all; others, including the framework in the image, begin with L1 for a user-operated assistant.

Do not compare level numbers without first checking the definition.

A more portable way to record autonomy is to state the actual approval model:

Approval model	Meaning
Information only	The system advises; a human performs all real-world actions
Per-action approval	The agent proposes each action, and a human approves before execution
Per-plan approval	A human approves a defined plan or batch; the agent executes within that approved scope
Pre-authorized bounded operation	The agent acts independently within machine-enforced limits and escalates outside them
Broad monitored operation	The agent acts across a broad scope; humans mainly monitor and handle exceptions
Full self-directed operation	The agent pursues its mandate with little or no operational human involvement

This description is more useful in a security review than a bare label such as “Level 3.” It reveals precisely where authority lies.

A plan approval can be a legitimate control, but it is not the same as reviewing each step. If a plan says “process 10,000 access requests,” the approver must understand the target population, action types, authority, exceptions, resource limits, and recovery path. Otherwise, “plan approval” can become a weak rubber stamp.

---

A practical method for classifying a proposed agent

When reviewing an agent design, avoid starting with the intended label. First inspect its actions and control points.

1. Inventory every action

List every tool call and workflow the agent can initiate, including apparently harmless ones:

• reading records or documents;
• searching across a tenant or data store;
• exporting or sharing results;
• creating, modifying, or deleting records;
• sending messages;
• executing code;
• changing access, infrastructure, or security settings;
• calling another agent or adding a new tool.

A “read-only” action can still be consequential if it exposes sensitive data to the wrong user or retrieves untrusted content into the agent’s context.

2. Identify the authorization unit

Ask what exactly a person must approve, if anything:

• each individual action;
• a task plan;
• a category of actions under stated conditions;
• only exceptions and high-impact actions;
• nothing during execution.

Also ask whether approval is prospective. A human who approves an already completed action has not governed that action.

3. Determine the human’s working role

Look at the normal workflow rather than an idealized exception case:

• Does the person decide the next task? This points toward L1.
• Do person and agent jointly divide and revise work? This points toward L2.
• Does the agent lead but request the person’s knowledge and preferences? This points toward L3.
• Does the agent operate until it hits a blocker or consequential threshold? This points toward L4.
• Is the person limited to monitoring and emergency intervention? This points toward L5.

4. Test the boundary with adverse cases

A design may claim that “high-risk actions require approval,” but that claim needs a testable definition. Consider cases such as:

• The agent is asked to export a report containing sensitive fields.
• A tool returns an instruction telling the agent to change its own permissions.
• A low-impact action is repeated thousands of times.
• A routine workflow affects a privileged employee account.
• An action is technically reversible but causes irreversible disclosure or reputational harm.

If the system cannot recognize and enforce its own escalation conditions, it has more autonomy in practice than its designers intended.

5. Classify each capability, then the workflow

A single enterprise agent can have different autonomy profiles for different tools:

Capability	Example classification
Log summarization	L1 when the analyst invokes it on demand
Evidence collection	L2 or L3 if delegated within a shared investigation
Routine ticket creation	L4 if the agent can create low-risk tickets independently
Account disablement	L4 only if the system must obtain explicit approval first
Unrestricted remediation	Potentially L5 if the agent decides and executes without operational intervention

The workflow’s overall risk is often governed by its most autonomous consequential capability, not by its least risky feature. An agent that is carefully supervised while summarizing text but can independently change access controls should not be described simply as “a supervised assistant.”

---

Autonomy should be designed downward from risk

Increasing autonomy is not automatically progress. It can improve speed and reduce routine workload, but it also expands the range of failures, abuse cases, and accountability gaps that must be controlled.

A sensible design process starts with the lowest autonomy that achieves the business purpose:

• Keep an agent at L1 where human expertise and accountability are integral.
• Use L2 when collaboration and rapid human takeover add value.
• Use L3 when an agent can lead a workflow but needs recurring expert judgment.
• Use L4 only when routine decisions are well understood and consequential boundaries can be enforced outside the model.
• Treat L5 as exceptional, particularly outside a sandbox or tightly constrained domain.

The control plane must remain distinct from the model’s probabilistic reasoning. The model may recommend that an action is routine, but deterministic application logic should decide whether it is within policy, whether the target is authorized, whether approval is required, and whether execution is permitted.

---

Key takeaways

Agent autonomy is the degree to which an agent can plan, decide, and use tools without human involvement. It is a design choice about authority, not a measure of the model’s intelligence.

Using the course’s five-level framework:

• L1: the user operates and directs the work.
• L2: user and agent collaborate with shared control.
• L3: the agent leads but consults the user for expertise and preferences.
• L4: the agent operates independently and requests approval only for blockers or consequential actions.
• L5: the user observes a self-directed agent and may only halt it.

For security reviews, always state the concrete approval model, the authorized action scope, escalation conditions, and technical enforcement mechanisms. A human-visible dashboard or a written instruction does not, by itself, reduce autonomy.

Next, you will distinguish model errors, safety failures, privacy failures, and security attacks—a distinction needed to understand what can go wrong at every autonomy level.