AI delegation is a person letting software act on their behalf, within limits, and sometimes letting that software hand part of the work to other software. This page defines the vocabulary used across this site and maps it to the public names used by the Authority engine.

A simple example

  1. Human → agent. A person lets a purchasing agent create purchase orders up to 1,000 EUR until the end of the year. Orders above 100 EUR need the person’s explicit approval.
  2. Agent → sub-agent. The purchasing agent hands a narrower slice to a sub-agent: orders up to 300 EUR, until the end of November.
  3. Sub-agent → action. The sub-agent asks a supplier system to create a 250 EUR order.
  4. The question. Before acting, the supplier system needs to know whether an unbroken chain of authority, running back to that person, covers this exact action at this moment, and whether the required approval exists.

Everything below names a part of that question.

The actors

Human principal

The person whose authority is ultimately being exercised. In Authority, a chain can only reach AUTHORIZED if it goes back to a root delegation whose grantor is marked HUMAN_ROOT. A chain rooted in an agent has no established human origin and is UNKNOWN.

Agent

Software acting for a principal under a delegation. An agent receives authority; it does not own it.

Sub-agent

An agent that received its authority from another agent through a sub-delegation (SUBDELEGATION_CREATED). The delegating agent must itself have been allowed to delegate (can_delegate).

Relying party

The system that must decide whether to carry out the requested action: a payment API, a supplier system, an internal service. It is the party asking the question. Authority is a tool that can answer it; the relying party remains responsible for acting on the answer.

Four questions that are often confused

Identity

Who or what an actor is. Authority V0 handles principals as opaque identifiers; it does not establish who stands behind them.

Authentication

Proof that a request really comes from a given identity. This is outside V0: the host supplies authenticated identities, and every event is marked ASSERTED_UNVERIFIED.

Authorization

Whether this actor may perform this action, with these parameters, at this point. Authority answers with one of four outcomes: AUTHORIZED, DENIED, REQUIRES_APPROVAL or UNKNOWN.

Delegation

How authorization passes from one principal to another, with limits attached. Delegation explains where an authorization comes from; it is the chain the engine reconstructs.

Limits carried by a delegation

Scope

What a delegation covers. In V0 a capability is an exact (resource, action) pair: no wildcard and no implicit inheritance (invariant I9). Monetary limits such as max_amount are part of the scope.

Attenuation

A sub-delegation can only narrow its parent. On every dimension (capabilities, can_delegate, expires_at, amount limits, total_budget) the child must be equal or stricter. Widening a single dimension makes the sub-delegation invalid; it is never silently truncated (I5).

Approvals

Above an automatic threshold and up to an approval ceiling, an action needs an explicit human approval (APPROVAL_GRANTED). Without one, the outcome is REQUIRES_APPROVAL. An approval is consumed by a single execution (I16).

Action-instance binding

An approval covers exactly the action that requested it, identified by its action_id and by its exact fingerprint (I6). A second action with the same capability and parameters is a different instance and gets nothing from that approval. The first article examines this rule in detail.

Budgets

total_budget caps the cumulative amount spent by executions under a delegation and its descendants. In V0, concurrent decisions can overspend a shared budget; the overspend is reported after the fact, not prevented (see limits).

Expiry

expires_at is compared with a trusted clock assigned at ingestion (authority_time), never with a timestamp declared by the source. The boundary instant counts as expired (I4).

Revocation

An authorized DELEGATION_REVOKED invalidates, from its position in the log onward, every descendant that depends only on the revoked delegation. A revocation issued by someone without the right to revoke has no effect (I7, I13).

Three views of authority

This site uses three words, AVAILABLE, INVOKED and RECORDED, to explain which question an answer belongs to. They are editorial vocabulary, also used in the repository’s code comments, not an external standard. Each corresponds to public names in the engine.

Fingerprint-scoped available authority: AVAILABLE

Would some valid chain held by the agent authorize this capability with these parameters (the action fingerprint) at this point? Any matching, unconsumed approval may count, including one bound to a different action_id. Public names: authorityAt, and currentAuthority and execution.authorityAtDecision in explainAction.

Invoked authority: INVOKED

Anchored on the delegation named by the action itself (ACTION_REQUESTED.delegation_id): would that delegation alone authorize this specific action instance? Public names: invokedAuthorityNow and execution.invokedAuthorityAtDecision.

Recorded chain validation: RECORDED

Does the chain recorded by the execution (ACTION_EXECUTED.authority_chain_ref) validate this action at its decision point? Public name: execution.recordedValidation.

Evidence and history

Authenticity of evidence versus validity of authority

Two separate questions. Validity: taken as given, do the logged events form a chain that covers the action? Authenticity: were those events really issued by the principals they name? Authority V0 answers the first only. It has no signatures; an AUTHORIZED outcome means the log contains uncontradicted events asserting a chain of grants, not that any grant was cryptographically proven.

Historical evaluation

Every evaluation is made at an explicit position in the log (atSequence) and an explicit trusted instant (authorityTime). An executed action is also re-evaluated at its own decision point. Because the log is append-only (I3), an action that was authorized when it ran stays authorized at that point, even after its authority is later revoked or expires.

What Authority addresses

  • Deterministic reconstruction of a delegation chain from an append-only event history, from human root to action.
  • Four distinct outcomes, with UNKNOWN as the fail-closed default when evidence is missing or ambiguous (I1).
  • Explanations that separate the available, invoked and recorded views of an action.

What Authority does not address

  • Identity, authentication or signatures: every event is ASSERTED_UNVERIFIED.
  • The intent or content of an action: the engine checks the formal authority chain, not whether the action is wise.
  • Prevention of concurrent budget overspend, protection against a privileged database writer, or any production-scale performance claim.

The complete list is on the limits page.

Read further