Most organisations do not decide to give an AI agent write access to production. They drift into it. The read-only assistant works well, someone asks whether it could also restart the stuck job, the restart works, and a month later the same assistant is scaling databases and deleting test resources because each individual step seemed small.
The problem with drift is not that any one step was reckless. It is that nobody can say, afterwards, what the agent is allowed to do, in which environments, under whose approval, and on what evidence that permission was granted. When something goes wrong, that is the first thing the incident review, the auditor and the board will ask.
The fix is to make authority explicit, graduated and earned. Part 1 described the starting point: an operations agent that can only read. This part describes the rest of the ladder and how to climb it on purpose.
Six levels of authority
Ilanga Retail Group is fictional, and its systems and figures are illustrative. Ilanga's platform team adopted a six-level ladder for Ops Desk, its operations assistant. The levels describe what the agent may do, not how clever it is.
| Level | Agent behaviour | Example at Ilanga |
|---|---|---|
| 0 | Explain only | Explain what a bucket policy or role assignment permits |
| 1 | Observe | List public buckets and last night's function errors |
| 2 | Recommend | Propose a configuration correction, in words |
| 3 | Prepare | Produce the actual infrastructure change for review, without applying it |
| 4 | Execute with approval | Create a private, encrypted bucket after a named engineer approves the exact change |
| 5 | Execute within policy | Apply a missing mandatory tag on a test resource automatically |
The line that matters most is between Levels 2 and 3. Below it, the estate cannot change because of anything the agent does; the worst outcome is bad advice. From Level 3 upwards, the agent produces or applies a change, and the controls have to be built for that.
Level 3 is the most underrated rung. An agent that writes the Terraform change, the CloudFormation change set or the Azure deployment template, and stops there, gives engineers most of the time saving with almost none of the risk. The change goes through the same review, pipeline and change process as a human-written one. Part 7 argues this should be the default for most production work for a long time.
Level 5 is the one to be most careful with. "Execute within policy" means the agent acts without a person approving each action, because a policy has already approved a narrow class of them. That is legitimate for genuinely low-risk, reversible, well-understood actions. It is not legitimate as a general state of trust.
Authority is per action and per environment
A single level for the whole agent is too coarse. "Ops Desk is Level 4" says nothing about whether it may delete a production database. The useful unit is the combination of an action and an environment.
Ilanga's platform team wrote its map before giving Ops Desk any write tool, and the change advisory board signed it off like any other operating standard. The diagram shows an extract. The map is a target, not a starting state: Ops Desk climbed towards it over ninety days, one gate at a time, as Part 7 describes. Three patterns in the map are worth copying:
- Production sits lower almost everywhere. Adding a missing tag is automatic in test but only prepared in production, because even a tag change in production can trigger cost allocation, policy evaluation or automation that someone depends on.
- Some actions never climb. Changing a security rule stays at Level 3 everywhere: Ops Desk drafts it, a person reviews and applies it. Deleting anything in production stays at Level 2. These are not temporary settings waiting for the model to improve. They reflect where Ilanga wants human judgement regardless of how good the agent becomes.
- Level 5 is a short, named list. Two remediations only: tagging test resources, and stopping test virtual machines that carry an auto-stop tag and are still running after 20:00. Both are reversible and both already existed as scripts. Ops Desk did not invent the capability; it was allowed to trigger it.
What moves an agent up a level
The question to ask before each promotion is not "is the model good enough?" It is "what evidence do we have that this action, in this environment, goes right often enough and fails safely enough?"
At Ilanga, promotion criteria were written down per step:
- From Observe to Recommend: a month of read-only answers checked against an engineer's own answer, with the error rate and the type of error recorded. Recommendations add a new failure mode, persuasive bad advice, so the team also checked whether recommendations cited the evidence they relied on.
- From Recommend to Prepare: a sample of prepared changes compared with what an engineer would have written, and every prepared change passing the same policy checks and pipeline tests as human work.
- From Prepare to Execute with approval: a working approval path in which the approver sees the exact change, cost estimate and rollback before saying yes, and in which the agent cannot alter the change after approval. Part 3 covers how.
- From Execute with approval to Execute within policy: a record showing the action was approved unchanged in nearly every case, with no incidents, plus a tested way to stop it. If approvers never change or reject a class of action, the approval is adding delay without adding judgement, and policy can take over. If they sometimes reject it, the approval is doing real work and should stay.
That last test is a useful way to think about the whole ladder. Human approval is a control, not a ceremony. Where it catches problems, keep it. Where it only ever rubber-stamps, either replace it with a policy or redesign it so the approver is shown what actually matters.
Climbing down is part of the design
Authority should be easy to remove. Ilanga built three ways to reduce Ops Desk's level, each tested quarterly:
- A per-action switch that drops one action to Level 2 without touching anything else, used when a provider changes an API or a new failure appears.
- An environment switch that makes Ops Desk read-only in production, used during peak trading and the December change freeze.
- A kill switch that revokes the write identities entirely. Part 5 explains why this belongs in the architecture rather than in a runbook.
When an incident review finds that an agent action contributed to a problem, the default response at Ilanga is to step that action down a level while the cause is understood, exactly as a team would temporarily withdraw a human's access to a system they had misused by mistake.
Separation of duties does not disappear
South African financial services, listed companies and the public sector all operate under expectations that the person who requests a change is not the same person who approves it, and that production changes are traceable to a named, accountable individual. An AI agent does not remove those expectations. It adds a new participant that must fit inside them.
Two rules followed for Ilanga:
- The agent never approves its own work. If Ops Desk prepared a change, a person approves it. If a person asked Ops Desk to make a change, someone other than the agent decides whether it needs further approval: that is the job of the policy service described in Part 3.
- The approver is a named person, not a channel. "Approved in Teams" is not an approval if anyone in the channel could have clicked the button. Ilanga's approvals are tied to the approver's own identity and recorded with the change.
These are the same principles CloudNala's AI Before the Rulebook series applies to decisions about people: assistance should not quietly inherit authority that was never granted.
Key points
Make authority explicit. Six levels, from explain to execute within policy, give everyone the same vocabulary for what an agent may do.
Map it per action and per environment. A single level for the whole agent hides the decisions that matter.
Level 3 is the workhorse. Preparing changes for normal review gives most of the benefit with little new risk.
Promotion needs evidence. Each step up should be justified by a record of real work, not by a successful demonstration.
Design the way down. Per-action switches, environment switches and a kill switch make authority reversible.
Next: Part 3, The cloud API is the contract. All parts are on the series page.
How CloudNala can help
We help platform teams write their authority map: which actions an operations agent may observe, recommend, prepare or execute, in which environments, with which approvals and on what evidence. The result is a short operating standard your change board can sign off, and a promotion path that does not depend on anyone's enthusiasm for the last demo.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Operations AI Review or write to us at consult@cloudnala.co.za