AI governance / Incident taxonomy

Break-of-Authority: A Distinct Incident Category for Agentic AI

EviState proposes break-of-authority for an evidenced act outside a defined authority envelope—distinct from a failure to establish what authority applied.

We have categories for security incidents, data breaches and system failures. As AI agents gain power to take consequential action, EviState believes authority incidents deserve equally explicit treatment.

An agent may be correctly identified. Its credentials may be valid. The request may pass every technical permission check. The system may behave exactly as designed. Evidence may still establish that the resulting action exceeded its authority envelope—or the organisation may discover that it cannot establish the applicable envelope at all.

That is not always adequately described as an authentication failure. It may not be an access-control failure. It is not necessarily a software fault, a model error or a conventional cyber intrusion. EviState proposes a practical framing that separates an evidenced break-of-authority from an authority-evidence failure.

Two cases that must not be collapsed

A break-of-authority is an evidenced act outside a defined authority envelope. The envelope is the recorded scope, purpose, target, value, duration, conditions and delegation limits that governed the action at the relevant time. Classification therefore requires evidence both of the applicable envelope and of the action that exceeded it.

An authority-evidence failure occurs where the organisation cannot independently establish what authority applied at the time. That is a governance and assurance failure, but it does not by itself prove that the agent acted outside authority. Later evidence may establish that the action was authorised, or may support classification as a break-of-authority.

An evidenced break can arise where an action:

  • was never within the mandate granted by an authorised delegator;
  • relied on a grant that had demonstrably expired, been revoked or changed;
  • exceeded a recorded purpose, target, value, jurisdiction or risk limit;
  • continued after an evidenced condition of authority was no longer true;
  • relied on a delegation that the defined authority model expressly prohibited.

If the applicable envelope itself cannot be established, the correct classification is authority-evidence failure—not an inferred break-of-authority.

Why explicit authority treatment helps

Security practice already distinguishes events by cause and consequence. A credential can be stolen. A vulnerability can be exploited. Data can be disclosed. A service can fail. A model can produce an unsafe or incorrect output.

Existing authorisation, access-control, policy-violation, compliance, delegation and insider-misuse classifications may capture parts of the problem. EviState is not asserting that related ideas or standards do not exist. The proposal is that authority deserves explicit treatment in agentic-AI governance because delegated action can cross people, agents, policies and systems while remaining technically permitted.

Consider a hypothetical autonomous procurement agent with permission to place orders. If evidence shows it bought from an approved supplier but exceeded the recorded value authorised for the current engagement, authentication may have worked and the procurement API may have enforced its configured access policy. The incident can nevertheless be classified as a break-of-authority because the action exceeded the evidenced business mandate.

Or consider an agent instructed by another agent to publish, transfer funds or alter infrastructure. A correctly attributed and verified signature can support origin and integrity. It does not, by itself, establish that the signer was authorised to approve the requested act.

The chain that must remain intact

A consequential agentic action should remain connected across four evidential layers:

A gap at any point should not be filled by assumption. Identity should not be promoted into authority. Technical permission should not be treated as a mandate. Where the historical envelope cannot be established, the result is an authority-evidence failure. Where evidence establishes that the action exceeded that envelope, the result is a break-of-authority.

Classifying the incident changes the response

If organisations treat break-of-authority and authority-evidence failure explicitly, incident response can ask better questions. Instead of examining only accounts, prompts, model outputs and logs, reviewers can identify the authority path on which the action relied and the evidence supporting the eventual classification.

A minimum incident record should establish:

  1. The consequential action: what changed, where and with what effect.
  2. The relying actor: the human, agent or system that executed or accepted the instruction.
  3. The asserted authority: the grant, approval, policy or instruction relied upon.
  4. The authority source: who or what purported to grant it, and their standing to do so.
  5. The applicable state: scope, limits, dependencies, expiry, revocation and relevant system state at the time.
  6. The classification basis: the evidence of an exceeded envelope, or the precise evidential gap that remains unresolved.
  7. The resulting state: what must be contained, reversed, corrected, disclosed or preserved.

These classifications identify different problems. Break-of-authority records an evidenced departure from the applicable envelope; authority-evidence failure records an unresolved governance and assurance gap. Neither classification decides whether the action was unlawful, negligent or substantively wrong. Those are separate judgements.

From retrospective evidence to preventative control

Evidence is valuable after an incident, but the stronger design objective is to detect a break before a consequential action is allowed to proceed.

For higher-risk workflows, a relying system could require evidence of a valid authority path, check that the grant covers the requested action and current state, and fail closed when a required dependency is missing or contradictory. The control design should be proportionate, with defined emergency and availability procedures rather than an assumption that every action needs the same approval path.

This is where authority evidence must meet enforcement. A record alone does not prevent execution. The system controlling the consequential action must be designed to use the evidence and refuse when the authority cannot be established.

The EviState position

ES Authority is EviState’s controlled-development work on making delegated digital authority inspectable. Its intended purpose is to preserve bounded evidence linking identity, authority, relevant state and consequential action—without pretending that evidence alone determines whether a decision was correct.

The proposed framing gives boards, security teams, auditors, insurers and regulators two disciplined questions to ask: does the evidence establish that the action exceeded its authority envelope; and, if not, can the applicable authority be independently established at all?

This is a pro-innovation position. Clear authority envelopes and proportionate evidence can let organisations delegate more confidently, distinguish proven breaches from unresolved assurance gaps and avoid treating every agentic action as inherently suspect. As agentic systems move from recommendation to execution, that discipline should become a standard part of both system design and incident review.

The question for debate

When an AI agent takes a consequential action, can your organisation prove the authority chain—or only show that the system had access?

About the author

Simon Wetton

Simon Wetton is the founder of EviState. He writes about accountable digital state, evidential continuity and the governance questions created by changing communications, publications and AI-enabled systems.

About Simon →
Return to EviState Insights