Every agent incident review arrives at the same question sooner or later. The agent deleted the records, sent the email, merged the change or moved the money, and someone asks who authorised it. The honest answer is rarely a person. It is a setting, a token or a standing approval that somebody clicked once, months earlier, for a different task, and that nobody has looked at since.
Model governance asks whether an output was right. Agent governance has to ask a different question first: whether the action was allowed. That question is about authority, meaning what an agent may do, on whose behalf, within what limits and with whose approval. It is also the part of agent governance that most programmes have not yet built, because the tooling that grants authority to agents was designed for convenience, not accountability.
This guide is about that gap. It sits alongside our broader agentic AI governance framework and goes one level deeper into a single control area: how agents get authority today, what the emerging standards now expect, why human approval so often stops being a control, and a practical model for granting, limiting and evidencing agent authority.
Why authority is the agent governance question
A model that produces a wrong answer creates a risk that a person must then act on. An agent removes that step. It reads, decides and acts, often across several systems, and the action is the harm. A hallucinated figure in a draft is an error. A hallucinated figure in a payment instruction that an agent has already submitted is an incident.
That shift moves the centre of gravity of governance. Accuracy, bias and robustness still matter, but the controls that decide whether a bad decision becomes a bad outcome are about authority: what the agent could reach, what it could change, and whether anybody had to agree before it did. An agent with poor judgement and narrow authority is an annoyance. An agent with good judgement and broad, unreviewed authority is an incident that has not happened yet.
The working definition. Agent authority is the set of actions an agent can take without a further human decision, together with the identity it takes them under. Governing it means being able to answer, for any action an agent took, three questions: who delegated this authority, what were its limits, and where is the record.
How agents actually get authority today
In most organisations nobody sets out to grant an agent broad authority. It accumulates, through four routes that each look reasonable on the day.
None of these routes is visible in a model inventory, and most are invisible to network controls. When we scanned a single developer laptop for our endpoint governance guide, the permission state told a clearer story than the tool count: 783 standing pre-approvals, a default mode set to run unattended, and 181 of 184 recorded agent sessions that had run without a person approving each step. Nothing about that was malicious or unusual. It was simply authority that had accumulated and never been reviewed.
What the emerging standards now expect
A year ago there was little specific guidance on agent authority. There is now enough to build a programme on, and the sources agree more than they differ.
OWASP Top 10 for Agentic Applications. Published by the OWASP GenAI Security Project on 9 December 2025, the list names ten risk categories specific to agents. Three of them are directly about authority: ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, and ASI09 Human-Agent Trust Exploitation. Several of the others, including ASI01 Agent Goal Hijack and ASI10 Rogue Agents, do most of their damage through whatever authority the compromised agent already held.
Singapore's Model AI Governance Framework for Agentic AI. Launched by IMDA on 22 January 2026 at Davos and updated in June 2026, and described as the first governance framework written specifically for agentic AI, it organises guidance into four areas. Two bear directly on authority. The first asks organisations to bound the risks upfront, "such as setting limits on agent autonomy, tools and data access". The second asks them to make humans meaningfully accountable, including to "trigger human approvals at significant checkpoints, and regularly audit the effectiveness of such human approvals", explicitly to guard against automation bias.
NIST's work on agent identity and authorisation. On 5 February 2026 the National Cybersecurity Center of Excellence published a concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, with comments closing on 2 April 2026. It asks how agents should be identified, authorised and audited, how non-repudiation can be achieved, and how prompt injection can be prevented and mitigated. Its starting point is the gap described above: agents operating as anonymous automation under shared credentials rather than as identifiable entities.
The EU AI Act. The Act does not create a separate category for agents. Obligations attach to the use case, so an agent used in a high risk context carries the requirements of that context, including the human oversight requirements of Article 14 and the deployer duties of Article 26. What agents change is the practical difficulty of meeting them: oversight designed for a system that recommends is much harder to demonstrate for a system that acts. Our EU AI Act guide covers how those duties are allocated.
| Source | What it says about authority | Status |
|---|---|---|
| OWASP Agentic Top 10 | Tool misuse, identity and privilege abuse, and trust exploitation are named top risks | Published December 2025 |
| IMDA agentic framework | Bound autonomy, tools and data; approvals at significant checkpoints; audit whether approvals work | Voluntary, launched January 2026, updated June 2026 |
| NIST NCCoE concept paper | Agents as identifiable, authorised and auditable entities with non-repudiation | Concept stage, comments closed April 2026 |
| EU AI Act | No agent category; human oversight and deployer duties follow the use case | Binding, high risk obligations phasing in |
When human approval stops being a control
The default answer to agent risk is to keep a human in the loop. It is the right instinct and it fails in a predictable way. An approval prompt that appears dozens of times a day, for actions that are almost always fine, trains the person approving it to stop reading. Within weeks the approval is a click rather than a decision, and the organisation has a control on paper that does nothing in practice.
This is what the IMDA framework means by automation bias, and it is why its guidance goes beyond requiring approvals to requiring that their effectiveness be audited. Standing pre-approvals are the end state of the same process: the person stops approving each action and approves a whole class of actions once, permanently.
The test worth applying. An approval that is always given is not a control. It is a delay. If you cannot find a single occasion on which a given approval step was refused, you have no evidence that it would be refused when it matters. In our own endpoint scan the recorded number of denied requests was zero.
The fix is not more approvals. It is fewer, better placed ones: approvals reserved for actions where a person's judgement genuinely changes the outcome, with enough context in front of them to exercise it, and everything below that threshold handled by scope rather than by prompt.
A model for governing agent authority
Five controls, in the order they need to exist. Each maps to one of the three questions in the working definition: who delegated, within what limits, and where is the record.
| Action class | Examples | Default authority |
|---|---|---|
| Read only, internal | Search documents, read tickets, query a reporting database | Autonomous within scope |
| Reversible changes | Draft a document, open a pull request, create a ticket | Autonomous, logged and reviewable |
| Changes others rely on | Merge code, update a record of truth, change a configuration | Human approval, with the diff shown |
| External or irreversible | Send email outside the organisation, delete data, move money, change access | Human approval every time, never a standing grant |
The table is deliberately simple. Its value is less in the specific rows than in making the decision explicit and written down, so that "the agent was allowed to" becomes a question about a documented rule rather than about an accident of configuration.
Measuring whether your approvals work
Authority controls decay quietly, so they need measures that show decay. Five are cheap to collect and difficult to game.
Refusal rate. The share of approval requests that are denied or modified. A rate of zero over a long period means the step is ceremonial.
Time to approve. Approvals granted in a second or two were not read. Track the distribution, not the average.
Unattended share. The proportion of agent sessions that ran without a person approving each step. Rising unattended share with no change in policy is the clearest sign that authority is drifting.
Standing grant age. How long the oldest active pre-approvals, tokens and elevated modes have existed. Anything older than your review cycle has, by definition, escaped review.
Attribution coverage. The share of consequential agent actions that can be traced to a specific agent identity and a delegating person. Anything below full coverage marks where an incident review will stall.
A practical first sixty days
Frequently asked questions
Where this leaves you
Agents are useful precisely because they act without being asked at every step, so the goal cannot be to remove their authority. It is to make that authority deliberate: granted to an identity, scoped to a task, tiered by consequence, set to expire, and recorded with the person who delegated it. The organisations that manage agent risk well will not be the ones with the most approval prompts. They will be the ones that can answer, for any action an agent took, who authorised it and why.
Where a governance platform fits. Written tiers and delegation records are only useful if they are kept current across every agent in use. Keeping that register, mapping it to frameworks such as the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, and producing the evidence an auditor asks for is the work an AI governance platform such as Holistic AI is built to carry.
