This is the handbook’s vocabulary: one table, A to Z. Each entry is one to three sentences and links the part that defines it, because the entries are written to be quoted and the canonical homes carry the argument. If you are meeting the model for the first time, do not start here. Start at the cover, whose reading order teaches these terms in the order the architecture runs, and come back when you need one.
| Term | Meaning |
|---|---|
act chain | The RFC 8693 actor chain. A delegated token carries the same mission claim with subset authority. The chain is actor lineage, not authority lineage: it records who acted through whom, and it does not prove what task was approved, how authority narrowed at each derivation, whether the task is still active, or which parameter constraints bind. Those travel in the Mission’s own constructs, the anchors, the Authority Set, the lifecycle state, and Child Mission lineage. Reading an actor chain as authorization provenance is the gap Mission lineage exists to close. |
| Action-bound approval | A fresh human decision demanded for one concrete action with its final parameters, independent of the Mission’s original approval (the high-assurance level). |
| Agent Deployment | The approved behavioral version of an agent (code, model, system prompt, tool allowlist, data scope, runtime configuration), owned by change governance and pinnable through the core’s OPTIONAL controls.agent_deployment. The Deployment (the client_id, in the OAuth binding) is the class-grain authorization subject and the instance is the attribution subject: a Mission pinned to the class may be executed by many attested instances at once, bounded by max_derivations and Mission-grain consumption, with per-instance keys keeping the record attributable. Distinct from the Mission Deployment Profile, the estate’s published claims manifest. Not to be confused with the Mission Deployment Profile, the spec family’s composition document naming which profiles a deployment runs. |
| Agent instance | The concrete running process, identified by its own key and, where deployed, an attester-minted identifier that survives rotation. The attribution grain, never the authorization grain. |
| Agent Registry | The enterprise record of logical Agents and instances: owner, status, risk tier, and approved Deployment association. A derivation input, never a grant. |
| Approval event | The AS validates the Intent and derives the Authority Set, the Approver consents to the rendered Intent + derived Authority Set, and the AS commits the anchors and creates the Mission active, atomically. |
| Attestation | Runtime evidence about the instance and its key, consumed by the registry rather than replacing it. Strength runs in tiers, from measured environments to contractual assertion, and a deployment names which tier it relies on. |
| Authority | The capacity to cause consequential effects, held as typed, bounded, resource-specific entries rather than as ambient permission. In this model authority is always derived from an approved task, never asserted by a client or inferred by a model. |
| Authority ceiling | The standing charter a human consents to once and renews on a governance cadence, under which each unit of work draws its own short-lived Mission. The renewal default forces narrowing: a ceiling renews at its evidence-derived usage envelope, and anything wider is a new approval (the standing agent at scale). |
| Authority Set | The maximum authority committed by authority_hash, as mission_resource_access entries (resource, actions, constraints, per-entry delegation), plus any other RFC 9396 types a deployment registers. |
authorization_details | The RFC 9396 wire shape for derived authority. |
| Binding security architectures | Credential-carried (the Mission rides the credential), PDP-joined (the decision point joins ordinary credentials to the record), and authority-native (the substrate’s own authority object is the record): the three security systems the four bindings realize, named beside the level and the binding (the deployment ladder). |
| Child Mission | A strict-subset Mission a parent authorizes for a sub-agent, with cascade revocation. Offline attenuation: minting a narrower child token off the AS hot path, kept safe by the runtime re-checking Mission state. |
| Claim gate / litmus test | The six properties, split four and two: the four substrate properties admit the category at issuance strength, and two more back the action-time defense claim, expanded above. |
| Class-guard classes | Irreversible actions, external commitments, and privileged administration. The class guard keeps a human in the approval for them whatever approves everything else, and the runtime prices the same classes as high-consequence, where the strictest requirements attach (who may approve, which actions are consequential). |
Completion / discharge / terminal_when | Authority that retires itself as work finishes, entry by entry. terminal_when is the one member a consumer must understand rather than ignore, because ignoring it fails open (Complete). |
Consent Evidence / consent_rendering_hash | A companion artifact committing the structured disclosure the AS recorded as rendered (not the pixels, not comprehension). |
| Consequential action | An action with external visibility or effect, the unit the runtime gate evaluates. The boundary is deployment policy above a floor the profile fixes, and the classes are floors across reversibility, exposure, privilege, commitment, and value (which actions are consequential). |
| Constraints, two layers | The Intent’s free-text constraints bind at disclosure: they are what the Approver reads, never what the derivation function parses. An Authority Set entry’s structured constraints bind at enforcement: machine-actionable, with Common Constraints where shared semantics exist. |
| Containment matrix | The six kills of incident response (Mission, agent, Agent Deployment, credential, workload, egress), each with its own blast radius and owner, in the runtime part. |
| Control plane for delegated authority | The operational reading of the layer: the Mission record is desired state, issuance and the runtime gate are the data plane consulting it, the freshness dial is propagation, and the discovery loop is reconciliation for authority. The strategic case is in the architecture chapter, and the structural mapping is the Authority Control Plane part. |
| Decision Evidence / Execution Evidence | Per-decision and per-outcome audit records. |
| Deferred Approval / Revision | The approval event made asynchronous. Submission returns a deferral code, the review rides the workflow the organization already staffs, and derivation happens once, at the approval event, under the policy in force. Revision is the narrowing channel: a reviewer trims bounds through the same deferral, and a narrowing is never an edit in place (deferred and revisable approval). |
| Delegated authority | Authority exercised by an actor on the strength of someone else’s approval. The layer’s whole subject matter, and the handbook’s claim is that managing it is a layer with no standard form. |
| Delegation | The explicit grant of same-or-narrower authority to another actor. Spawning is not delegation, a handle is not a credential, and ancestry grants nothing (Mission-Bound Authority). |
| Derivation / derivation policy | The mechanical step that turns a validated Intent and registry facts into an Authority Set, performed once at the approval event under the policy in force. The derivation policy is that step’s deployment-authored artifact: deterministic, no model in the loop, fixture-tested, and versioned by policy_version (the derivation policy, concretely). |
| Discovery loop | Deny, request, approve, expand, retry: how the open world arrives under governance, named in Adopting. |
| Enforcement-scope statement (the honest deployment claim) | The deployment’s published claim: the level, the mediated paths, the issuance-gated paths, the exclusions, and the freshness bound each path actually runs. The honest deployment claim in the Reference’s citation kit is its reusable template: a claim that cannot be written in that form is not a conformance claim. |
| Evidence family | Shaping, Consent, Decision, and Execution Evidence plus the lifecycle records, each emitted by its own authority and joined on the Mission. The join is what makes continuity verifiable. |
| Expansion / successor Mission | Widening as a fresh approval that creates a successor with lineage, never an edit in place. Activation atomically supersedes the predecessor, because two active records for one undertaking are a widening wearing a lifecycle (Grow). |
| Fail closed | The uniform failure posture. For consequential actions, when the answer is in doubt, refuse: unknown states are non-active, an unrecognized narrowing member refuses the entry, and missing state is a denial, never a default. |
| Fatigue budget | Approval attention treated as a security boundary with a spend plan: route decisions where attention already lives, narrow instead of resubmitting, and spend action-bound approval only at maximum consequence (the fatigue budget). |
| Five laws | Durability, Attribution, Narrowing, Termination, and Containment, the layer’s substrate-neutral invariants, stated in full. |
| Freshness source / staleness bound | The published maximum age of the Mission state a path relies on, and the mechanism that supplies it: issuer introspection, Mission Status, the Status List, or Signals. Only active permits reliance, within the bound (fail-closed and active freshness). |
| Harness | The execution-continuity owner: sessions, task graphs, queues, retries, and sub-agent handles. It binds every durable work item to Mission state and stops when the Mission does. Cooperation, never containment (the agent runtime and audit). |
Integrity anchors (intent_hash, authority_hash) | The commitments that bind what was approved to what is enforced: intent_hash is the canonical hash of the approved Mission Intent, and authority_hash is the canonical hash of the Authority Set, both committed at the approval event and carried with the mission claim. |
| Issuance gating | The token-layer chokepoint. A non-active Mission derives and refreshes nothing, so credential issuance itself consults the record. |
| Issuance grant | The middle path that restores the token-layer chokepoint to a MAS estate: estate Authorization Servers redeem MAS-minted grants for Mission-bound, state-gated tokens without moving approval into the AS. |
| Least exposure | Bound what the agent may see as deliberately as what it may do, the exposure discipline whose enforceable slice today is the edges the trifecta-containment claim names. |
| Lethal trifecta | Private-data access, untrusted-content exposure, and external side effects in one execution loop. The handbook treats it as a first-order design constraint: the legs stay separately typed, separately evaluated, and separately auditable, and trifecta containment is a claim with named conditions (Splitting the Lethal Trifecta). |
| Lifecycle states | active / revoked / expired. Companion states suspended / completed (Status), superseded (Expansion), and cascaded (Child Delegation). Unknown states are treated as non-active. |
| Logical Agent | The durable agent identity in the registry, with an accountable owner, status, and risk tier. It outlives deployments, instances, and Missions. |
| Mandate | A signed, portable, independently verifiable statement of a Mission’s committed facts, minted by its issuer, with optional selective disclosure. Evidence, never a credential: presenting one authorizes nothing (the control plane part). |
| Mediated custody | The High-Assurance discipline in which the agent never holds the sender-constraint key for a protected class. A mediating handler holds it, obtains the parameter-bound permit, and acts (the high-assurance level). |
| Mission | The durable, approval-backed, integrity-anchored record of one approved undertaking: what was approved, by whom, within what bounds, until when, and whether it is still in force. Identified everywhere by mission.id and mission.issuer, committed by intent_hash and authority_hash, and authoritative for reliance, where only active permits it (The Mission Is the Missing Abstraction). |
| Mission Assurance Levels | Baseline Issuance, Runtime-Enforced, Governed Agent, and High-Assurance Agent, with the binding (OAuth AS, standalone Mission Authority Server, AAuth Person Server, or the experimental UMA sketch) as the orthogonal axis, staged as crawl, walk, run in Adopting Mission-Bound Authorization, and read as an unlock ladder: each level makes a broader class of write authority defensible. |
| Mission Authority Server (MAS) | The standalone binding: a dedicated Mission Issuer that derives no tokens, with the PDP joining each ordinary OAuth token to its Mission at the point of use (the control plane part). |
mission claim | The object on every issued token: id, issuer, authority_hash, plus the OPTIONAL expires_at member the core defines as a bounding commitment with no liveness. |
| Mission Intent | The structured proposal: goal, resources, and expires_at (required), with optional constraints, proposed_authority, success_criteria, purpose, and controls. Closed at the top level: unknown members are rejected, and machine-actionable extensions ride in controls. Submitted via the mission_intent parameter through PAR. |
| Mission Issuer (the Authorization Server) | Holds the Mission record, derives authority, runs the approval event, gates issuance. |
| Mission Shaper | A client-side component that turns a prompt or trigger into a candidate Mission Intent. Proposes only. Grants no authority. |
| Mission Status | (pull, signed, mission_id-keyed) and Lifecycle Signals (SET events, delivered push or poll). Expansion widens via a fresh approval that supersedes the predecessor. Completion / terminal_when is monotonic, per-entry discharge. |
| Offline attenuation | Minting a strictly narrower token without an issuer round-trip, the narrowing proven on the chain, for fan-out at scale at the cost of issuer visibility (mechanism 2). |
| Open world | The deployment condition the architecture assumes: tools and resources discovered at runtime rather than pre-registered, trust relationships that form after authorization time, delegation to actors unknown at approval, untrusted content in the working set, and authorization decisions made with incomplete knowledge of what the task will need. The Open-World OAuth series is the published treatment, and the discovery loop is how the open world arrives under governance. |
| Orchestrator | The runtime role that records, before dispatch, how each step will be unwound: reversibility classes and unwind plans, exercised when a Mission stops mid-flight. |
parameter_digest | Binds a permit to concrete request parameters, closing the time-of-check-to-time-of-use gap. |
| PEP / PDP | The Policy Enforcement Point obtains a permit from the Policy Decision Point before each consequential action. The PDP evaluates against the live Mission. |
| Permit (the lease) | The PDP’s short-lived, audience-specific, parameter-bound decision artifact. It binds the request, not the world, and the high-consequence classes consume it exactly once (runtime enforcement). |
| Policy approver | An authorized policy that approves at machine speed inside a previously human-consented ceiling, with committed inputs and policy_version standing where the disclosure stood (who may approve). |
| Projection | An audience-scoped, subset-ruled view of a Mission’s authority, carried in a credential or loaded as a policy view. Projections never exceed their source and expire no later than it. |
| Read-only ceiling | The posture most estates start from (read-only agents, humans approving or executing the writes, permanent pilots), what it costs, and the graduation path off it, named in Adopting. |
| Reference security architecture | The Runtime-Enforced level as a formula: issuance core, runtime enforcement, AuthZEN binding, and a freshness source. Ratified dependencies, sized as a substantial build. |
| Revocation | Ending authority, not merely tokens. It stops new derivation immediately and stops reliance within each path’s published freshness bound, and completed effects need compensation, never time travel. |
| Runtime enforcement | The action-layer chokepoint. Each consequential action is checked against the live Mission and current resource policy at the point of use (Mission-Bound Runtime Enforcement). |
| Sender constraint | The binding that makes a credential unusable without its key (cnf with DPoP or mutual TLS). Mediated custody moves that key out of the agent entirely for the highest classes. |
| Session | Execution continuity, never authority. A session proves where work can resume. The Mission decides whether it may (the agent runtime and audit). |
| Shaping Evidence | An optional record of how the proposal was produced. Audit material, not authority. |
| Standing agent | The agent that never finishes. The agent stands, the authority cycles: a ceiling carries the meaning, and each unit of work draws its own Mission with its own expiry and discharge (the standing agent at scale). |
| Standing authority | Authority that persists between tasks because a credential, account, or grant persists. The blank check, and the thing the layer exists to retire. |
| Status List | The fleet-scale freshness surface: one signed, TTL-bounded bit array covering many Missions, where a set bit is the only thing that permits reliance (observe and revoke). |
| Subject / Approver | {iss, sub} principals: the user the task is for, and the principal who approved it. They may differ. The Approver may be a human or an authorized policy authority, and a non-human approval traces to a human-consented ceiling or policy (who may approve). |
| Subset rule | Every derivation, projection, and delegation yields the same or narrower authority than its source, validated at the issuer or proven on the chain. Widening is never derivation. It is a successor Mission. |
| Survivable incorrectness | The design stance beneath the laws, inherited from the Mission Shaping series: assume the agent will sometimes be wrong and keep the system governable when it is, with least exposure as the input arm and the laws and runtime gate as the action arm. |
| Swarm | Many attested instances of one Agent Deployment executing one Mission: multiplication, not delegation. The class is an authorization subject, never an attribution subject (the swarm). |
| Taint rule | The harness discipline that downgrades a session once untrusted content enters it, under default-taint polarity: a parameter that cannot be affirmatively traced to a trusted source stays tainted, so paraphrase sheds nothing (the trifecta at execution time). |
| Three objects, three lifecycles | Agent identity (who is acting), Agent Deployment (what is running), and the Mission (why the authority exists), each with its own owner, lifecycle, and revocation, defined in the architecture chapter with the working integration above. |
| Token classes | The core’s taxonomy. A Mission-referenced token carries a Mission reference without derived authority or any gating guarantee, and a reference is never authority. A Mission-derived token carries Mission-derived authority as authorization_details. A Mission-bound token is a Mission-derived token whose issuance and refresh are gated on active state, and the core reserves “Mission-bound” for that gated class alone. |
| Undertaking | The work itself, the durable task that spans tokens, calls, tools, sub-agents, and time. The Mission is its record. The undertaking is what the record governs. |
| Vendor test | The same six properties as questions to ask a vendor, with what failing answers sound like. |
| Verifiable continuity | The property that the approval, the decisions including denials, and the executions can be shown to belong to one undertaking, joined deterministically on the Mission rather than stitched from timestamps. Distinct from lifecycle continuity, the workflow surviving time and disconnects (the agent runtime and audit). |