Agents change the risk boundary: authority, approval and tool contracts

A chatbot produces text. An agent can search systems, create records, send messages, change access, submit forms, initiate payments or hand work to another agent. An answer can be wrong. An action can be irreversible.

The moment a model can act, three questions need written answers before anything else is designed:

1. Who is the agent acting for?
2. What is it allowed to do?
3. Who is accountable when the action is wrong?

Most agent designs answer a fourth question instead, "what can the agent do?", and treat the list of tools as the answer. The tools describe technical reach. They say nothing about legitimate use.

Fynbos Health Administrators is fictional, and its systems and figures are illustrative. Fynbos's third AI product is the Claims Query agent. A contact-centre agent invokes it during a member's call. It can read the claim status of the member on the line, draft a claim resubmission, log a service ticket in the ticketing platform, and apply a goodwill credit when a member disputes an administration fee. Each of those is useful. Each, done wrongly, has a cost: a privacy breach, a wrong submission, a flood of tickets, or money paid out that should not have been.

The agent is an identity, not a name

"Claims Assistant" on a slide is a label, not an identity. In Microsoft Foundry, an agent identity is, in Microsoft's words, a special service principal in Microsoft Entra ID, and it can be assigned permissions like any other identity. Foundry creates an agent identity blueprint and agent identities for this purpose. One detail matters for design reviews: at the time of writing, agents that have not been published share their project's identity, and publishing an agent gives it a distinct identity whose roles then have to be assigned again. See Microsoft's agent identity concepts.

That identity defines what the agent can reach. Business policy has to define what it may do, for whom, and within which limits. The rest of this part is about that second half.

Separate reasoning from enforcement

The single most useful design principle for agents is this: the model may propose an action; deterministic controls decide whether it happens.

Reasoning about what to do next is probabilistic. That is what makes agents useful, and it is also why the model's reasoning cannot be the control. Before anything executes, ordinary code should check the identity the action is for, the parameters, the limits and the policy, and route to a human where the rules say so. Execution itself should be deterministic and should leave a receipt: what was done, for whom, with what parameters, under which approval.

If the policy check fails, the agent refuses, logs the refusal and explains it. If the policy service is unavailable, the system should fail closed: no policy answer means no action.

The authority envelope

"RBAC will be applied" is not an agent design. An authority envelope is: a written set of limits for each agent and tool, each enforced outside the model.

Reversibility deserves attention. Wherever the business allows it, prefer actions that can be undone: drafts instead of submissions, queued changes instead of immediate ones, soft deletes instead of hard ones. Fynbos's agent prepares resubmissions for the human agent to submit, because a wrongly submitted claim is a much harder problem than a wrongly drafted one.

Whose authority does the agent use?

An agent can act with one of three kinds of authority, and the choice should be deliberate and visible on the sequence diagram.

User-delegated authority limits the agent to what the signed-in user can do. It is easy to reason about, but it does not make every action safe: a user may have broad access while the agent should use only a small part of it. A Fynbos contact-centre agent can look up any member. The Claims Query agent should only ever look up one.

Application authority uses the agent's or workload's own identity. It supports unattended work, but it creates a powerful service identity whose permissions apply to every request, from every user.

Brokered authority has a policy service issue a narrow, short-lived capability for one approved action. It gives the tightest control and costs the most engineering.

Fynbos uses delegated authority for reads, scoped further by the active call, and brokered authority for credits. When the agent proposes a credit, the policy service checks the amount, the member, the call and the approval rule, and issues a capability valid for one credit, of one amount, for one member, for a few minutes. The agent cannot reuse it, raise it or apply it to someone else.

Human approval needs a real design

"Human in the loop" on a diagram is a label. It becomes a control only when these questions have answers:

• Which events require approval?
• Who is qualified and authorised to approve?
• What evidence does the approver see?
• Can the approver edit the action, and if so, is the edited version re-checked?
• How long does the request stay valid?
• What happens if nobody responds?
• Can the agent retry after a rejection?
• Is the approval bound to the exact payload that executes?
• How is an emergency override handled?
• What is recorded for audit?

For Fynbos's credits above R500, the team leader sees the member, the disputed fee, the proposed amount and the agent's stated reason; can approve, reduce or reject; and the approval expires when the call ends. The approval is bound to the payload: if anything about the credit changes after approval, it needs approving again.

Approval fatigue is a real risk. If every harmless action needs a click, people learn to click without reading. Fynbos deliberately did not require approval for reads, drafts or tickets. Human control belongs where judgement, material impact or uncertainty justifies it.

Every tool is a contract

A tool is not a function description the model reads. It is a contract with a downstream system, and it should be specified like one:

• input schema and validation;
• authorisation requirements;
• idempotency behaviour;
• timeout and retry rules;
• rate and transaction limits;
• expected side effects;
• compensation or reversal;
• sensitive fields and logging rules;
• an error taxonomy;
• the evidence returned to the agent and the user.

