The Agentic Authority Model

How autonomous systems receive, carry, constrain, prove, and lose authority. Not permissions. Not RBAC. Not IAM. Authority.

  • Document: APQC-AUTH-006 — Authority Model
  • Status: Draft 0.1
  • Version: 0.1
  • Date: 2026-07-02
  • Editor / Authoring body: H33.ai, Inc.

This specification defines the Authority Graph — the answer to what is permitted? in the three-graph core. It is the part of the discipline that existing migration, IAM, and access-control frameworks do not address: not "is this request allowed" at an instant, but how a transferable, traceable, revocable right to act is rooted, delegated, constrained, proven, and withdrawn across autonomous systems and time. Written to stand alone and remain valid regardless of implementer.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

  • APQC-CORE-001 — Constitution. APQC-GLOSSARY-000 — Glossary.

0.2 Informative References

  • APQC-MODEL-003 — Conceptual Model. APQC-LIFECYCLE-004 — Lifecycle (Stage 4, Authority Assignment).
  • NIST SP 800-207 — Zero Trust Architecture (identity/authorization posture APQC extends).
  • APQC-EVIDENCE-007 (proves that action stayed within authority); APQC-ARCH-005; APQC-REFERENCE-010.

0.4 Conformance Dependencies

  • Depends on: APQC-CORE-001, APQC-GLOSSARY-000, APQC-MODEL-003.
  • Referenced by: APQC-EVIDENCE-007, APQC-ARCH-005, APQC-MATURITY-008, APQC-REFERENCE-010.

1. Purpose

When an autonomous system changes critical infrastructure, the governing question is not "who is it" or "is this request allowed right now," but "by what right does it act, from whom did that right come, how far does it extend, and can that be proven and revoked?" Existing frameworks answer adjacent questions and stop short of this one. This specification defines authority as a first-class, structured object so that an agent's right to act is explicit, bounded, traceable to a root, provable after the fact, and revocable at any time.

The distinction is not academic. An agent (GLOSSARY-000) does not have a career, a manager, a badge, or a conscience. It has exactly the authority delegated to it and nothing else. Where a human operator who exceeds their role can be counseled, an agent that exceeds its authority simply acts — at machine speed, across an entire estate, with no intuition to check it. The safety of governed autonomous transformation therefore cannot rest on the agent's good behavior (CORE-001 §9); it must rest on a structure that makes over-reach not merely disallowed but inconceivable — an action for which no path exists in the Authority Graph produces no effect and no evidence (CORE-001 P2; MODEL-003 I2). This document specifies that structure.

Three properties this model must deliver, that an access-control decision alone cannot:

  1. Traceability. Every right an agent holds MUST terminate upward at a verifiable origin. "The agent was allowed to" is never an acceptable answer; "the agent held authority A, delegated from B, delegated from Root R, within scope S, unexpired and unrevoked at time t" is.
  2. Durability. The right, its bounds, and its lineage MUST remain verifiable for the full evidence-retention horizon (years to decades), after the people, tools, and org charts that created it are gone.
  3. Provability. It MUST be possible, offline and after the fact, to reconstruct the exact authority that governed any past action and demonstrate that the action stayed within it — or that it did not.

Authorization frameworks give a yes/no at an instant and discard the reasoning. This model keeps the reasoning as a first-class, portable object.

2. What authority is not

Five distinctions are normative vocabulary for the discipline. Each is a well-known conflation in operational security, and each conflation reintroduces exactly the failure mode this model exists to prevent. They are stated first because the rest of the specification is unreadable without them: nearly every real-world authority incident is one of these five confusions wearing an incident number.

2.1 Identity ≠ Authority

Identity establishes who a party is. Authority establishes what it may do. The two are orthogonal: a party can be perfectly identified and hold no authority, and (in badly designed systems) a party can wield authority whose holder cannot be identified. A perfectly authenticated identity with no grant may perform no transformation (GLOSSARY-000). Knowing the actor is not permitting the act.

Worked contrast. A discovery agent (CORE-001 §7) and an execution agent may run under the same service identity in an estate — same certificate, same principal name. Identity cannot tell them apart. Authority must: the discovery agent's grants carry action ∈ {read, classify} and the execution agent's carry action ∈ {convert}. If the system reasons about identity where it should reason about authority, the read-only agent inherits the write-capable agent's reach the moment they share a principal.

Real-world failure. The confused-deputy class of bugs is precisely identity-conflated-with-authority: a component with a strong, trusted identity is induced to act on behalf of a caller who lacks authority, and the system authorizes on the deputy's identity instead of the originator's authority. The cure is not stronger identity; it is carrying the originating authority through to the action so the decision is made on the right's lineage, not the actor's name.

2.2 Authentication ≠ Authorization

Authentication proves an identity claim (GLOSSARY-000: a claim is not proof until attested and verifiable). Authorization decides a specific action. Passing authentication confers nothing operationally; it only makes the actor eligible to be considered. Authentication is a gate to the lobby; authorization is a decision at each door.

Worked contrast. An agent presents a valid credential and authenticates successfully at 09:00. At 09:05 it attempts to convert a production certificate. Authentication succeeded once; it says nothing about whether this action on this asset is permitted now. The two questions are answered by different mechanisms at different times, and coupling them ("authenticated, therefore allowed") is the defect.

Real-world failure. "Authenticated users can reach the admin endpoint" is the archetypal broken-access-control finding: authentication was treated as authorization. Every "any logged-in account could call the privileged API" breach is this conflation. In an agentic estate the blast radius is larger, because the "logged-in account" is a program that will exercise the privilege on every asset it can reach, without pausing.

2.3 Authorization ≠ Delegated Authority

Authorization is a decision at an instant — "may this action proceed?" — computed and then discarded. Delegated authority is a durable, transferable, revocable structure that an agent carries, can sub-delegate within limits, and that can be reconstructed later. Authorization is an answer; delegated authority is a graph (the Authority Graph, GLOSSARY-000). One is a value; the other is an object with lineage, bounds, and a lifetime.

Worked contrast. A classic authorization system, asked "may agent X convert asset Y at time t?", consults a policy, returns true, and forgets. Six months later an auditor asks "under what right did X convert Y?" and the system has nothing but a log line asserting it happened — no lineage, no bounds, no proof the grant existed. A delegated-authority system answers the same live question by finding a path in the graph, and answers the auditor's question by reconstructing that path (see §12, Authority Replay). The live decision and the historical proof are the same object viewed at two times.

