Human in the loop: autonomy levels for agents in production

The debate about AI agents in operations is often framed as a binary choice: either the agent acts on its own, or a human reviews everything. Both positions fail. Full autonomy without prior evidence is a risk no operations leader in a regulated industry should accept. Human review of every step, on the other hand, turns the agent into one more source of alerts and removes much of its value.

The alternative is to treat autonomy as a graduated scale and assign it per use case, not per agent. The same agent can act on its own to restart a test service and stick to recommending when a production database is involved. This article proposes a concrete scale, the criteria for moving along it and the controls each level requires.

A four-level scale

We propose four levels. The names matter less than making sure each one clearly defines who decides and who executes.

1. Observe. The agent reads data, correlates and summarizes. It does not suggest actions or touch systems. Example: a summary of an incident's status with the relevant signals.
2. Recommend. The agent proposes a specific action, with the evidence and reasoning behind it. A person decides and carries it out.
3. Act with approval. The agent prepares the action ready to run and executes it only when an authorized person explicitly approves it. The approval is recorded.
4. Act within guardrails and report. The agent executes without prior approval, but only within limits defined in advance (type of action, systems, time window, quantity), and reports what it did. Outside those limits it falls back to level 3.

Level 4 is not "full autonomy". It is bounded autonomy, with an explicit perimeter and after-the-fact review. In regulated operations we recommend not defining any level above it.

For the broader context on what these agents do, see our article on AI agents in IT operations.

Criteria for moving a use case up a level

Every use case starts at level 1 or 2. Moving it up is a decision made on evidence, not enthusiasm. We recommend assessing four criteria:

Accuracy track record

Before letting the agent execute, you need to know how often it gets things right. At level 2 this is measured directly: how many recommendations people accepted unchanged, how many they corrected and how many they rejected. The exact threshold depends on the case, but it should be set before you start measuring, not after you see the results. Volume matters too: a handful of correct recommendations is not a track record.

Blast radius

What is the worst that can happen if the agent gets it wrong? An error that hits a development container is not comparable to one that hits the payments platform. Express it in concrete terms: how many services, how many users, which business processes.

Reversibility

An action that can be undone in seconds with no data loss allows more autonomy than one that cannot be reversed. Restarting a process is reversible; deleting data, rotating a shared key or modifying a purchase commitment are not, at least not in the short term.

Regulatory impact

If the action affects personal data, security controls, records used in audits or the relationship with customers, the maximum level is also set by Compliance, not just Operations. In these cases, even with a good technical track record, human approval may need to stay in place.

The rule of thumb: a use case moves up only when all four criteria allow it. And it moves down automatically after a significant error, until the cause has been analyzed.

Example tasks and recommended level

The table below is a starting point for a regulated organization. Each organization should adjust it to its architecture, risk appetite and obligations.

Task	Recommended level	Main reason
Summarize an incident and correlate signals	1. Observe	Changes nothing; the value is in the synthesis
Propose the probable cause and resolver team	2. Recommend	Needs human judgment until a track record builds up
Propose resizing in production	2. Recommend or 3. Act with approval	Reversible, but affects availability and cost
Update technical attributes in the CMDB	3. Act with approval, then 4 for low-risk attributes	Visible and reversible; others depend on that data
Restart a non-critical service following an approved runbook	4. Act within guardrails	Reversible, limited impact, known procedure
Scale capacity within a predefined range	4. Act within guardrails	Explicit limits on quantity and cost
Isolate a device after a security alert	3. Act with approval	High business impact if it is a false positive
Modify firewall rules or access permissions	2. Recommend	Security control with regulatory impact
Delete data or resources holding data	2. Recommend	Not reversible

For concrete applications of this scale, see incident triage with agents, continuous rightsizing and living documentation.

Permissions and least privilege

The autonomy level is declared in a policy, but it is enforced through permissions. If the agent holds administrator credentials, level 2 is just an intention. We recommend:

• One identity per agent and per use case, never credentials shared with people or other systems.
• Read-only permissions by default. Write permissions are granted per specific action and per scope (a namespace, a resource group), not broadly.
• Short-lived credentials, issued per execution where the platform allows it, instead of permanent keys.
• Execution through existing channels. The agent acts through the same pipelines, automation tools or APIs people use, so the same controls apply.
• Separation between proposer and approver. The agent can never approve its own level 3 actions.

Kill switch and audit trail

Two controls must be in place before moving any use case to level 3 or 4.

The kill switch lets you stop the agent, or drop all its use cases to level 2, with a single action that does not depend on the agent itself. It should be documented in the operations center's procedures, have named owners and be tested periodically, like any other continuity control. A kill switch nobody has tested is not a control.

The audit trail must make it possible to reconstruct, for every action, what data the agent saw, what it concluded, what it proposed, who approved it and what it executed. We recommend that the trail:

• Is stored outside the agent's write scope.
• Includes the version of the model, the instructions and the tools used for each decision.
• Is linked to the corresponding change or incident ticket.
• Is retained according to the retention policy that applies to the organization's operational records.

This trail serves audits, but it also drives improvement: it is the basis for measuring the accuracy that justifies moving a use case up or down.

Governance reference frameworks

There is no need to invent AI governance from scratch. Two public references help structure it:

• ISO/IEC 42001 sets out the requirements for an artificial intelligence management system. It is useful for organizations that already run certifiable management systems such as ISO/IEC 27001, because it follows a similar structure of policies, roles, risk assessment and continual improvement.
• The NIST AI Risk Management Framework (AI RMF) organizes AI risk management into four functions: Govern, Map, Measure and Manage. It is voluntary and not certifiable, but it offers a practical vocabulary for discussing risk with Risk and Compliance teams.

The scale in this article fits both: it is a concrete way to document which human controls apply to each use of AI and how they are reviewed. Before setting maximum levels for use cases with regulatory impact, validate them with your organization's Compliance and Risk functions.