Idempotency is the item most often missing, and Fynbos found out why in testing. The ticketing API timed out after it had actually created a ticket. The agent saw a failure and retried. The member now had two tickets. Nothing broke badly, because tickets are cheap, but the same pattern with a credit would have paid out twice.

The fix had two parts. Each intended action now carries an idempotency key, so a repeated request is recognised and not executed twice. And "uncertain" became a distinct outcome from "failed": when a call times out, the tool checks whether the action happened before it is allowed to try again. More on tool design in Tools: how AI agents do work.

Record each tool's contract as a decision record. Fynbos's credit tool looks like this:

agent_tool:
  tool_name: "ApplyGoodwillCredit"
  business_purpose: "Resolve administration-fee disputes during a member call"
  calling_agent: "Claims Query agent (published agent identity)"
  downstream_system: "Claims administration system, via claims API"
  authority_model: "Brokered"
  permitted_actions: ["apply credit to verified caller's account"]
  prohibited_actions: ["credit another member", "reverse a credit", "change a claim"]
  parameter_limits: { max_without_approval_zar: 500 }
  approval_rules: ["team leader above R500, bound to exact payload, expires at call end"]
  idempotency_key: "call ID + member token + proposed amount"
  timeout_and_retry: "On timeout, query outcome before any retry; no blind retries"
  compensation: "Manual reversal by finance operations, logged"
  audit_evidence: ["capability ID", "approver", "receipt from claims API"]
  owner: "Head of Member Services"

Memory and state are not the same thing

Agents blur several kinds of information that should be kept apart:

• Conversation context is what the model is given for the current reasoning step.
• Session state supports the active interaction.
• Long-term memory keeps selected information across sessions.
• Business system state is the authoritative record of real-world work.
• Audit evidence explains what happened and why.

Do not let agent memory become an ungoverned copy of the system of record. If it is kept at all, it needs rules for consent, source, retention, correction, deletion, access and what happens when memory and the system of record disagree (the system of record wins). Fynbos's Claims Query agent keeps no long-term memory of members: every call starts from the claims system. Memory for AI agents covers the design options.

When agents call agents

Multi-agent designs multiply trust decisions. When one agent delegates to another, record the initiating user and purpose, the delegating agent, the receiving agent's identity, the authority passed on, reduced or refused, the data included, the tools each agent may call, and the accountable product owner.

Foundry supports several ways for one agent to authenticate to another, including a key, the Entra agent identity, the project's managed identity, OAuth identity passthrough on behalf of the user, or no authentication at all. Authentication secures the call. It does not prove the delegation was appropriate. Authority should only ever narrow as it passes down a chain, never widen, which is the same principle as segmenting a network (zero trust and service networking covers it from the network side).

Red-team the action path

Testing whether the model says something unsafe is not enough. Test whether it can be made to do something it should not:

• Can a caller talk the agent past the R500 limit?
• Can a retrieved document trigger a tool call?
• Can one member's call influence another member's actions?
• Can the agent call a tool after an approval has expired?
• Can a tool's response manipulate the next planning step?
• Can retries duplicate a transaction?
• Can the agent bypass the application and call a model or tool endpoint directly?
• Can sensitive data appear in trace payloads or error messages?
• Does the system fail closed when the policy service is down?

Common mistakes

• Treating the tool list as the authority model. Tools describe reach; the envelope describes legitimate use.
• Letting the model enforce its own limits. A limit in a prompt is a suggestion. Enforce it in code.
• "Human in the loop" as a diagram label. Without an approver, evidence, expiry and payload binding, it is not a control.
• Requiring approval for everything. Approval fatigue turns review into reflex.
• No idempotency on tools. One uncertain response becomes two real transactions.
• Forgetting that publishing changes the agent's identity. Roles assigned to the project identity do not carry over.
• Agent memory as a shadow system of record. The authoritative system wins, and memory needs retention rules.

Evidence a reviewer should ask for

• The authority envelope for each agent and tool, and where each limit is enforced.
• The authority model (delegated, application or brokered) per action, on the sequence diagram.
• The approval design: who, what they see, expiry, payload binding, audit.
• A tool contract for every tool, with idempotency and timeout behaviour.
• Red-team results for the action path, including retries and expired approvals.
• Evidence that the system fails closed when policy services are unavailable.

What to take from this part

The model proposes; deterministic controls decide. Reasoning can be probabilistic; authority cannot.

Write the authority envelope. Subject, resources, actions, limits, time, data, destinations, frequency, approval, reversibility.

Choose delegated, application or brokered authority on purpose. And show the choice.

Design approval as a state machine. Bound to the payload, with an expiry and an audit record.

Make every tool idempotent. "Uncertain" is not "failed".

Next in the series: Production begins after deployment: operating an enterprise AI product.

How CloudNala can help

We help organisations move agents from demonstration to controlled operation: writing authority envelopes with the business owners who carry the risk, choosing the authority model for each action, designing approval flows people will actually use, specifying tool contracts with idempotency and compensation, and red-teaming the action path rather than only the chat.

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 AI Production Readiness Review or write to us at consult@cloudnala.co.za