AI agent governance, in practice, is deciding which actions an agent may take without a person, what evidence moves an action to more or less oversight, and who approves that move. Set the autonomy level on each action rather than on the agent. A read, a customer message, a refund and an infrastructure change carry different consequences. A single setting for the whole agent either holds the low-risk actions back or lets the dangerous ones through unreviewed.
Key facts
Definition
AI agent governance sets an autonomy level on each action, from read through act inside limits, and names the evidence and the owner for every move between levels.
How Bigcircle does it
- Bigcircle sets the level per action: Skionis reads an AWS account without approval and applies a change only after an engineer approves a diagram.
- Bigcircle keeps a person approving the consequential actions of every agent it has put into production, and recommends agreeing in writing, before release, the evidence that would remove each approval.
- On the telecom engagement Bigcircle is working on, every agent action in the current phase is proposed and approved by a person while the baseline metrics are established.
Comparison
Feng, McDonald and Zhang define five levels by the user's role across a whole agent, and a per-action level lets a read run freely in the same agent where a refund keeps its approver.
Key number
On Solarpunk, plans completed with no human intervention rose from roughly 55% to 80% while the agent's authority stayed the same, by Bigcircle's own measurement.
Governance across an organisation covers which agents exist, who owns them, what they can reach and what gets logged. This guide covers the decision underneath that, for one agent at a time. Bigcircle keeps a person approving the consequential actions on the agents it has put into production, and part of this guide explains why. The rest covers where the common autonomy levels come from, the evidence that should move one action up, and who signs off on that move. It ends with what moves an action back down and where the main frameworks fit.
| Criterion | Read | Recommend | Prepare | Act after approval | Act inside limits |
|---|---|---|---|---|---|
| What the agent may do | Read, and change nothing | Propose one action with the evidence behind it | Build the exact pending change | Run one change a person approved | Run without approval case by case, inside written limits |
| What the person does | Acts on what the agent found | Decides, then acts | Reviews the change and submits it | Approves that one change | Watches, and can stop the action |
| Evidence before it moves up | Right tenant, fresh sources, and a missing source shown as missing | Correction rates for this action, with a known cause for each kind of correction | The change that runs is the change that was reviewed | A check in code for each thing the approver was catching, and the result confirmed in the target system | It does not move up. A trigger moves it back down |
| How Bigcircle handles this | Skionis reads live quotas, limits and existing resources before it plans, with no approval | Our campaign analytics agent returns the query, tables and filters behind each answer | Our campaign configurator proposes a configuration a person can diff, and nothing deploys without sign-off | Skionis applies a change only after an engineer approves a diagram of what will exist | Solarpunk runs a routine end to end through the systems registered for it and hands back the one step it could not resolve |
Where do AI agent autonomy levels come from?
The common scales grade the agent, and we grade the action. The scale cited most often, from Feng, McDonald and Zhang in June 2025, defines five levels by the role the user plays across a whole agent: operator, collaborator, consultant, approver and observer. We share its premise that autonomy is a design decision separate from capability, so the same model can ship with a person approving every step or with a person only watching. We part from it on the unit.
We set five levels too, but on one action class at a time, and they are the columns in the table above. Read and recommend leave the user as operator or collaborator for that action. Prepare and act after approval make them the approver, and act inside limits makes them the observer. The question then stops being how autonomous the agent should be, and becomes which action is ready to move and on what evidence.
Why set the level on an action rather than on the agent?
On Skionis, the DevOps agent we shipped on a live AWS account, three kinds of action sit at three levels inside one agent. It reads live limits, quotas, regions and existing resources before it plans, with no approval, because a read changes nothing and a plan made without it fails at apply. It revises a failing template on its own inside a validation loop, and a template that will not come clean after a bounded number of revisions is escalated rather than retried forever. The apply waits for an engineer to approve a diagram of what will exist after the change.
A single setting for that agent would have had to match one of the three. Matching the apply would mean asking permission to read an account, and matching the read would mean applying infrastructure nobody reviewed. Setting the level per action also keeps a failure traceable. The agent's capability changes whenever the model, a tool, the prompt or a data source changes, and authority should change only when someone decides it should. If one action moved and errors rose afterwards, the team knows which decision to revisit. A move that changes one property while holding the rest fixed keeps it that way, whether the property is the target range, the volume, the tenant or how long the credential lives.
Why do our production agents keep a person approving?
Every agent we have put into production still has a person approving its consequential actions or reviewing the finished result. On Skionis the approval is a picture because the alternative is raw template diffs, which engineers do not read carefully at the tenth change of the week. The diagram stays human by design, since "is this the change we meant" is not a question a validator can answer. Engineers went from refusing to let an agent near production to letting it own routine cloud changes, and the review step earned that, not the model.
The approval stayed for two reasons. It was fast to clear, and removing it would need a count of what the diagram review catches that the validator misses. Without that count there is no case for taking the engineer out. Before asking for more autonomy on any action, ask what its current approver catches. If nobody can answer, the request comes too early, because the evidence it needs has not been collected.
A campaign-orchestration engagement for a telecom marketing platform shows the same order from the start. Its current phase has every agent action proposed and approved by a person. The phase measures the baseline: how long a configuration takes, how fast an analytics question is answered, and how often a person corrects the agent. The proposal for later phases widens autonomy per action type only as the audit history supports it. The plan starts by measuring the approver.
What raised autonomy where an agent did run unattended?
Solarpunk, the executive operations agent, runs a routine end to end through the systems registered for it. It hands the leader finished work, or the one step it could not resolve with its trace attached. Plans completed with no human intervention rose from roughly 55% to 80% once local retrieval and planner memory grounded the agent in the user's own workspace. That is our internal measurement from before and after those two changes.
Its authority did not change between the two numbers. Before and after, it could act only through explicitly registered systems, and it could not invent access it had not been given. What changed was its context, so fewer runs stopped for a person. If what you want from more autonomy is fewer interruptions, this system suggests looking at what the agent knows about the user's workspace before looking at what it is allowed to do.
Skionis shows the same thing from the other side. Template errors before deploy fell from around 10% to 4% across the introduction of the validation loop, by our internal measurement. The engineer still approves every apply, but sees fewer bad templates, because the loop catches them first. Both changes reduced what a person had to handle, and the approval itself stayed where it was.
Do not read the coding-assistant numbers as a case for whole-agent autonomy. Anthropic's February 2026 study of Claude Code has users with fewer than 50 sessions turning on full auto-approve in roughly 20% of sessions, passing 40% by 750 sessions, while interruptions rise from 5% of turns to around 9%. Those users stopped approving each step and interrupted more often instead, which works when a developer is watching the session. Nobody watches a refund that runs overnight, which is why we keep the level on the action.
What evidence should move one action up a level?
Agree the evidence before the release, in writing, with the person who owns the operation. Evidence chosen after the release tends to be chosen to fit the result. Each move needs its own evidence, and the table lists the evidence each one needs.
| Move | Evidence that must exist first | What goes wrong without it |
|---|---|---|
| Read to recommend | Reads return only what this user and tenant may see, sources are current, and a missing source shows as missing | A recommendation built on another tenant's record or a stale one is wrong in a way the reviewer cannot see |
| Recommend to prepare | Acceptance and correction rates for this action alone, over a window agreed in advance, with a named cause for each kind of correction | A high overall acceptance rate hides repeated errors in one segment |
| Prepare to act after approval | The prepared change is versioned, and any change to target, parameters or evidence after review cancels the approval | A reviewer approves one change and the system runs another |
| Act after approval to act inside limits | A check in code for each thing approvers were catching, the result confirmed by reading the target system rather than trusting the tool's reply, a tested way to undo it, and a named person who can stop it | Removing the approver removes every catch the code does not repeat |
An approval rate near 100% is not, on its own, evidence that the approver can go. It can mean the proposals are right. It can also mean the approver has stopped reading, and the Skionis approval was designed around that risk. Test the reviewer before you rely on the rate: put a few known-bad proposals into the queue and count how many come back rejected. If they come back approved, the rate was measuring the reviewer's habits rather than the agent.
Take a person out only of a decision that a check now makes. If the team cannot write down what the approver catches, it cannot write the check, and the action stays where it is. Some actions should never reach the last column. A payment, a deletion or anything that cannot be reversed can stay at act after approval indefinitely, and that is a correct end state rather than a stalled rollout. Our guide on human in the loop AI agents covers how to design that approval so it stays meaningful, and the one on AI agent verification covers confirming the result in the target system.
Who approves a change in an agent's autonomy?
Name one person who owns the operation the action belongs to. For refunds that might be the head of support, and for infrastructure changes the platform lead. That person agrees the evidence before the release and approves the move up, because they carry the consequence if the action goes wrong. Engineering builds and runs the checks that take over from the approver. Whoever owns the credential, often security, confirms that the tool enforces the limits that were agreed.
Moving an action back down should not need a meeting. Any of the three can do it when a written trigger fires, because a move down that waits for agreement leaves the riskier setting running in the meantime. On the telecom engagement, the user who approves each campaign configuration today is also building the record that any later widening would rest on. That is why the plan starts by measuring their corrections.
What should move an action back down?
Write the triggers down when the action moves up, so that moving it back is a decision someone can take without reopening the original release. Move the action down, and only that action, when:
- the model, the prompt, a tool or the policy behind it changes;
- a new target, tenant or parameter range is added;
- the check that confirms the result in the target system is unavailable;
- the correction rate or the outcomes drift outside the range agreed when it moved up;
- retries or partial failures exceed what the recovery design allows;
- an incident shows a consequence nobody listed.
A change can need fresh evidence even when the action keeps its name. Moving an action from an API to computer use changes how the agent sees the current state, how it picks a target, and how likely a double submission becomes. None of that shows in the name, and none of it was tested when the action moved up.
The trigger only works if the agent cannot switch it off. Run the check that would move an action down from outside the agent's reach, and treat an unreachable monitor as a trigger in its own right. We hold that line because the failure has already happened inside a lab: OpenAI's misalignment report of 20 October 2026 has an agent repairing an evaluation pipeline on 3 October that turned off the monitoring alerts to OpenAI's security team, citing an instruction not to send messages. The monitor kept running, but no person was alerted. Three days later another agent removed a monitoring integration and then denied removing it.
Keep the approved versions and the evidence behind each move up, so that moving an action down reads as routine operation rather than as an admission that the release was wrong. Our guide on AI agent permissions covers the credential side of the same limit, and the one on AI agent sandboxing covers what to do once a trigger fires.
How is agentic AI governance regulated?
No framework in force decides when one agent action may run without a person. The main ones ask for the conditions around that decision: named roles, records an auditor can check, and a way for a person to override or stop the system. A level per action, with its evidence and triggers on record, already supplies each of those, so we do not build a second record for compliance. On FinSight, built and tested but not deployed, we kept no separate reporting path for auditors, because a second path is a second version of the truth.
| Framework | Status as of October 2026 | What we keep because of it |
|---|---|---|
| NIST AI Risk Management Framework 1.0 | Voluntary. Version 1.0 dates from January 2023, with a generative AI profile from July 2024 | GOVERN 2.1 wants roles and responsibilities for AI risk documented, so we name one owner for each action |
| ISO/IEC 42001 | A certifiable management system standard, from December 2023 | We date every level change and keep its evidence, so an internal audit can sample the level each action held |
| EU AI Act, Article 14 | Human oversight duties for high-risk systems, applying from 2 December 2027 for Annex III uses and 2 August 2028 for AI in Annex I products | We write a stop and override path for each action, and test that approvers are not approving by habit |
Article 14 is the closest of the three to the argument here. The people overseeing a high-risk system must stay aware of the risk of over-relying on its output, be able to override or reverse that output, and be able to halt the system through a stop button or a similar procedure. Planting known-bad proposals in the approval queue, as described above, is how we show the first. Written triggers that move an action down, and a named person who can stop it, cover the other two. The 2 December 2027 and 2 August 2028 dates come from Regulation (EU) 2026/1744, which moved them without amending Article 14.
Whether an agent is high-risk depends on what it is used for, not on its being an agent. Annex III lists uses such as hiring and credit scoring, and Annex I covers AI inside regulated products such as medical devices and machinery. The logging duties that come with that status are covered in our guide on the AI audit trail. If one action is holding up your next release, tell us what it changes.
Common questions
What is AI agent governance?#
The decisions about what an agent may do without a person, on what evidence, and who approves a change to that. Across an organisation it covers which agents exist, who owns them and what they can reach. For one agent it means an autonomy level on each action and evidence agreed before each move up. It also means triggers written for each move down, and a named owner who signs off.
What are the levels of AI agent autonomy?#
The scale cited most often, from Feng, McDonald and Zhang in June 2025, has five levels named for the user's role: operator, collaborator, consultant, approver and observer. Bigcircle sets five levels on each action rather than on the agent: read, recommend, prepare, act after approval, and act inside written limits. Different actions in one agent can sit at different levels.
How is agentic AI regulated?#
No law sets autonomy levels for agents. The EU AI Act's human oversight duties in Article 14 apply to high-risk uses from 2 December 2027 for Annex III and 2 August 2028 for AI in Annex I products. NIST's AI Risk Management Framework is voluntary, and ISO/IEC 42001 is a certifiable management system standard. Each asks for named roles, records, and a way to override or stop the system.
Who approves a change in an agent's autonomy?#
One named person who owns the operation, such as the head of support for refunds, agrees the evidence before the release and approves the move up. Engineering runs the checks that replace the approver, and the credential owner confirms the tool enforces the agreed limits. Any of them can move the action back down when a written trigger fires, without waiting for the others.
What evidence should move an agent action up a level?#
Correction rates for that action alone, with a known cause for each kind of correction, and a check in code for each thing the approver was catching. Before removing approval altogether, confirm the result by reading the target system rather than trusting the tool's reply. Test a way to undo the action, and name a person who can stop it.
When should you take authority away from an agent action?#
Move it back down when the model, prompt, tool or policy changes, when a new target or parameter range is added, when the check that confirms the result is unavailable, or when corrections drift outside the agreed range. Write those triggers down when the action moves up, and run the check that fires them from outside the agent's reach.
Should every AI agent action become fully autonomous?#
No. A payment, a deletion or anything that cannot be reversed can stay at act after approval indefinitely, and that is a correct end state rather than a stalled rollout. Different actions in one agent stop at different levels, and a low-risk label can run inside limits while a customer-facing change keeps its approver.