Ask a team what its agent is allowed to do and you will usually hear what it is able to do. "It can read the schedule, update cases and book re-collections." That is a list of capabilities. It says nothing about what the organisation has decided the agent should do on its own, under which limits, and with whose approval.
In human terms, the difference is obvious. A new clerk at a municipal office may have a login that can see every account, but the delegation of authority says what that clerk may approve. Nobody confuses the two. With agents, the confusion is routine, because the capability arrives through a connector and the authority is assumed to live in the prompt.
This part separates the two and gives a practical model for delegating authority to an agent, using Ubuntu Municipal Services, the fictional municipal entity in this series.
Where capability comes from
An agent's capability is the sum of what its tools and accounts can do. If its case-management connector uses a service account that can edit any record, the agent can edit any record. If its database tool runs queries under an administrator login, the agent can run administrator queries. The model's instructions do not reduce that capability; they only make some uses less likely.
That is why "we told it not to" is not a control. Prompts influence behaviour. Permissions constrain it. We made the same point about tool access in Tools: how AI agents actually do work and about gateways in The gateway is a control point, not a trust boundary.
When Ubuntu's team drew this picture, the outer box was larger than anyone expected. The integration account had been created for a data migration years earlier and never narrowed. The agent could, in principle, change billing records and close other residents' cases. Nobody intended that, and no prompt would reliably prevent it. The first and most effective control was narrowing the account.
Authority is granted per action
Authority should be delegated per action, not per agent. One agent can be allowed to act freely on some steps and only recommend on others. A five-level model covers most enterprise needs. Our authority ladder for cloud operations agents uses six levels, numbered 0 to 5 and tuned to infrastructure changes; the five here are a general form for business actions.
| Level | The agent may | Typical controls |
|---|---|---|
| 1. Inform | Provide information from approved sources | Read-only identity, logged answers |
| 2. Recommend | Propose an action for a person to take | Sources and reasoning shown; a person decides |
| 3. Prepare | Prepare an action that a person approves before it takes effect | Approval step with evidence, approver recorded |
| 4. Act within limits | Take the action itself, within thresholds | Value and frequency limits, actions safe to repeat, reversibility |
| 5. Act and report | Take broader actions and report afterwards | Named owner, full audit trail, rapid suspension |
At Ubuntu, the agent informs residents about schedules (level 1), recommends re-collection dates (level 2), prepares work orders that a supervisor approves (level 3), and books one re-collection slot per case when the route log confirms a miss (level 4). Issuing service credits was considered for level 5 and deliberately not delegated. Writing down what you chose not to delegate is as useful as writing down what you did.
Limits that make level 4 safe
"Act within limits" only means something if the limits are explicit and enforced outside the model. For Ubuntu's booking action:
- Scope: only for a case where the route log shows the street was missed.
- Quantity: one booking per case; a second request goes to an official.
- Repetition: the booking call carries the case reference, so a retry after a timeout cannot create a second booking.
- Reversibility: a booking can be cancelled by an official within the day without cost.
- Volume: if bookings in an area exceed a daily threshold, the agent stops booking and alerts the depot supervisor, because a pattern of misses is an operational problem, not a series of individual complaints.
Each limit is enforced by the scheduling system or the integration layer, not by an instruction to the model. The thresholds are illustrative; the principle is that the agent's authority is checked where the action happens.
The agent must not expand its own authority
One question deserves its own section: can the agent change its own permissions, tools or limits? In a well-designed system, no. It should not be able to request new scopes, enable additional tools, alter its configuration or edit the policy that governs it. Changes to authority go through the same change process as any other delegation, with a person approving and a record kept.
This matters more as agents gain access to platform tools. An agent that can modify the infrastructure it runs on, or the identity it runs under, can widen its capability in ways nobody reviewed.
Identity: under whose name?
Every action an agent takes should be traceable to three things: the agent's own identity, the person or event that started the work, and the person who approved it where approval applied. Running agents under a shared service account, or under the identity of whoever happens to be logged in, makes that impossible.
For South African public bodies, this is not only good practice. Administrative decisions must be attributable and explainable, and records that cannot say who acted, on whose behalf and under what delegation will struggle under audit. The same applies to any organisation processing personal information under POPIA, where access to a resident's details should be limited to what the purpose requires.
A short test for any agent
- List every tool and the account it uses. What can each account actually do?
- For each action, which of the five levels applies, and where is that written?
- Which limits are enforced outside the model, and where?
- Can the agent change its own tools, permissions or limits?
- For any action last week, can you name the agent, the initiator and the approver?
If the capability list is longer than the authority list, close the gap from the capability side first. It is cheaper and more reliable than trying to close it with instructions.
Key points
- Capability comes from tools and accounts; authority is a decision the organisation makes.
- Delegate authority per action using a small number of levels, and record what was not delegated.
- Enforce limits where actions happen, not in the prompt.
- An agent must not be able to expand its own authority.
Next: Part 5, Memory is not state. All parts are on the series page. For the wider argument on delegation, see Delegation does not remove accountability.
How CloudNala can help
CloudNala helps organisations write the delegation of authority for their agents. We inventory tools and accounts, compare capability with intended authority, design per-action limits that are enforced outside the model, and produce an authority matrix that risk, audit and engineering can use.
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.
Book an Agent Due-Diligence Review or write to us at consult@cloudnala.co.za