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). |
Adjudication / consent_principal | The approval roles approval_basis records: derivation fixes the authority, the adjudicator decides whether this Mission instance activates, and consent_principal names the human accountable for it (the record’s approver is its compatibility alias). adjudication.kind is human, the Approver deciding, or policy, a deterministic, versioned policy (policy {id, version}) acting within a ceiling a human consented to. A model’s output enters only as a recorded input to that policy: it can refuse or narrow, never supply or widen authority (OAuth binding). |
| Adoption bundle | The Architecture’s name for each Mission Assurance Level: a named set of documents a deployment runs, taken in the order deployments build them. Never a conformance class, an earned label, or a ladder: a deployment adopts the bundle its risk warrants and stops there, and a relying party compares assurance claims, not bundles (Architecture). |
| Agent Deployment | The approved behavioral version of an agent (code, model, system prompt, tool allowlist, data scope, runtime configuration), owned by change governance. Pinning a Mission to one is an architectural pattern with no wire member in the OAuth binding; a future Agent Deployment Binding profile would realize it. An agent identity and an Agent Deployment are distinct: a profile may map a Deployment version to its own client registration, but nothing requires it. The shared agent identity is the authorization subject and the instance is the attribution subject: one Mission may be executed by many attested instances at once, their aggregate consumption bounded by the Mission-grain metering budget, with per-instance keys keeping the record attributable. Distinct from the Mission Deployment Profile, the estate’s published claims manifest. |
| 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 atomic, adjudicated transition that creates a Mission active under its authorization basis (approval_basis). Every Mission has its own, identified by the record’s approval_event_id. Under the direct basis it is a human approval: 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, atomically. Under a standing-consent basis a policy activates the instance against a human’s earlier consent, with no fresh human approval, and the instance’s approval_event_id identifies that activation, never the standing approval. |
| Approved Authority Set | The Authority Set the approval event fixes: immutable, committed by authority_hash, and never changed in place. Containment and Entry Discharge only subtract from it, producing the Effective Authority Set; widening takes a new approval event and a successor Mission (Architecture, the authority path). |
| Assurance claim | A named property a deployment can prove, each with a proof obligation an existing profile fixes, listed in its Deployment Profile rather than implied by a level: approved-record integrity, bounded revocation latency, action-time enforcement, parameter-bound enforcement, transaction-grade execution, and the two High-Assurance claims (agent-compromise-resistant enforcement and trifecta containment). The surface a relying party compares (Architecture). |
| 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 entries of any RFC 9396 type the AS supports: the OAuth binding is type-agnostic. The handbook’s examples use the Mission Resource Access Profile’s mission_resource_access entries (resource, actions, constraints, per-entry delegation). The approval event fixes it as the Approved Authority Set, and narrowing yields the Effective Authority Set. |
authority_source | The immutable record member naming whose authority the approval draws on: user_delegated (a delegating person’s own), service_owned (a workload’s provisioned authority), or organizational (governed policy with a named accountable owner, referenced by policy {id, version, digest}). Provenance beside approval_basis, folded into neither anchor and never carried on tokens (OAuth binding). |
Authorization basis (approval_basis) | The approved root a Mission traces to, fixed at the approval event: direct (a human’s own approval), template (a dispatch drawing on a ceiling consented once), policy_drawdown (a policy-adjudicated child within a parent’s consented bound), or ceiling_drawdown (a policy-adjudicated successor within a ceiling consented in advance, under the Progressive profile). Every basis, defined by the OAuth binding or a companion, names the same accountable human as consent_principal and records activation, activation_actor, and root_commitment, with an optional adjudication. Provenance recorded beside the anchors, never folded into them. |
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 context-carried (the substrate’s own mission context is the record): the three security systems the five bindings realize, named beside the level and the binding (the adoption order). |
| Child Mission | A strict-subset Mission a parent authorizes for a sub-agent, with cascade revocation. Requested by RFC 8693 token exchange presenting the parent’s sender-constrained access token (never a refresh token); the child redeems its own grant. Offline attenuation is the issuer-free alternative, with its own row. |
| Claim gate / litmus test | The six properties, split four and two: the four category properties admit the category at issuance strength, and two more back the action-time defense claim, expanded above. The six are the handbook’s own category bar. The drafts’ substrate contract is deliberately looser, treating structured authority and monotonic derivation as optional capabilities, so a binding can meet it and still fail the vendor test’s questions 2 to 4. |
| 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, defined by Mission Entry Discharge. terminal_when names an entry’s completion conditions, and like every constraints key it fails closed: a consumer that does not understand it refuses the entry, because ignoring it would widen the grant. A discharge takes effect when the AS commits it and the Mission stays active; Mission-level complete stays with Status (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 task_bounds bind at disclosure: human-readable strings the Approver reads beside the derived set, never what the derivation function parses. An Authority Set entry’s structured constraints bind at enforcement: machine-actionable, with the Resource Access Profile’s Common Constraints where shared semantics exist. |
| Consuming AS | An estate Authorization Server that redeems Mission Issuance Grants at its token endpoint. With a Mission-state integration it projects each redemption and refresh through the Effective Authority Set; without one, only the grant’s active-at-minting gate applies, it issues no refresh tokens, and a revoked Mission’s residual is the grant’s remaining redemption window and clock-skew leeway, plus the issued token’s lifetime, plus that of each further exchange that checks no Mission state, capped by the Mission’s expiry (Mission Issuance Grant). |
| Containment | Five senses, each with its own home. Law 5: execution stays inside approved purpose (the five laws). Authority containment: the layer function that checks every consequential action against the approved purpose at the point of use (the layer vocabulary). The containment overlay: Mission Containment’s removal-only narrowing of a live Mission. The containment matrix: the seven kills of incident response. Trifecta containment: the named High-Assurance claim against injection-driven exfiltration (the lethal trifecta at execution time). The overlay and the matrix have their own rows. |
| Containment matrix | The seven kills of incident response (capability via the containment overlay, 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, defined with the Refusal Record by Mission Runtime Evidence and joined to the permit by evaluation_id. |
| 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: it narrows a submitted authorization_details proposal, or, with no proposal, applies a configured mapping keyed on the Intent’s purpose within its target_resources. The derivation policy is that step’s deployment-authored artifact: deterministic, fixture-tested, and versioned by policy_version, admitting a model’s output only as a recorded input that refuses or narrows and never supplies or widens authority (the derivation policy, concretely). |
Derivation limit (derivation_limit) | An issuer-side cap on the derivations (counted issuance events) the Mission Issuer performs under one Mission: the lesser of the Intent’s requested_derivation_limit and AS policy, rendered at approval, with any derivation past it refused (mission_error value derivations_exhausted). Not a fan-out or concurrency ceiling: a swarm’s aggregate bound is the Mission-grain metering budget (Mission Derivation Limits). |
| Discovery loop | Deny, request, approve, expand, retry: how the open world arrives under governance, named in Adopting. |
| Effective Authority Set | The Approved Authority Set after every issuer-held, monotonic narrowing the deployment runs, such as Entry Discharge and Containment. It only subtracts. Every derivation draws from it under the subset rule, and the runtime decision takes the current set as its own input, separate from the authority the credential carries. Membership is necessary, never sufficient, for an action to proceed (Mission Status and Lifecycle). |
| Enforcement-scope statement (the honest deployment claim) | The deployment’s published claim, leading with the assurance claims it makes, then the mediated paths, the issuance-gated paths, the exclusions, and the freshness bound each path actually runs, with the adoption bundle as context: the bundles are guidance and the claims are what a relying party compares. Update it when a path’s coverage, controls, or published bounds change (not every resource checks Mission state). 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 one a relying party can compare. |
| Entry Discharge | The companion that lets one mission_resource_access entry finish before the Mission does. terminal_when names the entry’s completion conditions, and the discharge operation on the lifecycle endpoint commits a condition’s firing under a distinct mission_discharge grant. The entry stops deriving and the Mission stays active (Mission Entry Discharge). |
evaluation_id / conditions | Members of an AuthZEN permit. evaluation_id correlates one evaluation with its Decision Evidence. conditions carries the permit’s decision conditions, honored at every use: parameter_digest, valid_until, and use_limit (1 for the high-consequence classes). A PEP refuses a permit carrying a condition it does not recognize (AuthZEN Profile). |
| 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. Requested by RFC 8693 token exchange presenting the predecessor’s sender-constrained access token (never a refresh token). 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 and mapped to the drafts’ terms: the Architecture’s seven Mission Invariants and the OAuth binding’s six properties, neither one to one. |
| 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. Neither rides the mission claim: both stay on the record, and an authorized introspection caller can receive authority_hash. The conditional proposal_hash commits a submitted authorization_details proposal where one was made. |
| Issuance gating | The token-layer chokepoint. A non-active Mission derives, refreshes, or exchanges 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 tokens without moving approval into the AS. Every grant is minted against current Mission state; whether redemption and refresh are checked again depends on the consuming AS’s mode. |
| 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 Signals | The push complement to Mission Status: a profile of the OpenID Shared Signals Framework in which the Mission Issuer emits a signed Security Event Token, a mission.lifecycle-change event, for each committed lifecycle transition, delivered push or poll (Signals: the push side). |
| Lifecycle states | active / revoked / expired. Companion states suspended / completed (Status), superseded (Expansion), and cascaded (Child Delegation). Unknown states are treated as non-active, and reliance requires the effective-active pair: stored active and a decision time before expires_at, with expiry evaluated before stored state is trusted. |
| 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). |
| Mapping Assessment | The OAuth binding’s informative appendix describing, in the Mission Substrate Statement’s form, how its surfaces realize the substrate kernel and capabilities. It adds no requirement: the OAuth binding publishes no Statement and makes no substrate-conformance claim (OAuth binding). |
| 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 | A durable, approval-backed governance object for authorization: the approved task, with a lifecycle, that authority is derived for, bound to, and gated on. Its record says 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: adoption bundles, named sets of documents taken in the order deployments build them, never a conformance class, an earned label, or a ladder. The binding (OAuth AS, standalone Mission Authority Server, AAuth Person Server, or the UMA and GNAP sketches) is the orthogonal axis, and Adopting Mission-Bound Authorization stages the bundles as crawl, walk, run. Read in adoption order, each bundle makes a broader class of authority defensible to grant, an informative mapping: at Baseline Issuance, writes whose bounds the receiving Resource Server enforces; at Runtime-Enforced, parameter-bound writes and bounds finer than the Resource Server checks. A level does not determine any action class’s containment property. A deployment adopts the bundle its risk warrants and stops there, and the named assurance claims, not the level, are the surface a relying party compares. |
| Mission Authority Server (MAS) | A standalone controller over the OAuth binding’s Mission data model: 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 Mission Join). A peer deployment topology, not an independent substrate model; an estate whose Authorization Servers cannot issue Mission-bound tokens starts there (the control plane part). |
mission claim | The object on every token derived under a Mission: id and issuer, plus the OPTIONAL expires_at member the OAuth binding defines as a bounding commitment with no liveness. It carries neither authority_hash nor approval_basis, except on an offline-attenuation chain, where the root’s authority_hash rides as a lineage anchor; an authorized introspection caller can receive both. A standalone Mission Authority Server’s tokens stay ordinary OAuth tokens and carry no mission claim. |
| Mission Containment (the overlay) | The experimental narrow-without-ending channel: when a declared protected event fires, the issuer commits a versioned, removal-only overlay that subtracts capability from the Effective Authority Set while the Mission stays active and the anchors stay immutable. Removed authority returns only as a successor via Expansion. |
| Mission Continuation | Authorization continuity across hops and over time: the Mission binds an identity-continuity transport (the Identity Continuation Assertion, async delegation, or cross-domain projection) under one invariant, a continuation handle grants nothing, and every continued grant re-passes the active gate. Continuity is never authority. |
| Mission control point | The generic role that holds a Mission’s approved context, lifecycle, and gating: the Mission Issuer (the AS) in the OAuth binding, the MAS in a standalone deployment, the Person Server in AAuth, and the AS in the UMA and GNAP sketches (Architecture). |
| Mission Intent | The structured semantic proposal: goal, target_resources, and expires_at (required), with optional goal_lang, task_bounds, success_criteria, and purpose. Closed at the top level: the AS refuses, with invalid_request, any member that neither the OAuth binding nor a companion it implements defines (Derivation Limits’ requested_derivation_limit, for example). The Intent carries no authority members: a candidate proposal rides beside it as standard top-level authorization_details, untrusted and only ever narrowed, committed by the conditional proposal_hash. Submitted as the intent member of the Submission envelope (mission_intent carries {intent, evidence}) through PAR. |
| Mission Issuer | The role that validates the Mission Intent, runs the approval event, derives the Authority Set, records the Mission, and owns its state. In the OAuth binding the Authorization Server plays it and also gates token issuance; under a standalone MAS, the MAS plays it and derives no tokens, and estate Authorization Servers can redeem its Issuance Grants. |
| Mission Shaper | A client-side component that turns a prompt or trigger into a candidate Mission Intent. Proposes only. Grants no authority. |
mission_state_observation | The AuthZEN request object carrying a PEP’s Mission-state snapshot: state, mode (fresh, cached, or event_driven), and freshness_at, with the status issue and expiry times in the cached and event-driven modes. Required where the deployment places state establishment with the PEP; wherever the PDP can consult a state source itself, its own view is authoritative (AuthZEN Profile). |
| Mission Status | The pull surface for Mission state: a signed, mission_id-keyed response a consumer requests, also keeping the Mission-level complete operation. Per-entry discharge under terminal_when belongs to Mission Entry Discharge, and the fleet-scale list to Mission Status List (Status: the pull side). |
| Mission Substrate Statement | The section of a Mission Substrate Binding that declares how it maps the substrate contract’s kernel (a Mission reference and controller, actor binding, approved context, an approval event, an active/non-active gate with bounded reliance, context propagation, and an ordered governance record) and which of eight optional capabilities, such as structured authority and monotonic derivation, it supplies, with the limits of each claim (Mission Substrate Requirements). |
| 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, kept safe by the runtime re-checking Mission state (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: its state and current Effective Authority Set, beside the authority the credential carries. |
| 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 adjudication | A deterministic, versioned policy that decides Mission activation at machine speed inside a previously human-consented ceiling, recorded as approval_basis.adjudication with kind: policy and the deciding policy {id, version}, so re-evaluating that version over the recorded inputs re-checks the decision. The Approver of record stays the human whose consent roots the ceiling: the policy adjudicates and never becomes the Approver, and a model’s output is at most a recorded input that can refuse or narrow (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: the OAuth binding, runtime enforcement, its AuthZEN Profile, Mission Runtime Evidence, and a freshness source, with Substrate Requirements arriving as the normative kernel that runtime enforcement and the AuthZEN Profile consume. Its family documents are intended for the Standards Track; its outside dependencies include working-group drafts (ARAP, the AuthZEN Obligations Profile, and OAuth RAR metadata remediation) and a proposed individual draft, Client Instance Identification, which is where the remaining dependency risk sits. Sized as a substantial build. The architecture stages four such stacks, one per level, each containing the previous, and this is the second. |
| Refusal Record | The evidence record a PEP or PDP emits for a refusal before any PDP decision: a failed token validation, an unreachable PDP, Mission state the PEP cannot establish, or a request missing its Mission context. It carries only facts the refusing role verified; once a PDP has decided, every outcome is Execution Evidence instead (Mission Runtime Evidence). |
| Request provenance / request intake | An optional Intent Submission Evidence type. A request intake, isolated from the shaper, authenticates the originator, captures the instruction before shaping, and signs an assertion of the originator, channel, and capture time bound to one Authorization Server, one exact Intent, and one presenter, carrying only a keyed digest of the instruction. Policy input, never approval or authority (Request Provenance). |
| Residual | What a control leaves for someone else to own. After revocation, the residual window is how long already-issued authority can still be honored: the sum of every lifetime and redemption window that runs without a Mission-state check, capped by the Mission’s expiry. Against a threat, the residual is the part the deploying party still owns after the gate caps it (Mission Security Model). |
| Revocation | Ending authority, not merely tokens. It changes the Mission’s state immediately, stops new derivation once the issuer observes that state, and stops reliance within each path’s published freshness bound, and completed effects need compensation, never time travel. It does not prevent equivalent authority from being approved under a separate Mission, which takes policy over the approval paths. |
| 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. |
| Standing consent | An accountable human’s earlier approval, such as an authority ceiling, under which a template or a policy activates Mission instances with no fresh human approval per instance. Each instance still has its own approval event, and template, policy_drawdown, and ceiling_drawdown are the standing-consent bases. Unlike standing authority it holds no credential: each unit of work draws its own Mission (who may approve). |
| Status List | The fleet-scale freshness surface defined by Mission Status List: one signed, TTL-bounded list of two-bit values covering many Missions. VALID (0x00) reports active and is the only value that permits reliance; SUSPENDED (0x02), INVALID (0x01, every terminal state), and any other value are non-active (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 is always the accountable consent principal, a human, equal to approval_basis.consent_principal: under a standing-consent basis an authorized policy adjudicates the activation while the Approver remains the human whose consent roots it (who may approve). |
| Submission envelope | The JSON object the PAR mission_intent parameter carries: intent, the Mission Intent, and an optional evidence array of Intent Submission Evidence entries. Closed at the top level, and intent_hash commits the intent member only, never the envelope or its evidence (OAuth binding). |
| 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 executing one Mission under the same authorized agent identity, each satisfying the Mission’s Agent Deployment pin where one is implemented: multiplication, not delegation. The shared identity 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 OAuth binding’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 it 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). |