AI Agent Governance

AI agent governance defines who may delegate work to an AI agent, which actions the agent may take, what evidence and approval those actions require, and how people can monitor, restrict or stop the work. It connects organizational responsibility to the permissions and decisions through which an agent affects real systems.

The practical starting point is a consequential action. Reading a customer record, proposing a change, sending a message and committing a refund are different grants of authority. An agent that can produce a useful recommendation does not automatically need permission to carry it out.

HALO's approach is to make delegated authority inspectable. An operating owner should be able to explain what this agent may do, for whom, on which resources, under what conditions, and how that permission can end. This article proposes a review method; it does not establish that a particular agent or platform is safe, compliant or certified.

Govern the actions as well as the answers

An agent's output can lead to a tool call that reads or changes another system. Review therefore needs to examine the action boundary as well as the quality of the generated answer.

OWASP's 2025 Excessive Agency guidance identifies excessive functionality, permissions and autonomy as causes of damaging actions. It recommends narrowing tool capabilities and privileges, checking authorization in downstream systems, and requiring approval for high-impact actions. Its guidance supports examining what a tool permits, rather than relying on a model's instruction to behave. OWASP Excessive Agency.

Microsoft's agent shared-responsibility guidance also separates orchestration, tools/actions and memory concerns. It describes per-action authorization and human oversight, while noting that actual responsibilities vary with service terms and configuration. That is provider guidance, not a universal allocation of legal responsibility. Microsoft's AI agent shared responsibility model.

The field is still developing. NIST's NCCoE identity and authorization project describes practical implementation guidance as an intended output of its work. We do not treat that project description as a completed agent-governance certification standard. NCCoE project resource hub.

For the broader organizational framework, see what an AI governance framework should govern. The concern here is narrower: the conditions under which an agent may act and the people responsible for those conditions.

Give each grant of authority a clear scope

Start with a task someone actually wants delegated. Define the result, affected systems and consequences of error. Then separate the powers needed to investigate from those needed to commit a change.

Permission	Proposed boundary	Question for review
Read	Retrieve defined records within the user's authorized scope	Can the tool expose records this user could not otherwise access?
Propose	Produce a recommendation or draft without changing the authoritative record	Is the proposal clearly distinguishable from an executed action?
Write	Change a defined field or create an internal record under stated conditions	Which fields, resources and values are permitted?
Send or commit	Cause an external effect, such as sending a response or issuing a refund	Which approval and transaction checks must pass first?
Delegate	Ask another agent or service to carry out part of the task	Does the recipient receive only the authority needed for that part?

This table is a HALO review aid, not a formal permission model. A real implementation may combine or divide these operations differently. Test the effective permissions of the connected identity, not only the labels shown in a configuration screen.

A read-only assistant connected through an account that can also change and delete records has an unresolved boundary. Determine whether the tool interface and receiving system actually prevent those changes. Document which component enforces the restriction and what happens when enforcement is unavailable.

Record the authority before exercising it

A short authority record can make the review concrete. The following example is hypothetical. It is not a HALO deployment, a recovered customer record or an output of HALO Engine.

An organization wants an agent to investigate a customer's disputed delivery charge. The agent may retrieve relevant order and policy information and prepare a refund recommendation. It may not issue the refund by itself.

Field	Illustrative authority record
Accountable owner	Named customer-operations manager
Purpose	Investigate a disputed delivery charge and propose a response
Information scope	The authorized customer's relevant order and current approved refund policy
Permitted actions	Retrieve records and create an internal recommendation
Prohibited actions	Change bank details, issue payment, delete records or send an unreviewed response
Approval	Authorized reviewer checks customer, order, amount, policy basis and final action
Exception	Conflicting records, unclear authority or changed terms stop commitment and reach the owner
Revocation	Owner can disable the grant; pending proposals do not preserve authority to commit
Evidence	Source references, proposal version, permission decision, reviewer decision and separate action outcome

The design gives the agent room to investigate while reserving commitment. It still needs implementation evidence. Can the refund tool reject an unapproved request? Can the user identity access only the relevant customer's records? Does the approval refer to the final amount? A completed table is an instruction for verification, not proof that the boundary exists.

Approval needs an action and a version

Show the reviewer the action they would authorize: affected record, amount or content, intended recipient, supporting source, uncertainty and consequences. Record whether approval applies once, for a limited period or within a defined recurring scope.

