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 authority conformance, not a substitute — a correctly identified agent can still drift.
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.