In brief
How should organisations govern AI agents?
By deciding, action by action, what an agent is allowed to read, propose, execute and never do, and then enforcing those decisions through narrow tools, permissions, approval gates, budgets, tracing and adversarial testing. Governance starts with authority, not with the framework.
Agent projects often begin with the exciting question: what could an agent do for us? The more useful question comes next and is frequently skipped: what should an agent be allowed to do? Without a deliberate answer, permissions tend to grow informally. A developer grants access to a mailbox to make a demo work, then to a ticketing system, then to a database, and before long an experimental agent can take consequential actions that nobody formally approved.
An authority map is a simple way to prevent that drift. It is a document, and eventually a configuration, that lists every capability an agent might use and assigns each one an explicit level of authority.
The four levels of agent authority
We use four levels. They are deliberately plain so that business owners, security teams and engineers can discuss them without translation.
| Level | What the agent may do | Typical examples |
|---|---|---|
| Read | Retrieve information within defined scopes | Search a knowledge base, look up an order status, read recent log entries |
| Propose | Prepare an action for a person to approve | Draft a customer reply, prepare a refund, suggest a configuration change |
| Execute within limits | Carry out an action automatically inside set boundaries | Update a ticket category, schedule a follow-up, issue refunds below a small threshold |
| Prohibited | Never permitted, regardless of instructions | Change payment details, delete records, contact regulators, grant access rights |
The value of the table lies in the conversation it forces. A support leader may be comfortable with an agent updating ticket fields but not with it sending emails. A finance controller may accept automated refunds below a threshold but want every larger one reviewed. These are business decisions, and they should be recorded as such.
How to build the map
- List the goal of the agent in one sentence, including what is out of scope.
- List every system the agent might need and every action within each system, not just the ones planned for the first release.
- For each action, ask what happens if the agent does it wrongly, repeatedly or at the wrong time. Note whether the effect is reversible.
- Assign a level to each action with the business owner. When in doubt, choose the more restrictive level.
- Record the conditions for execution, such as value limits, time windows or required confidence.
- Name the accountable owner for the agent and the person who can change the map.
The map should be reviewed whenever the agent gains a new tool or a new use, and at a fixed interval even if nothing appears to have changed.
Turning the map into controls
Narrow tools instead of broad access
An agent should not receive a general database connection or an email account. It should receive tools that do one thing, such as get_order_status or create_refund_proposal, each with typed inputs, validation and its own permission check. Narrow tools make the authority map enforceable in code rather than in prompts.
Approval gates that change risk
Approval steps are only useful when they appear where risk actually changes and when the approver has enough context to decide. An approval request should show what the agent intends to do, why, the evidence it used and what will happen if the action is approved. Approving a vague summary is not meaningful oversight.
Budgets and stopping conditions
Agents can loop, retry or pursue unproductive paths. Hard limits on steps, elapsed time, tool calls and model spend give predictable behaviour and cap the damage of unexpected failures. When a limit is reached, the agent should stop and hand over, not improvise.
Tracing every run
Each run should record the instructions received, the plan formed, every tool call with inputs and outputs, and the final result. Traces make incidents diagnosable, support audits and reveal where the authority map needs adjusting.
Testing behaviour, not just accuracy
Conventional testing asks whether the agent completes tasks correctly. Governance testing asks different questions:
- Does the agent refuse actions outside its authority, even when instructed to perform them?
- Does content containing hidden instructions, such as an email saying ignore previous instructions, change its behaviour?
- What happens when a tool fails, returns unexpected data or times out?
- Does the agent respect value limits and escalation rules at their boundaries?
- Can a person understand, from the trace alone, why the agent acted as it did?
These tests should run whenever the model, prompts or tools change. Model updates from providers can alter behaviour in ways that simple accuracy checks will not catch.
Starting conservatively and earning autonomy
A practical rollout starts with the agent in propose-only mode for everything beyond reading. Proposals and human decisions are logged. After a period of consistent results, specific low-risk actions move to execute within limits, one at a time, with monitoring. High-consequence actions often remain at propose permanently, and that is a sensible outcome rather than a failure of ambition.
Autonomy is granted per action, on evidence, and can be withdrawn. It is never granted to an agent as a whole.
Sources and further reading
About the author: Dr. RohitCo-Founder, Director and Chief Technology Officer, AARHIT Systems. Writes on technology strategy, AI architecture, agents, evaluation and AI governance. More articles by Dr. Rohit