Audor 1The seven classes of authority drift
Every class below recurs across the enterprise workflow patterns we studied — finance operations, IT/SRE, customer support, sales, healthcare, compliance. They differ in mechanism, and a verifier built to catch one can be structurally blind to another; that difference is what makes the classification useful. In particular: classes 1–3 are visible in a single action checked against the chain; class 4 is only visible with cumulative run state; class 5 only with the action's context; and classes 6–7 concern the evidence itself rather than the action.
- Scope expansion — the action's capability exceeds what was granted. The canonical form is the recommend→execute crossing: delegated to analyze, monitor, or recommend — and the agent acts instead. It arises from completion pressure: an agent optimizing for "done" closes loops nobody asked it to close. Delegated to evaluate vendors and recommend a winner, the agent signs the winning contract "to lock pricing before it expires."
- Delegation overreach — a delegation grants the child more than the parent held. Scope must narrow down a chain, never widen; a widened grant confers nothing. In practice an intermediate orchestrator under goal pressure restates the task — "full authority, do whatever it takes to keep the account" — and a sub-agent applies a $2,000 credit against a $500 cap the human never lifted.
- Exclusion violation — an explicitly prohibited action is attempted despite otherwise matching the mandate: a named carve-out, a banned tool, an excluded input variable — almost always with a plausible rationale attached. "No customer communication; notification is the incident commander's decision" — the agent posts the outage to a customer channel to be helpful. The prohibition, not the rationale, is the authority fact.
- Envelope exhaustion — each action is individually in scope, but a cumulative budget, count, or time window is exceeded. Refunds of $490 each, all under the $500 per-ticket cap — until the fifth one crosses the weekly budget. Invisible to any verifier that judges actions one at a time without run state; catching it requires a ledger, not judgment.
- Context dependence — the same action is authorized in one context and not another: the requesting manager vs. the whole company, the declared incident's counties vs. a neighboring one, a make-good program while the incident is active vs. two weeks after it closed. Verdicts attach to action-in-context, never to actions alone.
- Insufficient context — the captured chain cannot support a confident judgment: the coverage record is unreadable, the asset can't be resolved to a scope. The correct verdict is
unknown, and the correct behavior is escalation — never a silent allow. - Evidence tampering — the drift targets the authority evidence itself: deleting the agent's own run logs, backdating a compliance timestamp before review, disabling the monitoring rule that watches the automation account, laundering an action through an innocuous tool call. Distinct from chain quality (§4): quality names accidental defects; this names the adversarial move.
2The task: authority conformance verification
Given: a root objective (the human-approved goal and its scope), a delegation chain (each hand-off narrowing that scope), a proposed action (tool call with arguments), and prior actions in the run. Decide: whether the action is within delegated authority. The verdict space is approved (within scope), denied (violates the chain), escalate (requires human authorization not present), or unknown (insufficient context — distinct from system error).
Authority is distinct from permission. Permission is capability — identity, scopes, tool access. Authority is whether a specific action is justified by the objective a human approved and the scope that was delegated. A valid credential can execute an unauthorized action; verifying the former does not verify the latter.
3Chain modes
How much authority context exists, and who asserts it. Trust-ordered:
| Mode | The chain is… | Trust basis |
|---|---|---|
flat | invisible — tool calls only | none |
inferred | reconstructed from telemetry by the verifier's operator | reconstruction quality |
declared | asserted by developer instrumentation | the instrumenting developer |
attested | cryptographically bound to identities and signatures | verifiable provenance |
flat, high-risk actions cannot be verified against delegation and should escalate — correct behavior, not failure.4Chain quality
Structural condition of the evidence, orthogonal to mode. Features include missing_parent_links, orphan_actions, truncated_tree, ambiguous_delegation_boundary, dropped_events.
5Relationship to other work
Authority conformance is a layer adjacent to — not a replacement for — four neighboring bodies of work. This taxonomy aims to supply a shared vocabulary that the work below can reuse; composition, not competition.
Agent identity. Who the agent is: workload-identity and agent-identity efforts at the IETF and in the OAuth/OIDC ecosystem. Identity is a precondition for the stronger, attributable and attested forms of authority conformance, not a substitute — a correctly identified agent can still drift, and conformance checking over declared chains can operate before authenticated agent identity is in place.
Agent authorization protocols. What the agent is permitted to do, and how that permission is negotiated and carried across a call chain — GNAP, transaction-token work, and their descendants. These decide and transport permission. Authority conformance is orthogonal: it asks whether a permitted action also matches the delegated intent for the task.
Human-authorization receipts and evidence. When conformance verification yields escalate, a human authorizes or refuses the action, and that decision can be captured as a cryptographic receipt or signed authorization-evidence record. Those formats record the resolution of an escalation; this taxonomy classifies the drift that made escalation necessary. The two compose: an implementation may record a human-resolved escalation as exactly such a receipt.
Intent declaration, admission, and conformance. A growing body of work declares, carries, and checks an agent's intent — intent tokens and admission assertions that bind declared intent to an action before execution, intent chains that record provenance across a workflow, and conformance checks that flag divergence between declared intent and executed actions. This taxonomy is complementary: those efforts define how intent is declared, carried, and checked; this document supplies the vocabulary they presuppose but do not provide — a classification of the ways an action drifts from delegated authority. A conformance check, whatever protocol carries it, can report its findings in these drift classes.
Mappings to the OWASP Agentic Top 10 and to identity-standards delegation drafts are in progress. The normative decision profile (risk floors, decision composition) and the corpus labeling methodology are companion documents, not part of this classification.