In the hypothetical example, approval for one refund amount should not silently become approval for a different amount or customer. Decide what changes invalidate the decision and which component checks that relationship before commitment.

Define rejection, timeout and absence as well. If the reviewer cannot respond, does the operation remain paused, move to another authorized reviewer or end? A system should not interpret silence as permission merely because waiting is inconvenient.

Review capacity matters. An approver needs sufficient context, time and ability to intervene. Adding a confirmation screen does not establish that the decision is meaningful. For lower-consequence, well-bounded actions, an organization may choose standing rules instead of individual approval; the owner should record and test that choice.

Identity and authorization are separate questions

Identity concerns which person, agent or service is making a request. Authorization concerns whether this request is allowed on this resource under the applicable conditions. An authenticated request can still be outside the task's authority.

Our recommendation is to preserve the connection between the person delegating work, the agent's task and the identity used by each downstream tool. Avoid assuming that permission to use one tool grants every permission held by its service account.

Ask what happens when work moves to another agent. Does it receive the task's constraints and only the necessary access, or does it acquire a broad standing identity? Require an explicit decision about further delegation and its limits. More participants should not make responsibility harder to locate.

Source material also needs a boundary. A retrieved page or message can supply information relevant to the task without becoming authority to expand permissions. OWASP discusses indirect prompt injection as a route to excessive agency; it is a reason to examine tools and permissions even when the initial request is legitimate. OWASP's risk description.

Monitor decisions and verify outcomes

For a consequential action, an authorized reviewer should be able to reconstruct the request, the information used, the applicable grant, any required approval and the receiving system's result. These records support different claims. A successful tool invocation does not by itself prove that a refund settled or a customer received a message.

Collect what is necessary for those questions and protect it. Do not put unrestricted customer records, credentials or private messages into a convenient shared trace. Decide who may inspect the evidence, how long it is needed and which event calls for intervention.

A useful monitoring question is whether behavior is leaving the intended scope: unexpected tools, repeated denied requests, unusual destinations or repeated attempts after failure. These are proposed review signals, not a complete detection method. Define the response and owner for each signal that matters.

Revocation must reach pending work

Specify who can pause the agent, remove tool access or revoke a task's authority. Then examine what that decision does to work already queued or waiting for approval.

In the hypothetical refund workflow, revoking the investigation should prevent a pending proposal from later becoming a committed payment under the old grant. Test that case alongside an expired approval, a changed customer record and a failed authorization service.

An attempted refund with an uncertain result needs reconciliation before another attempt. Investigate whether the receiving system completed it and use tested duplicate-prevention mechanisms where available. Revocation is also not a reversal: stopping future actions does not undo a message already sent or a transaction already completed. Assign responsibility for recovery separately.

Evaluate governance claims with a bounded demonstration

Ask a prospective platform or implementation team to show an allowed action and a prohibited one against a contained test resource. Then ask them to change the approval, remove permission or make a prerequisite unavailable.

Inspect the result at the system that enforces the boundary. A warning in the agent's interface is insufficient evidence if the external action still succeeds. Conversely, a denied request may show a control working even when the agent itself attempted something inappropriate.

Useful evaluation questions include:

1. Who owns the agent's purpose, permissions and exceptions?
2. Which person or system grants authority for each consequential action?
3. What prevents access outside the delegating user's scope?
4. Which approval applies to the final proposed action?
5. How do rejection, timeout and failed authorization behave?
6. Can revocation prevent a pending action from proceeding?
7. Which records establish completion, and which facts remain unknown?

The answers should inform a release decision, a narrower pilot or further work. They are not a substitute for specialist security, legal or sector assessment where the use and its consequences require it.

HALO ENGINE — AI ORCHESTRATION RISK SCAN

Before granting broader agent authority, examine the surrounding operating arrangements.

HALO Engine uses a structured, response-based diagnostic to help you examine relationships among your tools, data, workflows, permissions and controls, identify potential weaknesses, and determine what deserves closer attention.

Run the HALO Engine Risk Scan

The scan is based on your responses; it does not independently audit your systems or certify compliance.

Keep delegation answerable to an owner

AI agent governance should leave an organization able to explain a real action: why it was within scope, what supported it, who could approve or stop it and what actually happened.

Begin with a grant small enough to inspect, demonstrate the boundary and review the exceptions before broadening it. Useful autonomy depends on a deliberate operating arrangement and evidence of how that arrangement behaves.