Real-world failure. Instant-authorization systems that cannot answer "by what right" after the fact are the reason post-migration organizations "usually cannot produce independently-verifiable evidence of what was converted, when, by whom, and under whose authority" (CORE-001 §1). The decision was made and thrown away. Delegated authority is what makes the decision keepable.

2.4 Capability ≠ Permission

A permission is an entry in an external policy, looked up at access time by some reference monitor. A capability is an unforgeable grant that travels with the actor and names the exact right it confers. The difference is where the truth lives: for a permission, in a table the actor points at; for a capability, in the grant the actor holds.

APQC authority is capability-shaped — it moves with the agent, so an agent that has been quarantined or moved cannot regain reach by pointing at a policy table that still lists it. But bare capabilities historically lack three things APQC authority adds: provenance (a capability says what but not from whom, down what chain), revocation (bearer capabilities are notoriously hard to withdraw once handed out), and replay (a capability proves a present right, not a reconstructable past one). This model is capabilities plus the lineage, withdrawal, and historical-proof machinery that make them governable.

Worked contrast. A permission model says "check whether agent X is in the converters group before allowing convert." Remove X from the group and the next check fails — but only if the check happens, only if the table is consistent across regions, and only if nothing cached the earlier true. A capability model hands X a grant that is the right; X presents it and it is verified intrinsically. APQC adds: the grant names its delegator and root (provenance), can be revoked such that its whole subtree fails closed (§11), and can be reconstructed as-of any past instant (§12).

Real-world failure. Permission-table drift — an actor removed from a role in one system but still authorized by a stale replica or a cached decision elsewhere — is a standing source of over-privilege. Capabilities remove the table as the source of truth, but naive bearer capabilities replace it with a worse problem: an un-revocable token. APQC's contribution is to keep the capability's locality and make it revocable and provable.

2.5 Credential ≠ Authority

A credential proves a fact — an identity, an attribute, possession of a key. Authority grants an action. Holding a signing key is not the right to sign this change under this intent (GLOSSARY-000). This is the crux of the whole model, and it is where most systems silently fail:

A party that generates its own keys has valid signatures and zero authority.

Anyone can run a key-generation routine. The resulting key produces cryptographically valid signatures — they verify against the corresponding public key perfectly. But validity is a mathematical property of a signature relative to a key; it says nothing about whether the signer was permitted to make the statement it signed. Authority is what makes a signature legitimate, not merely valid.

Worked contrast. Two attestations cross an auditor's desk. Both are cryptographically valid ML-DSA signatures over the statement "production certificate C was converted to ML-KEM at 14:03." Attestation A was produced by an execution agent holding a grant traceable to the organization's Authority Root, scoped to exactly this action class on this asset class, unexpired and unrevoked at 14:03. Attestation B was produced by a party who generated their own keypair last night and signed the same sentence. Both signatures verify. Only A is authority-backed. A verifier who checks signature validity accepts both; a verifier who checks authority — does a path exist from a Root to this signer permitting this action at that time? — accepts only A. The entire discipline is the machinery for making that second check possible offline, years later (CORE-001 §9: "A signature proves a key signed; APQC evidence proves the signer was authorized to make that specific change").

Real-world failure. Self-signed trust anchors, rogue internal CAs, and "we found a service that was signing its own approvals" are all this conflation. The signatures were valid the entire time; nothing in the cryptography was broken. What was missing was the requirement that a signature be rooted in authority to be meaningful. A system that verifies signatures but not authority is protected against forgery and wide open to self-authorization — which, for an autonomous agent that can mint its own keys, is the whole attack.

Why five and not one. These are five faces of a single principle — the right to act is a distinct object from the actor, the actor's identity, the actor's momentary permission, and the actor's keys — but they fail differently and must be refuted separately. A system can get identity right and still be a confused deputy (§2.1); get authorization right at the instant and still be unauditable later (§2.3); use capabilities and still be un-revocable (§2.4); verify every signature and still trust a self-minted one (§2.5). The rest of this specification builds the one object — authority — that closes all five.

3. The Authority Root

All authority in a transformation descends from an Authority Root: a verifiable trust anchor that is the origin of the delegation chain. The Root is the answer to the regress "and who authorized them?" — it is where the chain of "delegated from" terminates. Without a Root, every grant is justified by another grant forever, or (worse) by nothing, and the fundamental question "by what right?" has no bottom.

A conforming system MUST have a Root that is:

  • (a) Independently verifiable — any verifier (CORE-001 §7) can confirm the Root's identity and that a given authority chains to it, offline, without contacting the issuer. A Root that can only be confirmed by asking the party that benefits from it is not a Root.
  • (b) Durable across the evidence-retention horizon — the Root MUST remain verifiable for the full retention period (years to decades; CORE-001 P7). Authority created today must be checkable long after the Root's operators have moved on. This is a post-quantum durability requirement: a Root whose signatures become forgeable within the retention horizon fails continuity (§10) retroactively — every authority beneath it becomes unverifiable at once.
  • (c) Non-forgeable and non-silently-replaceable — no party (including the Root operator) may substitute a different Root without the substitution being detectable. Silent Root replacement is the most dangerous failure in the model: it re-parents the entire graph under a new origin and, if undetectable, launders self-minted authority (§2.5) into apparently-rooted authority.

No authority exists that cannot be traced to a Root. An authority object presented without a verifiable path to a Root is not "less trusted" — it is un-rooted, and un-rooted authority is treated exactly as no authority at all (§13 anti-patterns; A1). There is no partial credit.

Rationale. The Root is what distinguishes this model from every "generate-your-own-keys" system (§2.5). Cryptographic validity is free; rootedness is the scarce property. By requiring that all authority terminate at a small number of durable, independently-verifiable anchors, the model makes the auditor's job tractable: to check that any action was authorized, verify one chain against one known Root, rather than reason about an unbounded web of self-asserted trust.

Edge cases. - Multiple Roots. An organization MAY operate more than one Root (e.g., one per legal entity or per regulatory boundary). Each authority chains to exactly one Root; there is no cross-Root inheritance. Two Roots means two graphs that never share a path. - Root rotation. A Root's anchor may need to change (algorithm deprecation, operational rotation). This MUST be done as an explicit, evidenced succession — a signed statement from the outgoing Root designating the incoming one — so that the chain of Roots is itself verifiable. Silent rotation violates (c). - Root compromise. If a Root is compromised, every authority beneath it is suspect. The model's response is mass revocation (§11) from the compromised Root down and re-issuance under a successor Root. This is catastrophic by design: making the Root the single point of trust means it is also the single point whose compromise is total — which is why (b) and (c) are non-negotiable.

