Delegated authority
AI Governance for Agentic AI
Define what AI agents may do, bind approvals to actions and reconcile uncertain outcomes before expanding autonomy.
Agentic AI governance defines what an AI agent is allowed to do, under whose authority, with which information and how the organisation can intervene. The central question changes when a system moves from suggesting an answer to making a booking, updating a record, sending an instruction or delegating work. A useful output is not the same as an authorised action.
Approve the action boundary before connecting the agent to a live service. That boundary should specify the allowed tools, transaction conditions, identity, approval requirements, execution limits and stop procedure. Keep the decision traceable to a human owner who can explain why that authority is appropriate and who can reduce or withdraw it.
This guide is for business owners, engineering leaders, security teams and governance practitioners introducing agents in Saudi organisations. It develops an original travel-booking example and a reusable authority record. It forms part of AI governance setup, with a focus on continuing delegated authority rather than a generic demonstration of agent capabilities.
Separate the goal from permission to act
“Arrange a suitable business trip” describes an outcome but leaves important decisions unresolved. May the agent search options, reserve a refundable hold, make a binding purchase, change a traveller's details or cancel an existing booking? Does the employee's instruction authorise all of those actions, and does the employee have the relevant authority?
Translate the goal into specific operations and business consequences. A system can be allowed to search broadly while being permitted to commit narrowly. An apparent convenience, such as accepting a substitute itinerary automatically, may change cost, contractual terms or operational obligations. Define those choices explicitly instead of leaving them to an agent's interpretation of the goal.
The NCSC's May 2026 guidance discussion on agentic AI adoption recommends bounded adoption, clear human accountability and the ability to monitor and contain agents. The operating design below applies those ideas to a proposed workflow; it is not a claim that any particular product or configuration has been certified or proven safe.
Build an authority record for each consequential action
| Field | What to record |
|---|---|
| Purpose and owner | The business outcome and person accountable for the use |
| Permitted operations | Read, propose, hold, submit, modify or cancel, described individually |
| Identity and delegation | Which principal acts, whose authority it represents and when it expires |
| Constraints | Allowed recipients, objects, amounts, time windows and other conditions |
| Approval requirement | Who approves, what they see and which changes require a fresh approval |
| Execution evidence | Request, authorisation, tool result and confirmed business outcome |
| Intervention | Who can stop execution, revoke access and reconcile unfinished work |
The record should describe enforceable conditions. “Use judgement” cannot substitute for a boundary where the organisation needs a definite limit. If a case falls outside the permitted set, the agent should route it to a person with the right authority rather than inventing a nearby interpretation that appears convenient.
Keep the decision-rights design connected to the technical implementation. A policy may authorise a business manager to approve purchases while the application exposes a broader service credential. The review must reconcile those two realities; a well-written authority table does not reduce permissions on its own.
Worked example: search and hold are not purchase authority
Consider a fictional company introducing a travel assistant for approved staff journeys. The initial scope allows it to find options and prepare an itinerary. The company later proposes allowing a temporary reservation hold, with a binding purchase requiring approval from an authorised travel approver. This example is illustrative; availability and terms of a real supplier's hold function must be verified.
The business owner defines the information the agent needs and keeps unrelated employee records outside the task. The travel team supplies current policy and approved booking channels. Engineering maps the available operations and confirms whether the supplier can enforce the intended distinction between a hold and a purchase. If the service cannot support that boundary, the design must change before launch.
A proposed purchase is presented with traveller, itinerary, total payable amount, relevant cancellation conditions and the exact action to be authorised. The approver sees the proposal, checks policy and either approves, rejects or requests a change. Approval should bind to that proposal; it should not authorise any future option the agent considers similar.
| Action | Proposed authority | Escalation condition |
|---|---|---|
| Search approved channels | Within the defined task and permitted information | Required source or information falls outside scope |
| Prepare itinerary | Draft for review | Policy is ambiguous or a material condition is missing |
| Create a temporary hold | Only if verified terms and technical controls support the approved boundary | The hold creates an unapproved commitment or charge |
| Purchase | Specific approval for the current proposal | Price, route, traveller or material terms change |
| Cancel or change | Separate defined authority and confirmation | Fees, downstream commitments or policy exceptions arise |
The important outcome is not maximum autonomy. It is that every executed operation can be related to a valid authority and an understood business consequence. If the purchase remains manual because the approval binding cannot be demonstrated, the search-and-draft use may still be useful within its narrower boundary.
Make approval meaningful at the moment of execution
An approval screen should show the decision that matters, not a long technical trace that obscures it. For the travel example, the approver needs the actual itinerary and commitment, the exceptions and the consequence of approval. A generic button labelled “continue” is weak evidence if the user cannot tell whether it means search, hold or buy.
Define what invalidates approval. A changed price, different traveller, new payment destination or altered cancellation term may require a fresh decision. The exact rules should reflect the business process. Do not assume that approval remains valid indefinitely or that the agent can resolve every change by choosing what it believes is equivalent.
Design for absence and conflict. If the approver is unavailable, the agent should follow a named alternative route or stop at the approved limit. It should not grant itself authority because a booking window is closing. If policy and a user instruction conflict, preserve the conflict and send it to the appropriate owner.
Distinguish request, execution and confirmed outcome
Record separate states for proposed, approved, submitted, confirmed, failed and uncertain. A tool call accepted by an intermediary is not necessarily a completed booking. A timeout does not establish that nothing happened. The operating process needs a way to reconcile uncertainty before another consequential action is attempted.
In the illustrative case, suppose the booking service receives an authorised purchase but the response is interrupted. The agent should not immediately buy again. The technical owner should define a supplier-supported method for checking the transaction and preventing duplicate commitments. Where such a method is unavailable, route the uncertain state to the travel team and restrict further attempts.
Do not let an agent's natural-language success message become the authoritative business record. The booking confirmation or other source-system result should support the reported outcome. If the agent says “completed” while confirmation is missing, that discrepancy is an operating event requiring attention.
Govern delegation and service identities
Identify whether the agent acts through a user's delegated authority, a dedicated service identity or another supported model. Record what that identity can access and change, who owns it, how access is granted and how it is revoked. Shared administrator credentials are not an acceptable substitute for designing the intended authority boundary.
If one agent can delegate to another, specify which task and permissions may pass. Delegating a search should not imply permission to purchase. The receiving agent should remain within the originating authority and its own permitted scope. Preserve a link between the initiating task, delegated work and eventual action.
Test revocation during a task, not only before one begins. If a user leaves, an approval expires or a security owner suspends the use, determine what happens to queued actions and cached credentials. The system should not continue simply because the original task was started while access was valid.
Treat external content as information, not authority
An agent may read supplier pages, messages or documents while pursuing its task. The governance design should state that content from those sources does not gain the power to change the organisation's instructions or grant new permissions. For example, a note embedded in an itinerary must not be allowed to change the payment destination or bypass the approval route.
Security teams should test attempts to induce out-of-scope actions through the actual information paths the agent uses. Business owners should help identify consequences: an apparently harmless change to a contact or cancellation instruction may affect a real commitment. Use controlled test data and agree who reviews unexpected behaviour.
Separate legitimate business exceptions from hostile or irrelevant instructions. Both may require the agent to stop and ask, but the follow-up differs. A genuine policy exception needs an authorised decision; a suspected manipulation attempt belongs in the security response process.
Test refusal, uncertainty and interruption
A useful acceptance exercise includes successful tasks and cases that should not proceed. Ask the operating team to explain the expected boundary before running each case. The test should establish what happened, why it was within or outside scope and what evidence supports that conclusion.
- Search and prepare an itinerary using only the approved information.
- Attempt purchase without the required approval and verify refusal at the execution boundary.
- Change a material booking term after approval and check that the old approval cannot authorise the changed proposal.
- Interrupt a submitted transaction and reconcile its state before any retry.
- Revoke the agent's authority while work is queued and confirm the remaining actions are contained.
- Present external content that asks the agent to bypass policy and inspect the response.
- Request cancellation with an unapproved fee and confirm escalation.
- Stop the agent and reconstruct completed, pending and uncertain actions.
This is a proposed test design, not a claim that eight cases establish complete safety. Add scenarios reflecting the actual supplier, transaction model and consequences. Retain failures and unresolved conditions instead of presenting only the successful demonstration to the decision-maker.
Define a stop procedure that covers unfinished work
A stop button must have a defined operational meaning. Does it stop new tasks, prevent new tool calls, revoke a credential, cancel queued work or all of these? Which actions have already crossed into a supplier system and can no longer be prevented by disabling the agent? The runbook should distinguish those states.
Assign a responder to reconcile completed, pending and uncertain transactions. For the travel case, stopping the assistant does not itself cancel a booking or remove a fee. Any corrective action should use the appropriate authority and source-system process. Avoid an uncontrolled cleanup agent that creates new commitments while attempting to reverse the old ones.
Connect the runbook to AI incident handling and rehearse it with the business team. A technically successful shutdown can still leave users without information about an itinerary they believe has been purchased. Communication and reconciliation are part of containment.
Review changes to authority, not only model versions
New tools, broader identity permissions, changed approval rules, additional sources and altered business terms may change the approved boundary even if the underlying model stays the same. Conversely, a model update can affect behaviour without changing the visible workflow. The review process should consider both technical and business changes.
Use AI change triggers to specify when reassessment is required and the AI impact assessment to record the changed use and consequences. Record what changed, which assumptions it affects, what tests were repeated and which conditions remain open. Do not copy the old approval date onto an expanded scope.
Review ongoing signals in relation to consequence: attempted out-of-scope actions, uncertain transactions, repeated approval requests, manual corrections and failed containment. A high task-completion count alone does not show that the agent remained within authority. Investigate whether apparent efficiency is being achieved by moving unresolved work to a human team.
Distinguish task limits from cumulative authority
An agent may comply with the limit on each action while creating an unacceptable cumulative outcome. The business owner should consider repeated bookings, simultaneous tasks and overlapping users, then define relevant aggregate boundaries. These limits must reflect the actual process; a generic transaction cap copied from another use may not address the consequence.
In the travel example, the same employee's repeated requests should not quietly create several commitments for one journey. Define how the system identifies the relevant task and checks existing work before proposing or executing another purchase. If that check cannot be performed reliably, the authority design should retain an appropriate human reconciliation step.
Also specify when a task expires. An itinerary approved for a particular journey should not remain a reusable permission after the purpose changes. Record what happens to pending holds and queued actions when the task ends. The owner should distinguish completing the task from merely closing the conversation with the user.
Review overrides with the same precision as ordinary approval
An exceptional journey may require a permitted policy exception. Identify who can approve that exception, which ordinary constraints remain and how the resulting authority reaches the agent. A reason entered in free text should not itself expand tool permissions or bypass the normal approval mechanism.
Keep exceptional authority tied to the specific case and duration. Review recurring overrides to determine whether the standard workflow is wrong, the policy is unclear or users are relying on exceptions for convenience. A pattern may justify redesign, but it does not automatically justify granting the agent permanent wider authority.
Retain the rejected alternative where it explains the decision. For example, a human may decline a cheaper itinerary because a material business condition is not met. The agent's later optimisation should not revive that option without understanding the recorded constraint. Governance preserves the reason for the boundary as well as the final permission.
Handover criteria for an operating agent
The receiving team should be able to explain the current authority, find its evidence, identify open conditions, stop further execution and reconcile one uncertain transaction. It should know who owns the business purpose, credentials, supplier relationship and incident response. Those responsibilities must remain available after the implementation project closes.
For purchased agents, connect these requirements to supplier evidence requirements and the contracted service scope. Ask for the relevant controls and transaction semantics to be demonstrated in the proposed configuration. A general statement about responsible AI does not establish how this agent binds approval to a purchase.
Bring the proposed actions, identity model and hardest unresolved case to an agentic AI governance discussion. The starting question is concrete: what may this agent do today, what must remain with a person, and what evidence would justify a future expansion?
FAQ
Your questions, answered.
What is the main governance difference between an AI assistant and an agent?
The important distinction is the authority to act. A system that drafts information needs rules for data and reliance; a system that can change records, send instructions or create commitments also needs explicit action boundaries. Classify the actual capability rather than relying on whether a supplier calls the product an assistant or an agent.
What should an AI agent authority record include?
Include the purpose, accountable owner, permitted operations, identity, delegation, constraints, approval requirement, execution evidence and intervention procedure. Describe the conditions that can actually be enforced and tested. Link business approval to technical permissions so a narrow policy is not undermined by a broadly privileged connection.
Can an agent purchase after a user approves an itinerary?
Only if that approval validly authorises the purchase under the organisation’s process and is bound to the current proposal. Define the approver’s authority and material terms. A changed price, traveller or condition may require fresh approval; a broad instruction to arrange travel should not silently authorise every resulting commitment.
How should an AI agent handle a transaction timeout?
Treat the outcome as uncertain until it is reconciled with the source system. Do not assume failure and immediately repeat a consequential operation. Use the supplier-supported transaction-checking and duplicate-prevention approach, or route the case to the responsible team when safe reconciliation cannot be automated.
Does stopping an agent reverse actions it already completed?
Not necessarily. The stop procedure must distinguish new, queued, submitted and completed actions. Disabling the agent may prevent further execution while leaving an existing commitment intact. Assign an owner to reconcile the state and authorise any cancellation or correction through the appropriate business process.
How should governance control an agent that delegates to other agents?
Define which tasks and permissions may be delegated and preserve the link to the originating authority. A delegated search must not create purchase authority. Test the receiving agent’s scope, expiry and revocation behaviour, and keep evidence linking the original task, delegated work and resulting action.
What tests matter before an agent receives live authority?
Test permitted work, refused actions, changes after approval, uncertain transactions, revocation, hostile external instructions, exceptional fees and stopping with unfinished work. Expected outcomes should be agreed in advance. The test set must reflect the actual use and consequences; a small successful demo cannot establish universal reliability.
When should an agent’s approval be reviewed again?
Review material changes to tools, identities, permissions, approval rules, sources, business terms or model behaviour. Also review incidents and repeated exceptions that undermine prior assumptions. Record the revised scope and evidence rather than carrying an old approval forward to a more capable agent.