Agent Authority Assurance: a working definition

Most conversations about governing AI agents stop at permission. An agent is given a role, a set of credentials, and a policy document, and the assumption is that this is what it means for the agent to be authorised. This briefing sets out a working definition of agent authority assurance, the discipline Zovent exists to advance, and explains why the definition has to reach further than the permission list.

Permission and authority are not the same thing

Permission is a property of a system. It describes what the technical configuration allows. Authority is a property of an organisation. It describes what the organisation actually intended, who approved it, and within what limits. The two overlap far less than most governance programmes assume.

A system can permit an action nobody ever intended to authorise. An organisation can authorise an outcome no system is configured to deliver. Both situations look perfectly normal on a dashboard, because dashboards report what happened, not what was allowed to happen.

Four layers, and the gaps between them

Declared authority is what the organisation formally states agents may do. Policies, mandates, approval matrices, delegated limits.

Delegated authority is what has actually been handed to a person, a team, or a system. Roles, scopes, credentials, budgets.

Technical authority is what the systems genuinely permit. What the finance platform, the cloud tenant, the payment infrastructure and the surrounding configuration would allow if an agent simply tried.

Exercised authority is what agents have actually done, action by action, in sequence.

When these four layers agree, an action can be traced from an organisational mandate, through the delegation that carried it, to the technical permission that allowed it, to the record of what was done. When they disagree, the disagreement is the exposure. The gap between declared and delegated is where good intentions go missing. The gap between delegated and technical is where unintended outcomes become possible. The gap between technical and exercised is where those outcomes are eventually discovered, usually by someone other than the organisation.

What assurance requires

Monitoring is not assurance. Monitoring reports what happened. Assurance is evidence that what happened was permitted by authority the organisation actually holds, produced independently of the system being checked.

Three properties matter. The evidence must come from outside the systems being assessed, so the system is never its own witness. It must connect a specific action back to a specific mandate, so a claim can be followed end to end. And it must be produced continuously, because authority that was valid last month says nothing about this month.

The working definition

Agent authority assurance is the discipline of independently verifying that every consequential action taken by an AI agent was carried out under authority the organisation actually intended to grant, and of holding that verification as evidence in a form that survives scrutiny outside the organisation.

The definition carries three commitments. The verification is independent, so the system being assessed is never its own witness. It is continuous, so a finding holds beyond the day it was checked. And it is portable, so the evidence can leave the organisation intact and still mean what it meant inside.

What it is not

It is not permission management, which answers what a system allows. It is not anomaly detection, which answers what looked unusual. It is not a policy document, which records what was intended. Each of these has value. None of them answers the question an auditor, an insurer, a regulator or a board will eventually ask: how do you know that action was authorised?

Find out where your own agents stand.