(Reference implementation: APQC-REFERENCE-010.)

4. The Authority Graph

The Authority Graph (GLOSSARY-000; MODEL-003 §3.4) is the structure of all grants in force and their lineage. It answers "what is permitted?" — one of the three graphs (Knowledge / Authority / Evidence).

4.1 Formal structure

The Authority Graph is a directed acyclic graph (DAG):

  • Nodes are authorities (rights). Each node is an authority object (§5, §7) with a scope, a lifetime, provenance, and constraints. A distinguished set of nodes are Roots (§3), which have no incoming delegation edge.
  • Edges are delegations (GLOSSARY-000): a directed edge from authority P (the delegator's held authority) to authority C (the delegate's granted authority) asserting "P granted C." Every non-Root node has at least one incoming delegation edge; a node with none is un-rooted and invalid (§3).
  • Direction. Edges point from delegator to delegate — downward, away from the Root. "Upward" means toward the Root; "downward" means toward executing agents.
  • Acyclicity. The graph MUST be acyclic. A cycle would mean an authority is (transitively) its own ancestor, which makes provenance ill-defined and monotonic decrease (§7) meaningless. Delegation to a party who already holds ancestor authority creates a new, weaker node, never an edge back into the chain.
  • Leaves are the authorities actually held by executing agents. An action is taken by a leaf.

4.2 Path semantics — the permission question

For any prospective action, the Authority Graph is queried as a reachability-with-constraints problem:

Does a path exist from a Root to this agent such that, along the whole path, the action-on-asset is within the inherited scope, the current time is within every lifetime on the path, every inherited constraint is satisfied, and no edge or node on the path is revoked?

If such a path exists, the action is permitted. If no such path exists, the action is not merely denied — within the discipline it is inconceivable (CORE-001 P2; MODEL-003 I2): it cannot be attempted, produces no effect, and produces no evidence (GLOSSARY-000: no substrate is emitted for an action that never had authority). This is the fail-closed invariant (A5): the absence of a valid path is not an error condition to be logged — it is the normal, silent, effect-free outcome of an unauthorized attempt.

The distinction between "denied" and "inconceivable" is load-bearing. A denied action leaves a trace and a foothold; an inconceivable action leaves nothing an attacker can build on and nothing an auditor must sift. In an agentic system this matters because agents attempt many actions; only authorized ones may leave a footprint.

4.3 Intersection with the Knowledge Graph

The Authority Graph is distinct from the Knowledge Graph (MODEL-003 §3.3): the Knowledge Graph describes reality (what assets exist, what depends on them); the Authority Graph describes permission (what may be done, by whom, within what bounds). An action is possible only at their intersection — a knowledge-graph asset that is also reachable by an authority-graph grant. Authority over an asset that does not exist is inert; existence of an asset over which no authority is held is untouchable. The Evidence Graph (MODEL-003 §3.7) then records, at that intersection, what was actually done and under which authority — closing the loop between "permitted" and "proven."

4.4 ASCII: the Authority Graph, Root to agent

                         ┌─────────────────────┐
                         │   AUTHORITY ROOT R   │   trust anchor (§3)
                         │  (no incoming edge)  │   durable · verifiable
                         └──────────┬──────────┘
                                    │ delegation edge
                     ┌──────────────┼──────────────┐
                     ▼                              ▼
            ┌─────────────────┐            ┌─────────────────┐
            │  Authority B     │            │  Authority B'    │
            │  scope: convert  │            │  scope: read     │
            │  on estate/*     │            │  on estate/*     │
            │  ttl: 90d        │            │  ttl: 90d        │
            └────────┬────────┘            └─────────────────┘
                     │ delegation (subset)
                     ▼
            ┌─────────────────┐
            │  Authority C     │  scope: convert on estate/prod/tls-*
            │  ttl: 7d         │  constraint: no-op during freeze
            └────────┬────────┘
                     │ delegation (subset)
                     ▼
            ┌─────────────────┐
            │  Authority D     │  scope: convert on estate/prod/tls-eu-*
            │  (held by AGENT) │  ttl: 24h  ·  constraint: no-op during freeze
            └─────────────────┘            (+ human-approval if inherited)

  Query for "AGENT converts estate/prod/tls-eu-42 at time t":
  walk D → C → B → R. Path exists, scopes intersect to permit it,
  all lifetimes cover t, freeze constraint checked, nothing revoked ⇒ PERMITTED.

5. The authority object (a semi-formal model)

An authority is a structured object, not a role label or a policy row. This section fixes its fields neutrally — no product schema, no wire format (those are Not In Scope, §16). An implementation MAY name and encode these differently; it MUST represent the same information.

AUTHORITY (node in the Authority Graph)
├─ id                : opaque, unique, collision-resistant identifier of this grant
├─ root_ref          : the Authority Root this grant ultimately chains to (§3)
├─ parent_ref        : the delegating authority's id  (absent iff this node is a Root)
├─ holder            : the identity to which this authority is granted (the delegate)
├─ scope             : { action_class , asset_class }   ─ a WHITELIST, not a role (§6)
│                        action_class : e.g. {read} | {convert} | {read,classify}
│                        asset_class  : a bounded pattern over the estate,
│                                       e.g. estate/prod/tls-eu-*  (never "*")
├─ lifetime          : { not_before , not_after }        ─ a BOUNDED window (§6)
├─ constraints       : set of conditions binding this grant AND all sub-grants (§8)
│                        e.g. no-op-during-freeze ; human-approval-above-tier-N ;
│                             single-use ; max-blast-radius=K ; region-locked
├─ provenance        : ordered chain [Root … parent] with the delegating act at
│                        each hop (who, from what parent authority, when, under
│                        what added constraints) — verifiable, not asserted (§6)
├─ delegable         : whether the holder MAY sub-delegate (and if so, a cap on depth)
└─ revocation_ref    : how this grant can be checked for revocation status (§11)

Notes on the model. - scope is two classes, not two instances. Authority is issued over classes of action and asset so that it composes with the live, changing estate (MODEL-003 §3.1) without re-issuance per asset — but the classes MUST be bounded patterns, never wildcards that expand to "everything" (§13, over-broad grants). - provenance is the reified path to the Root. It is what makes an authority auditable rather than asserted: given the object, a verifier can reconstruct every hop and check each delegating act, without trusting the holder. - constraints and lifetime are the two independent tightening dimensions. Inheritance (§7) intersects scope and unions constraints; lifetime is intersected as a window. These are the only ways authority changes down the graph, and all three move in the tightening direction only. - The object carries everything needed to verify it (rooted, self-describing). It does not point at an external policy table to discover its own bounds — that would reintroduce the permission-drift problem (§2.4).

6. Authority properties: Scope, Lifetime, Provenance

Every authority MUST carry all three. Each is independently mandatory; an authority missing any one is malformed and MUST be rejected (A3).

6.1 Scope

Scope is the exact class of action and class of asset an authority permits. Scope is a whitelist, not a role label: an authority permits precisely what it names and nothing adjacent. "Administrator" is not a scope; {action: convert, asset: estate/prod/tls-eu-*} is.

Rationale. Role labels accrete meaning over time and across systems — the "operator" role gains a permission for one project and silently widens everyone's reach. A whitelist scope cannot widen by accretion: adding a right requires issuing a new, separately-traceable grant. This makes scope creep visible in the graph rather than hidden in a role definition.

Worked example. An agent holds {convert, estate/prod/tls-eu-*}. It attempts to convert estate/prod/db-eu-7 (a database, not a TLS endpoint). The asset does not match the scope pattern; no path permits it; the action is inconceivable. There is no "close enough" — TLS and DB are different asset classes, and the whitelist names TLS only.

Edge case — pattern precision. The asset_class pattern MUST be bounded and precise. estate/prod/tls-eu-* is bounded (EU production TLS). estate/* is not bounded — it is a wildcard grant and is an anti-pattern (§13). The precision of the pattern is the precision of the least-privilege claim.

6.2 Lifetime

Lifetime is a bounded validity window {not_before, not_after}. Authority without expiry is a defect. Standing, unexpiring authority MUST NOT exist (A3). Every authority is born already dying; it must be renewed by a fresh delegating act to persist, and that renewal is itself a new, evidenced node.

Rationale. Time is the cheapest revocation. Most over-privilege in real systems is not maliciously granted; it is left over — a grant that outlived the task, the project, the employee. A mandatory expiry converts every "forgot to clean up" into a "expired on its own." It also bounds the value of a compromised grant: a stolen authority is worth only its remaining lifetime.

Worked example. An agent is granted 24-hour authority to convert a batch. The batch finishes in six hours. Eighteen hours later a bug (or an attacker) tries to reuse the agent's grant. It is still valid — this is the residual-window risk, which is why lifetimes should be task-sized, not calendar-sized. Six hours after that, the grant expires; every subsequent attempt is inconceivable with no revocation action required. The lifetime did the cleanup that no human remembered to do.

Edge case — clock trust. Lifetime evaluation depends on a trusted time source. A grant that appears expired under one clock and valid under another is a race (§11.3). Conforming implementations SHOULD bind lifetime evaluation to the same trusted timestamp source used for anchoring (GLOSSARY-000), so that "was it valid at t" has one answer, checkable offline.

6.3 Provenance

Provenance is the full, verifiable lineage from Root to this grant: who delegated it, from what parent authority, when, and under what added constraints — every hop. Provenance is what makes authority auditable rather than merely asserted.

Rationale. An authority whose bounds are correct but whose origin cannot be verified is indistinguishable from a self-minted grant (§2.5). Provenance is the field that answers "and who authorized them?" all the way down to the Root. Without it, scope and lifetime describe a right that might have come from anywhere.

Worked example. An auditor is handed authority D held by an agent. Provenance lets them walk D → C → B → R, checking at each hop that the delegating act was itself within the delegator's authority and signed by the delegator. If any hop fails — a delegator that granted more than it held, a signature that does not verify, a missing parent — the whole chain is invalid, regardless of how well-formed D looks in isolation.

Edge case — provenance vs. privacy. Provenance names the delegating parties and grants, not necessarily the business content of the intent. The lineage is verifiable without exposing sensitive material (consistent with least exposure, MODEL-003 I3): a verifier confirms that authority chained correctly without needing to read what the underlying assets contain.

7. Delegation, delegation constraints, and inheritance

7.1 Delegation

Delegation (GLOSSARY-000) is the transfer of a subset of a holder's authority to another party, recorded as a directed edge in the Authority Graph. Delegation MUST be monotonic-decreasing: a delegate can never receive more scope, longer lifetime, or weaker constraints than its delegator holds (A4). A delegation that attempts to exceed its delegator is void, not merely disallowed — the resulting node is invalid and no path runs through it.

Rationale. Monotonic decrease is the single property that makes the graph sound: it guarantees that no leaf can hold effective authority that its Root did not permit. Without it, a mid-chain party could widen scope and the Root's grant would no longer bound the estate — the entire traceability guarantee (§1) would collapse at the first over-broad delegation.

7.2 Delegation constraints

Delegation constraints are conditions a delegator attaches that bind the grant and all downstream sub-delegations. Examples: "no production action during a freeze window," "human approval required above risk tier N," "single use," "max blast radius K assets," "region-locked." Constraints are inherited and MUST NOT be loosened downstream (A4). A delegator may add constraints; no delegate may remove one.

Rationale. Scope answers "what class of thing"; constraints answer "under what conditions." Some limits are not naturally expressible as scope narrowing — a freeze window is a temporal condition on an otherwise-in-scope action. Constraints are the mechanism for policy-shaped limits (GLOSSARY-000: policy constrains how authority is used) to ride down the delegation chain and bind every descendant.

7.3 Authority Inheritance — the math

Authority Inheritance governs how scope and constraints flow down the graph. The rule is exact:

A sub-authority's effective scope is the intersection of every ancestor's scope (from the Root down to and including itself). A sub-authority's effective constraints are the union of every ancestor's constraints. A sub-authority's effective lifetime is the intersection of every ancestor's lifetime window.

Intersection can only shrink; union of constraints can only tighten; intersection of windows can only narrow. Therefore effective authority is monotonically non-increasing along every path — the formal statement of §7.1. Consequently, the effective authority of any agent is computable from the graph alone, and no agent can hold effective authority its ancestors did not permit.

Worked multi-level example. Trace one agent's effective authority through three delegations:

ROOT R
  grants B :  scope  = {convert} × estate/*            (broad, at the top)
              ttl    = [Jan01 .. Apr01]   (90 days)
              constr = { }                (none yet)

B delegates C : scope  = {convert} × estate/prod/tls-*
                ttl    = [Feb01 .. Feb08]  (7 days)
                constr = { no-op-during-freeze }

C delegates D : scope  = {convert} × estate/prod/tls-eu-*
   (agent)      ttl    = [Feb03 .. Feb04]  (24 hours)
                constr = { human-approval-above-tier-3 }

EFFECTIVE authority of the agent holding D:

  scope   = ({convert}×estate/*)          intersect     ← from R
            ({convert}×estate/prod/tls-*) intersect     ← from B->C
            ({convert}×estate/prod/tls-eu-*)            ← from C->D
          = {convert} × estate/prod/tls-eu-*
            (the NARROWEST asset class on the path wins;
             action set intersects to {convert})

  ttl     = [Jan01..Apr01] ∩ [Feb01..Feb08] ∩ [Feb03..Feb04]
          = [Feb03 .. Feb04]      (24 hours — the tightest window)

  constr  = { }  ∪  { no-op-during-freeze }
                 ∪  { human-approval-above-tier-3 }
          = { no-op-during-freeze , human-approval-above-tier-3 }
            (BOTH bind the agent, even though R and B never
             mentioned tier-3, and C never mentioned tiers either
             beyond passing the freeze constraint down)

Read the result carefully. The agent holding D may convert only EU production TLS assets (intersection of scopes), only within a 24-hour window on Feb 3–4 (intersection of lifetimes), and only while honoring both the freeze constraint (added by B→C) and the tier-3 approval constraint (added by C→D) — the union of constraints. Even though the Root granted estate/* with no constraints, the agent inherits none of that breadth: intersection shrank the scope to EU prod TLS, and union accumulated two constraints the Root never imposed.

Edge cases. - Diamond inheritance (two paths to one node). If D is reachable from the Root by two distinct paths (delegated by two delegators), its effective authority is the union of what each path permits — an action is permitted if any valid path permits it. This is deliberate: multiple independent grants of a right are more permission, not less, and each path is independently revocable (§11). Care is required so that a diamond does not accidentally let a party recover, via a second path, scope that was deliberately narrowed on the first; auditors MUST evaluate all paths, and constraint checking is per-path. - Empty intersection. If two ancestors' scopes do not overlap (e.g., one grants read on TLS, another grants convert on DB, and a child tries to combine them into one grant), the intersection is empty — the child holds no effective authority. The graph does not error; the node simply permits nothing. - Constraint the ancestor cannot evaluate. A delegator MAY add a constraint (e.g., tier-3 approval) that a distant descendant, not the delegator, is positioned to enforce. Constraints ride down as obligations on the eventual action, evaluated at action time along the whole path; a descendant that cannot satisfy an inherited constraint simply cannot act.

7.4 ASCII: inheritance flow

              R  ── scope: convert × estate/*      ── ttl 90d ── constr {}
              │
   intersect  │  scope ↓ (can only shrink)         ttl ∩ (can only narrow)
              ▼  constr ∪ (can only accumulate)
              C  ── scope: convert × prod/tls/*     ── ttl 7d  ── constr {freeze}
              │
   intersect  ▼
              D  ── scope: convert × prod/tls/eu/*  ── ttl 24h ── constr {freeze, tier3}
             (agent)
                      EFFECTIVE = narrowest scope
                                  ∩ tightest window
                                  ∪ all constraints

8. Constraints as first-class limits

Constraints (§7.2) deserve separate treatment because they carry the limits that scope and lifetime cannot express, and because they are the mechanism by which organizational policy (GLOSSARY-000) becomes machine-enforceable authority rather than a document. A constraint is a predicate over the action context — the asset, the time, the estate state, the approvals present — that MUST evaluate true for the action to proceed, checked along the whole path (§7.3).

Representative constraint kinds (informative, not exhaustive):

  • Temporal — no production action during a declared freeze window; only within a change window. (Distinct from lifetime: lifetime bounds the grant's validity; a temporal constraint bounds when the action may fire within that validity.)
  • Approval-gated — human approval required above a risk tier; two-party approval for a class of asset. Ties agentic execution to human authorizers (CORE-001 §7) without giving the human standing authority.
  • Volume/blast-radius — at most K assets per unit time; halt on anomaly. Bounds the machine-speed risk that a human operator's pace naturally bounds.
  • Single-use — the grant is consumed by one action. Its own revocation, in effect (§11).
  • Locality — region-locked, tenant-locked. Prevents a grant valid in one boundary from acting across it.

Because constraints union down the graph and cannot be loosened, they are the safe place to put "and never, under any sub-delegation, do X." A Root or intermediate delegator that attaches a constraint knows it binds every descendant, forever, regardless of how the subtree is later delegated.

9. Authority Continuity

Authority Continuity is the requirement that authority survive the events that routinely break access control: personnel turnover, organizational restructuring, vendor change, tooling replacement, and the passage of years. A grant's meaning and lineage MUST remain verifiable after the humans and systems that created it are gone (A7).

Why access control fails here and authority must not. Conventional IAM state lives inside a running system, tied to live directories, current employees, and vendor software. When the employee leaves, the directory is migrated, or the vendor is swapped, the reasoning behind a grant is lost even if the grant's effect lingers — which is precisely how orphaned privilege accumulates. Continuity requires that the authority object be self-describing and self-verifying (§5): it carries its own rooted provenance, so its legitimacy does not depend on any live system still being able to explain it.

Worked example. Three years after a conversion, the organization has changed IAM vendors twice, the engineer who approved the grant has left, and the agent that acted was decommissioned. An auditor asks: "was the Feb-03 conversion of estate/prod/tls-eu-42 properly authorized?" With continuity, the answer comes entirely from the retained authority object and its provenance chain, verified offline against the (durable, §3b) Root that was in force then. Nothing living needs to be consulted. Without continuity, the honest answer is "we can't reconstruct that" — the exact gap CORE-001 §1 identifies.

Relationship to Evidence. Continuity is the authority-side counterpart to evidence portability (CORE-001 P7). The Evidence Graph records that an action occurred and under which authority; continuity guarantees that the authority itself remains verifiable for as long as the evidence does. Evidence that binds to an authority which can no longer be verified is only half-provable.

10. Authority Replay

Authority Replay is the operation of reconstructing the exact state of the Authority Graph as it existed at any past moment — the full set of grants, constraints, and revocations in force when a given action occurred. Replay turns authority from a live permission check into historical, provable fact. It answers "was this agent, at that instant, actually permitted to do this, and by whom?" deterministically and offline (A8). Authority Replay is the authority-side counterpart to Evidence Replay (APQC-EVIDENCE-007).

10.1 What "deterministic and offline" requires

Replay MUST yield the same answer every time, computed from retained data alone, with no call to any live service. That imposes design obligations:

  • The graph MUST be reconstructable as-of a timestamp — every node, edge, constraint, lifetime, and revocation carries the time it took effect, so the graph can be "rewound" to time t.
  • All inputs to the permission decision (§4.2) MUST be retained: the authority objects on the path, their provenance to the Root, the Root's anchor as-of t, the revocation status as-of t, and the constraint-evaluation inputs (e.g., whether a freeze was in effect at t).
  • The decision function MUST be pure: same inputs ⇒ same output. No dependence on current system state, current clock, or current policy tables.

10.2 Step-by-step reconstruction

Auditor question: "Under what authority did the agent convert estate/prod/tls-eu-42 at t = Feb-03 15:00?"

Step 1  Locate the action's evidence (Evidence Graph, EVIDENCE-007). It names the
        acting authority id = D and the timestamp t.

Step 2  Rewind the Authority Graph to t. Retrieve authority D as-of t:
          scope = convert × estate/prod/tls-eu-*   ttl = [Feb03..Feb04]
          constr = {freeze, tier3}  parent = C

Step 3  Walk provenance upward, each node as-of t:
          D --parent--> C  (scope convert×prod/tls-*, ttl [Feb01..Feb08], constr {freeze})
          C --parent--> B  (scope convert×estate/*,  ttl [Jan01..Apr01], constr {})
          B --parent--> R  (Authority Root; no parent)

Step 4  Verify each delegating act as-of t:
          - R→B, B→C, C→D each signed by the delegator, signature verifies
          - each child's scope ⊆ parent's scope        (monotonic decrease held)
          - each child's ttl  ⊆ parent's ttl
          - each child's constr ⊇ parent's constr       (constraints only added)

Step 5  Verify the Root as-of t: R's anchor is the Root in force on Feb-03,
        durable and independently verifiable (§3). Chain terminates at R. ✔ rooted.

Step 6  Recompute effective authority at t (the §7.3 math):
          scope = convert × estate/prod/tls-eu-*   (intersection)
          ttl   = [Feb03..Feb04]  ⊇ t=Feb03 15:00  (in window ✔)
          constr= {freeze, tier3}

Step 7  Check revocation as-of t: no node on path D→C→B→R was revoked at or
        before t. ✔  (Had C been revoked at Feb03 14:00, this step FAILS closed
        and the conclusion flips to "NOT authorized at t".)

Step 8  Evaluate inherited constraints against the retained action context at t:
          freeze : no freeze in effect on Feb-03 ✔
          tier3  : the action carried a tier-3 human approval token, retained ✔

Conclusion: the conversion of estate/prod/tls-eu-42 at Feb-03 15:00 was
authorized under authority D, rooted at R via C and B, within scope, within
lifetime, unrevoked, and constraint-satisfying. Proven offline, deterministically,
from retained data alone — reproducible by any verifier, years later.

The same procedure, run against a self-minted attestation (§2.5), fails at Step 5: the chain does not terminate at a verifiable Root. The signatures verify at Step 4 in isolation, but there is no rooted path — so the action was never authorized, and replay proves it.

11. Revocation

Any authority MUST be revocable by an appropriate ancestor at any time, and revocation MUST propagate to all descendants immediately and verifiably (A6). A revoked authority path fails closed for all future actions. Revocation MUST be evidenced (APQC-EVIDENCE-007) so that, after the fact, it is provable both that an authority was revoked and when — closing the window in which a compromised or over-broad grant can act.

11.1 Who may revoke, and what propagation means

Revocation is authorized from above: an ancestor may revoke any authority in its subtree (a Root may revoke anything beneath it; an intermediate delegator may revoke what it delegated and everything downstream of that). Revoking a node revokes, transitively, every descendant — because a descendant's authority is derived from the revoked node's, cutting the parent invalidates the whole subtree at once. This is inheritance (§7.3) running in reverse: as scope and constraints flowed down, revocation flows down from the cut point.

11.2 Propagation walkthrough

Before revocation:                    Revoke C (freeze violation discovered):

        R                                     R
        │                                     │
        ▼                                     ▼
        B ──► B'                              B ──► B'      (B' UNAFFECTED —
        │                                     │              not in C's subtree)
        ▼                                     ▼
        C                                     C  ✗ REVOKED at t_rev
        │                                     │
        ▼                                     ▼
        D  (agent)                            D  ✗ revoked-by-inheritance
        │                                     │
        ▼                                     ▼
        E  (sub-agent)                        E  ✗ revoked-by-inheritance

Effect: at t_rev, the entire subtree rooted at C (C, D, E) fails closed.
Any action by D or E at or after t_rev finds NO valid path (§4.2) ⇒ inconceivable,
no effect, no evidence. B' and its subtree are untouched — revocation is scoped to
the cut point's descendants, never siblings or cousins.

Propagation is immediate (effective at t_rev, not at the next lease renewal) and verifiable (a verifier can later confirm the revocation's existence and timestamp from evidence). "Immediate" is a semantic requirement, not merely an implementation goal: replay (§10, Step 7) MUST treat any action at or after t_rev on the revoked subtree as unauthorized, regardless of what any live cache believed at the time.

11.3 Race conditions revocation MUST handle

Revocation is where the model meets distributed-systems reality, and it must be specified against the races, not around them:

  • In-flight action vs. revocation. An action is decided-permitted at t₀ and revocation lands at t₁ > t₀ while the action is executing. The model's rule: authority is evaluated at the moment of the transformation's effect, and if that moment is at or after t_rev, the action is unauthorized. Implementations SHOULD make the authority check and the effecting of the change atomic (or make the change reversible, CORE-001 P5) so that a revocation cannot be straddled. A substrate MUST NOT be emitted for an action whose authority was revoked before its effect committed.
  • Revocation-propagation lag vs. lease validity. A distributed estate may not learn of a revocation instantly. The model requires that the authoritative record mark the authority revoked as-of t_rev; any node that acted after t_rev on the strength of stale local state acted without authority, and replay will (correctly, fail-closed) judge it unauthorized. This is why lifetimes SHOULD be short (§6.2): a short lifetime bounds the maximum staleness window even if propagation lags, so revocation and expiry converge.
  • Clock skew at the revocation boundary. If t_rev and the action timestamp are measured on skewed clocks, an action might appear before-or-after the cut ambiguously. The model resolves ambiguity conservatively (fail closed): at the boundary, an action whose ordering relative to t_rev cannot be established as strictly-before is treated as after. Binding both timestamps to a common trusted source (§6.2) removes the ambiguity for the audited record.
  • Revoke-then-reissue confusion. A revoked authority id MUST NOT be reused. Reissuing under the same id would make replay ambiguous ("was this the pre- or post-revocation grant?"). A replacement grant is a new node with a new id and its own provenance.

11.4 Revocation as evidence

A revocation is itself a governed act and produces evidence. This means the absence of a revocation is also provable: replay can show that no revocation of the path existed at or before t, which is what licenses the "authorized" conclusion in §10.2 Step 7. Un-evidenced revocation is not conforming — an unprovable "we revoked it" is worth nothing to an auditor and cannot close the compromise window with certainty.

12. Failure cases and anti-patterns

Each anti-pattern below is a real, common way access-control systems break, and each is precisely the thing one requirement of this model forbids. They are collected here so that a reviewer can check a candidate system against known failure shapes.

  • Standing authority. A grant with no expiry that simply persists. Why it breaks the model: it is the leftover-privilege engine — authority that outlives its task, its project, its holder, and its intent, waiting to be found by an attacker or a bug. Forbidden by A3 (Lifetime mandatory; standing authority MUST NOT exist).

  • Over-broad grants. scope = * or estate/* "to be safe" or "to avoid re-issuing." Why it breaks the model: it makes least-privilege a fiction; the intersection math (§7.3) can only shrink from the top, so a wildcard at or near the Root poisons every descendant's ceiling. A broad grant is not a convenience; it is the widest blast radius in the graph. Constrained by A3/A4 (bounded scope; monotonic decrease can only help if the top is already tight).

  • Authority that outlives intent. A grant issued for a specific intent (GLOSSARY-000) that remains valid after that intent is satisfied or abandoned. Why it breaks the model: authority is meaningful only relative to the intent it serves (CORE-001: intent is "the root from which all downstream authority derives"). A grant divorced from a live intent is authority in search of a use — the definition of latent over-privilege. Mitigation: task-sized lifetimes (§6.2) and single-use constraints (§8) bind authority to intent's lifespan.

  • Un-rooted authority. A grant presented without a verifiable path to an Authority Root. Why it breaks the model: it is indistinguishable from a self-minted grant (§2.5) — valid signatures, zero legitimacy. Accepting it defeats the entire point of §3. Forbidden by A1 (every authority MUST root; no un-rooted authority exists). Treated as no authority, not weak authority.

  • Delegation that widens scope. A mid-chain party granting more scope, longer lifetime, or weaker constraints than it holds. Why it breaks the model: it breaks soundness — the Root no longer bounds the leaves, and traceability (§1) becomes a lie the moment one hop cheats. Forbidden by A4 (monotonic-decreasing; a widening delegation is void, and no path runs through a void node).

  • Revocation that doesn't propagate. Cutting a node while its descendants keep acting on cached or lease-held authority. Why it breaks the model: it leaves the compromise window open exactly when it must be closed. A revocation that stops at the cut point but not the subtree is not a revocation. Forbidden by A6 (propagating, immediate, evidenced) and enforced at replay (§10 Step 7; §11.3 races).

  • (Corollary) Authorization without retention. Deciding permission at an instant and discarding the reasoning (§2.3). Why it breaks the model: it satisfies the live check and fails every later "by what right?" — the audit gap CORE-001 §1 names. Forbidden by A8 (replayable) and A7 (continuity).

13. Implementation notes (informative)

Neutral guidance on realizing the model. Nothing here is normative; it names the shapes that satisfy §§3–11, not any product (Not In Scope, §16).

  • Anchoring a Root durably. Bind the Root's public trust anchor to an independent, tamper-evident record (an anchor, GLOSSARY-000) so its existence-at-a-time is confirmable without trusting the Root operator. Use post-quantum signature families for the Root so that (§3b) durability holds across the retention horizon; using multiple independent families protects against the failure of any one (cf. CORE-001 §8). Root succession (§3 edge case) is itself an anchored, signed statement so the chain of Roots is verifiable.

  • Representing delegation. Represent each delegation as a signed statement by the delegator binding: parent authority id, child scope/lifetime/constraints, holder, and timestamp — i.e., the §5 object minus what is inherited. Because the object is self-describing and rooted, verification needs the object and the Root, not a live policy service. Storing the graph as append-only, timestamped nodes/edges is what makes as-of-t rewind (§10.1) mechanical rather than reconstructed by guesswork.

  • Propagating revocation. Two composable techniques: (1) short lifetimes (§6.2) so unrevoked-but-stale authority self-heals by expiry, bounding propagation lag; (2) an authoritative, timestamped revocation record that replay consults as-of-t, so the audited answer is correct even if a live cache was briefly stale. The record MUST be evidenced (§11.4). Fail-closed on inability to determine revocation status: unknown ⇒ not authorized.

  • Making replay deterministic. Keep the permission-decision function pure and version it; retain every input (path objects, provenance, Root-as-of-t, revocation-as-of-t, constraint-context) alongside the evidence for the action. Never let replay read current state. Bind lifetime, revocation, and action timestamps to one trusted time source so ordering questions (§11.3) have a single offline answer. Determinism is a property you design in by retention and purity, not one you add later.

14. Relationship to Zero Trust, IAM, and capabilities (informative)

This model does not replace identity, access management, or capability systems; it sits above them and supplies what they structurally lack for autonomous, long-lived, provable transformation.

  • Zero Trust (NIST SP 800-207). Zero Trust establishes never trust, always verify and per-request authorization against live policy and signals. It answers "should this request, from this authenticated principal, be allowed right now?" extremely well. What it does not provide: a transferable, sub-delegable, rooted right that an agent carries; and durable, offline, after-the-fact proof of the right that governed a past action. Zero Trust is a runtime posture; authority is a persistent, portable object. APQC extends the Zero Trust posture (CORE-001 §12) by making the "verify" leave behind a replayable authority record, not just a momentary allow.

  • IAM / RBAC / ABAC. These manage who holds what role/attribute and evaluate permissions (§2.4) against those at access time. Their state is live, system-bound, and role-shaped — which is exactly why it suffers scope creep (roles accrete), permission drift (stale replicas), and continuity loss (state dies with the vendor). Authority differs on three axes: whitelist scope not roles (§6.1); rooted, self-describing provenance not a live directory (§6.3, §9); and replayable history not discarded decisions (§10). IAM answers "is this principal permitted"; authority answers "by what right, from whom, provably, and can it be withdrawn."

  • Object-capability systems. Capabilities give the crucial property authority keeps — the right travels with the actor, unforgeable, checked intrinsically (§2.4). What classical capabilities lack, and this model adds: provenance to a Root (a capability names a right, not its origin), revocation that propagates through a subtree (bearer capabilities are famously hard to revoke, §11), and replay (a capability proves present possession, not a reconstructable past). APQC authority is best read as capabilities made rooted, revocable, and replayable.

The one-line summary. Identity says who; authentication proves who; authorization decides now; capabilities carry the right; Zero Trust verifies each request. Authority adds the missing spine: a rooted, bounded, delegable, revocable, and replayable right to act, provable offline for the life of the evidence. That spine is what autonomous systems need and what the adjacent frameworks were never built to provide.

15. Normative requirements

A conforming Authority Model implementation:

  • A1. MUST root every authority in a verifiable Authority Root (§3); no un-rooted authority exists. Un-rooted authority MUST be treated as no authority.
  • A2. MUST represent authority as an acyclic graph whose every path is traceable Root-to-agent (§4), with scope, lifetime, provenance, and constraints bound to each node (§5).
  • A3. MUST bind Scope, Lifetime, and Provenance to every authority (§6); MUST NOT issue unexpiring or standing authority; MUST express scope as a bounded whitelist, never a wildcard or a role label.
  • A4. MUST enforce monotonic-decreasing delegation and inherited constraints (§7): a delegation exceeding its delegator is void; scope intersects, lifetime intersects, and constraints union down every path.
  • A5. MUST fail closed on any action lacking a valid path, producing no effect and no evidence (§4.2; CORE-001 P2).
  • A6. MUST support immediate, propagating, evidenced revocation over the whole descendant subtree of the revoked node (§11), and MUST resolve revocation-boundary ambiguity conservatively (fail closed).
  • A7. MUST preserve authority continuity across turnover, org change, vendor change, and time, such that any past grant remains verifiable offline from the authority object and its rooted provenance alone (§9).
  • A8. MUST support deterministic, offline Authority Replay of any past graph state (§10), yielding the same permission conclusion every time from retained data alone.

15.1 Conformance tests

Each test is checkable and phrased Given/When/Then. A conforming implementation MUST pass all of them.

  • CT-A1 (rooting). Given an authority object with no verifiable path to any Authority Root; When it is presented for an action; Then the action is refused as if no authority were presented — no effect, no evidence — and replay of the attempt shows "un-rooted, not authorized."

  • CT-A2 (traceable graph). Given any authority held by an agent; When a verifier requests its lineage; Then the verifier can walk a single acyclic path from the agent's authority to a Root, with scope/lifetime/provenance/constraints available at every node, offline.

  • CT-A3a (mandatory expiry). Given an attempt to issue an authority with no not_after; Then issuance is rejected as malformed. CT-A3b (no wildcards/roles). Given an attempt to issue an authority whose scope is *, estate/*, or a bare role label; Then issuance is rejected (or, if an organization explicitly permits estate-wide grants at a Root, that grant is flagged and its breadth is visible in every descendant's replay).

  • CT-A4a (no widening). Given a delegator holding scope convert × prod/tls-eu-*; When it attempts to delegate convert × prod/tls-* (wider) or a longer lifetime or a removed constraint; Then the resulting node is void and no path runs through it. CT-A4b (inheritance math). Given the three-level chain of §7.3; When effective authority of the leaf is computed; Then it equals scope = convert × estate/prod/tls-eu-*, lifetime = the tightest window, constraints = {freeze, tier3} (intersection of scope/lifetime, union of constraints).

  • CT-A5 (fail closed). Given an agent whose scope does not cover asset Y; When it attempts a transformation on Y; Then the transformation does not occur, Y is unchanged, and no substrate is emitted for the attempt.

  • CT-A6a (subtree propagation). Given the graph R→B→C→D→E and a sibling B→B'; When C is revoked at t_rev; Then every action by C, D, or E at or after t_rev finds no valid path, while B' and its subtree are unaffected. CT-A6b (in-flight race). Given an action decided-permitted at t₀ and revocation at t₁ > t₀ landing before the action's effect commits; Then the effect does not commit and no substrate is emitted. CT-A6c (evidenced). Given a completed revocation; When replay is run for an action at or after t_rev; Then the revocation and its timestamp are provable from retained evidence, and the conclusion is "not authorized."

  • CT-A7 (continuity). Given an authority created years ago, whose issuing employee, IAM vendor, and acting agent are all gone; When an auditor asks whether a past action under it was authorized; Then the answer is derivable offline from the retained authority object and its rooted provenance alone, without any live system.

  • CT-A8 (deterministic replay). Given the retained inputs for a past action; When Authority Replay is executed twice, independently, offline; Then both runs reconstruct the identical as-of-t graph state and reach the identical permission conclusion.

  • CT-A8b (self-minted rejection). Given a cryptographically valid attestation signed by a self-generated key with no rooted delegation; When replay is executed; Then signature verification succeeds in isolation but the chain fails to terminate at a verifiable Root, and the conclusion is "never authorized."

16. Reference implementation

The reference implementation of this model roots authority in a durable post-quantum trust anchor, gates every governed action on a valid delegated grant (an out-of-scope action yields no result and no attestation), and binds each resulting evidence object to the authority under which it occurred — so that authority and evidence are two views of one fact. Delegation is recorded as signed, timestamped, monotonic-decreasing grants; revocation propagates through the descendant subtree and is itself evidenced; and Authority Replay reconstructs any past graph state deterministically and offline against the Root in force at that time. See APQC-REFERENCE-010. This section is informative; the model above is normative and implementation-independent.

17. Not In Scope

This specification does not define: authentication mechanisms or identity proofing (prerequisites, not authority); specific IAM/RBAC/ABAC products; cryptographic algorithms, signature schemes, or key formats; wire formats, encodings, or APIs; the durable-anchor or ledger technology used for a Root; or organizational approval workflows (which consume this model — e.g., as inherited constraints — but are not it). It defines what authority is, the object that represents it, the graph it forms, and the invariants it must satisfy — not how any product implements them.