Bounded Capability Receipts and Durable Spend Control for Agent Actions

Introduction A single-action authorization receipt is intentionally narrow: it records approval of one exact action and can be accepted at most once within its atomic consumption domain. Some agent deployments also need a different primitive. For example, an operator may authorize an agent to purchase a bounded class of supplies, subject to an aggregate monetary ceiling and an expiry, without asking a human to approve each conforming purchase. That primitive has two inseparable parts:

a signed capability receipt that states the immutable authority boundary; and
a shared, durable state machine that serializes reservations and committed consumption across retries, processes, replicas, and restarts.

The signed object without the state machine is replayable budget metadata. The state machine without a signed, scoped grant has no portable statement of authority. This document specifies their composition.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. BCP 14 is indexed by the RFC Editor at .

Scope and Non-Goals This document defines issuance binding, action-scope evaluation, budget accounting, holder proof, durable reservation and commitment, and narrowing delegation. It does not define user authentication, human-approval presentation, general policy syntax, payment clearing, settlement, currency conversion, revocation distribution, or the external effect adapter. A capability receipt is machine authority evidence. It is not, merely by being signed, evidence that a human reviewed each later action. Deployments that require per-action human authorization continue to require a per-action authorization artifact. When a capability may be exercised by more than one executor, every executor MUST use the same relying-party-pinned authoritative atomic state domain. A deployment that cannot enforce that binding MUST restrict the capability to one executor or state only a per-executor budget guarantee.

Terminology

Issuance authorization:: An independently verified authorization artifact for the exact act of creating a bounded capability.
Capability receipt:: The signed immutable grant defined by this document.
Capability issuer:: The principal whose pinned key signs a capability receipt.
Holder proof:: Proof that the requester controls the secret or key named by the capability receipt. Holder proof is not proof that a requested action is in scope.
Scope verifier:: A verifier for a named scope profile, selected and configured by the relying party.
Capability store:: The authoritative shared transactional state for registration, reservation, and committed consumption.
State domain:: The relying-party-pinned atomic store and trust configuration to which every authority-bearing participant for a capability lineage is bound. A state-domain identifier is deployment context, not portable proof of global uniqueness.
Operation ID:: An identifier unique for one attempted operation under one capability receipt. The authoritative operation key is the tuple of capability receipt digest and operation ID inside the state domain.
Reservation token:: An unguessable owner-fencing value returned by a successful reservation and required for its commitment.
Provider-entry deadline:: The authoritative instant before which a reserved operation may enter the effect adapter. It is no later than capability expiry.
Effect boundary:: The point after which an external effect may have occurred and therefore budget cannot safely be restored merely because the caller did not receive a successful response.
Indeterminate outcome:: An operation for which the executor cannot prove that no effect occurred and cannot prove a successful expected effect.

Trust Model The relying party selects capability-issuer keys, accepted issuance authorization profiles, scope profiles, state-store domain, and local authorization policy. A key embedded in a presented capability receipt MUST NOT, by itself, become a trust anchor. An empty trust configuration MUST fail closed. The capability store is trusted to serialize state transitions and retain committed operation records. The effect adapter is trusted to place the effect boundary correctly and to report outcomes honestly. This protocol makes those trust dependencies explicit; it does not remove them. All capability-store participants that can authorize a capability or allocate, register, reserve, commit, reconcile, revoke, or report any ancestor or descendant drawing on that capability's authority MUST use one shared authoritative atomic state domain. Independent stores cannot prevent each other from accepting or reallocating the same remaining authority. Conservation claims in this document apply only inside that one domain. A deployment may have multiple executor instances, settlement adapters, or process replicas. If they can exercise the same capability, each MUST resolve the same state domain before admission and use that domain for the budget transition. An executor's local record of prior spending is not an authoritative aggregate record. If the deployment cannot make the shared-domain guarantee, it MUST either name exactly one executor in the applicable scope or describe the limit as per-executor and MUST NOT claim aggregate conservation across executors.

The Bounded Capability Receipt The receipt is a JSON object serialized using the JSON Canonicalization Scheme (JCS) before signing. The following is illustrative:

Required Fields

@version:: EP-BOUNDED-CAPABILITY-v1.
capability_id:: A globally unique, opaque identifier. Uniqueness is not used as a substitute for cryptographic binding.
issuer:: The issuer identifier used to select a relying-party-pinned verification key.
subject:: The intended holder or workload identifier. This identifier does not replace holder proof or live workload authentication.
authorization:: The identifier and SHA-256 digest of the complete issuance authorization artifact. The digest MUST cover the exact bytes accepted by that artifact's native verifier.
scope:: A named scope profile, its value, and the SHA-256 digest of the JCS serialization of profile and value.
budget:: A non-negative integer amount no greater than 9007199254740991, an explicit unit, and a decimal scale from 0 through 18. For iso4217:USD with scale 2, an amount of 250000 denotes USD 2500.00. Implementations MUST NOT infer a scale from display conventions. The represented value is amount * 10^-scale; increasing scale therefore reduces the maximum representable major-unit value. A profile MUST refuse an amount-and-scale combination that cannot represent its declared operating range. This version does not encode arbitrary-precision decimal values.
holder:: A recognized holder-proof method and its method-specific commitment.
threshold:: Integers m and n satisfying 1 <= m <= n <= 255. This field describes custody of the holder credential; it does not assert approval by distinct humans.
revocation_mode:: Exactly direct or cascade. A direct revocation affects the named capability but does not withdraw authority already transferred to a registered child. A cascade revocation also blocks new authority claims by every descendant. The value is signed and MUST NOT be inferred from the issuer, holder, lineage depth, or a presenter-selected default. A missing or unknown value MUST be rejected.
parent:: null for a root capability. For a child capability, an object containing the parent capability ID, the digest of the complete signed parent receipt, and the identifier of an authenticated parent delegation operation. That operation MUST bind the child receipt digest and the delegated amount, unit, scale, scope, validity interval, and revocation mode. A parent identifier without digest-bound parent and delegation evidence is insufficient.
not_before and expires_at:: UTC timestamps in Internet Date/Time format using the canonical string form selected by the deployment profile. Expiry is exclusive. Numeric epochs, implementation-specific date strings, and values that do not round-trip to the canonical form MUST be rejected.

Signature Input and Receipt Digest The issuer signature input is the JCS serialization of the object containing exactly @version and capability. The signature algorithm for this version is Ed25519 . The receipt digest is: The issuance authorization is bound by both its identifier and digest. Binding only a caller-selected receipt identifier is insufficient because two different artifacts can carry the same identifier.

Receipt Verification A verifier MUST perform all of the following and fail closed on any error:

apply bounded parsing and reject duplicate JSON member names, unknown critical versions, malformed encodings, and out-of-range values;
select the issuer key from relying-party configuration, not from the presented object alone;
verify the issuer signature over the exact signature input;
natively verify the issuance authorization under its own pinned trust inputs and compare both receipt identifier and digest;
verify that the authorized action is issuance of this exact capability object, or of a digest that commits to it;
verify the scope digest and require a recognized, relying-party-enabled scope profile;
verify the validity interval and, for a child, resolve and verify the digest-bound parent lineage to a root capability or a locally trusted, previously validated lineage checkpoint. Reject an unresolved, truncated, reordered, or substituted link; a repeated capability ID or receipt digest; the leaf appearing among its ancestors; or a path exceeding deployment policy. At every hop, verify that the child amount does not exceed the authenticated delegated amount, unit and scale are unchanged, validity is contained by the parent, and scope is no broader than the parent scope; and
compute the capability receipt digest used for store registration.

Receipt verification returns VERIFIED. It does not return AUTHORIZED, prove remaining budget, or prove that a proposed operation is in scope.

Issuance Authorization The issuance authorization MUST authorize the act of creating the capability, including the immutable digest of its subject, scope, budget, holder commitment, revocation mode, parent, and validity interval. It MUST NOT be reused as though it were a per-operation authorization for later spends. When the issuance artifact is an EMILIA Authorization Receipt, its exact action is capability issuance and its one-time consumption occurs when the capability is registered. Later capability-funded operations are governed by this document's scope and durable state protocol.

Per-Action Human Authorization Composition A deployment may require a separately authenticated human authorization for an individual capability-funded exercise. That artifact MUST bind the exact canonical exercise-action digest used by reservation and effect admission. If material terms are not committed by that digest, the artifact MUST bind those terms independently. A capability signature, holder proof, threshold custody, or key protected inside a workload is not evidence that a human reviewed the later exercise. The capability verifier and human-authorization verifier may remain separate. A relying-party composition policy may require both results for the same action digest, but the two verifiers MUST NOT treat the other's evidence as a trust anchor. This composition does not make human authorization part of every bounded capability. A deployment that permits conforming exercises without a per-action human artifact MUST state that the issuance authorization established the bounded class rather than a human reviewing each later action.

Action Scope Before reserving budget, the enforcement point MUST compute the proposed material action independently of presenter-supplied labels and invoke the pinned verifier for scope.profile. A missing profile, unknown action representation, lossy mapping, or indeterminate comparison MUST refuse. The mandatory-to-implement urn:emilia:scope:caid-set-v1 profile contains a non-empty, duplicate-free array of Canonical Action IDentifiers. It matches only exact identifier equality. For delegation, a child CAID set is no broader than its parent only when every child identifier is an exact member of the parent set. Equality of the complete sets is allowed. This non-strict subset relation is reflexive and transitive. Possession of a CAID authorizes nothing outside this verified capability context. Application profiles can define closed constraints over typed action fields. Such a profile MUST specify canonicalization, exact value equality, comparison, unknown-field handling, numerical units, and an algorithm for deciding whether a delegated scope is no broader than its parent. The profile MUST state whether that attenuation relation is reflexive and whether it is transitive. It MUST classify the basis for any transitivity claim as one of: definition-derived, mechanically-checkable, or asserted. A mechanically checkable claim MUST define a finite domain and deterministic procedure by which a verifier or conformance suite can enumerate the required triples. An asserted claim is profile-author testimony, not a demonstrated algebraic property. Every profile identifier used in a signed scope MUST identify immutable comparison semantics. An identifier fixed by immutable standards text satisfies this requirement. Any other application-profile identifier MUST be content-addressed. A mutable alias or version label alone is insufficient. The relying party MUST pin the exact profile definition selected by that identifier and refuse if the definition cannot be resolved without ambiguity or has changed. Action membership and attenuation are separate decisions. Membership returns IN_SCOPE, OUT_OF_SCOPE, or INDETERMINATE. Attenuation returns NO_BROADER, BROADER, or INDETERMINATE. A composite scope is no broader only when every mandatory component returns NO_BROADER. Any BROADER component makes the composite broader; otherwise any undecided component makes the composite indeterminate. Missing components MUST NOT be treated as successful comparisons. A verifier MUST NOT promote per-hop comparisons into a chain-wide non-widening claim unless transitivity is either derived from the relation definition or mechanically established over the profile's complete declared finite domain. A comparison under a non-transitive, asserted-transitive, or unknown-transitivity relation is local to the reported hop. It can be useful evidence, but it does not compose by induction across a delegation chain. A definition-derived classification is permitted only when the immutable profile definition specifies a relation whose transitivity follows by construction. Merely labeling a relation transitive, including in authenticated profile metadata, is an asserted basis. For a mechanically established classification, every scope value used in the composed chain MUST be a member of the exact finite domain covered by the establishment record. A value outside that domain makes the mechanical result inapplicable to that chain. For a mechanically established result, the verifier MUST disclose whether it performed the complete enumeration itself or relied on a prior conformance run. The establishment record MUST identify the runner, completion time, immutable profile and relation-rule identifiers and content digests, the canonical encoding, digest algorithm, digest, and cardinality of the complete declared finite domain, the deterministic procedure identifier, version, and content digest, and the result. A verifier relying on a prior run MUST authenticate and integrity-check that record and MUST accept the runner under relying-party-pinned trust policy. A self-authenticated or otherwise untrusted runner is insufficient. If the record is unavailable, invalid, untrusted, or does not cover the pinned profile's complete declared finite domain, the verifier MUST NOT use it for chain composition. A current per-hop comparison may still be reported local-only. This requirement does not require enumeration at admission time. A verifier relying on a prior run MUST compare the establishment record's profile and relation-rule content digests, complete-domain encoding, digest algorithm, digest, and cardinality, and deterministic procedure identifier, version, and content digest with the exact profile, rule, domain, and procedure selected for the current evaluation. A mutable version label without an immutable content binding is not an exact match. A mismatch, or an inability to perform that comparison, makes the record stale for this evaluation. Authenticated integrity proves what the earlier run reported; it does not establish that the earlier result remains applicable after a profile, rule, domain, or procedure revision. A stale record MUST NOT support a chain-wide non-widening claim and contributes no current comparison result. A verifier may report local-only only after it separately performs the current per-hop comparison; if it cannot do so, it MUST report INDETERMINATE. Reliance on an authenticated, matching prior conformance run is deliberately permitted. This document assigns no automatic trust rank to verifier-performed enumeration and relied-on enumeration; the disclosed reliance mode lets the relying party apply its own policy. Implementations SHOULD NOT repeat an otherwise acceptable complete enumeration solely to avoid reporting the relied-on mode. For each mandatory component of a delegation path containing more than one edge, every adjacent comparison used for a chain-wide claim MUST use the same immutable profile definition, relation-rule definition, finite-domain identity where applicable, and transitivity basis. Transitivity established separately for two different relations does not prove that those relations compose. This document defines no cross-relation composition rule. A path that changes any of those relation inputs is local-only across that boundary. A local-only report may be retained as diagnostic evidence, but it MUST NOT establish descendant authority across a path of more than one delegation edge. Registration or admission of that descendant MUST refuse when the current comparison is broader and MUST refuse or return INDETERMINATE when chain composition cannot be established. A single delegation edge requires a current successful local comparison but does not require transitive induction. Scope comparison is evaluated per component and relative to the verifier that produced it. A comparison report MUST record each component, the deciding verifier, the pinned profile and rule, the values compared, the local result, whether the relation is reflexive, the transitivity classification and basis, any mechanical establishment record and reliance mode, and whether the result is local-only or chain-composable. An undecided result MUST distinguish a component for which no order is defined from one whose governing profile was unavailable to that verifier. Mandatory-profile components MUST be reported rather than assumed. A structural chain result and a scope comparison result MUST NOT be combined into an overall validity claim unless both reports, including their decidability and composition limits, travel with the claim. Profiles that intentionally use a non-reflexive relation MUST state that an unchanged scope will be refused. Profiles that cannot decide either action membership or attenuation MUST return INDETERMINATE.

Holder Proof and Threshold Custody The mandatory-to-implement holder method is sha-256-preimage. The holder presents exactly 32 bytes over a confidential, integrity-protected channel, and the enforcement point compares SHA-256(preimage) with the signed commitment using a constant-time comparison. The preimage MUST NOT be logged, stored with the receipt, or included in portable evidence. This method is intentionally a bearer-equivalent interoperability baseline. Any party that learns the preimage can exercise the remaining capability subject to its scope, budget, status, and validity. A deployment whose threat model requires non-exportable holder custody or per-operation proof of possession SHOULD select an operation-bound signature method, such as the method below, or an application profile defining a hardware-bound holder method. Those stronger properties MUST NOT be inferred from the preimage method. This version additionally defines ed25519-operation-proof. For that method, holder.commitment is the lowercase sha256:<64-hex> digest of the 32-byte Ed25519 public key. The exercise proof carries that raw public key and a 64-byte Ed25519 signature, each encoded as unpadded base64url . The verifier MUST decode both values strictly, compare the public-key digest with the signed holder commitment, and verify the signature over the UTF-8 JCS serialization of this closed object: ", "operation_id": "", "exercise_action_digest": "sha256:<64-hex>", "amount": 1, "unit": "", "scale": 0, "audience": "", "state_domain_digest": "sha256:<64-hex>" } ]]> Every value in that object MUST be taken from the independently verified receipt, immutable exercise snapshot, and relying-party configuration used by the reservation. Presenter-supplied replacements MUST NOT be accepted. Replaying the same signed request is refused by the capability-scoped operation key; changing the operation ID, action, amount, unit, scale, audience, or state domain requires a new signature. This proof establishes control of the committed key for that reservation request. It does not establish a human gesture, comprehension, or approval ceremony. For ed25519-operation-proof, the portable threshold value MUST be m=1, n=1. Threshold or hardware custody behind the committed Ed25519 public key is an implementation property and does not become a portable multi-party or human-approval claim. The preimage may be divided using a threshold secret-sharing scheme before presentation. Share format, participant authentication, confidentiality, recovery, and distribution are outside this document. Reconstructing m shares proves control of the holder secret; it does not prove that m distinct humans reviewed or approved the action. Human multi-party approval requires a protocol such as .

Registration After receipt verification and one-time consumption of the issuance authorization, the issuer registers the capability in the authoritative store. Registration MUST atomically create immutable fields for capability ID, receipt digest, unit, scale, total budget, scope digest, validity interval, revocation mode, and parent. It MUST initialize consumed and reserved to zero. A second registration of the same capability ID MUST succeed only when every immutable field and receipt digest is identical. Any mismatch is a collision and MUST refuse. Consumption of the issuance authorization and registration of its exact capability receipt MUST form one idempotent logical operation bound to the capability receipt digest. If both transitions cannot share one atomic state transaction, the issuance-authorization consumption record MUST identify the registration operation and exact capability receipt digest, and both domains MUST retain enough state to query and reconcile an ambiguous result. A crash after consumption MUST NOT permit the authorization to issue a different capability or to be silently restored. A deployment using separate domains for those two transitions MUST identify a concrete reconciliation profile that defines its durable states, authenticated queries, exact-digest join, retry behavior, and terminal ambiguous result. In the absence of such a profile, consumption and registration MUST occur in one authoritative atomic state transaction. Retry of that registration may return the existing identical capability only after verifying the same issuance-consumption record. An absent or conflicting record MUST refuse or return INDETERMINATE; it MUST NOT create a second root capability from uncertain issuance state. Mutable counters in a presented receipt are not authoritative. Remaining budget is computed only from the shared store: The authoritative state MUST maintain the invariant reserved + consumed <= total for every capability. For a parent capability, each registered child allocation MUST be covered by one or more distinct terminal delegated operation committed against that parent before child registration. The aggregate amount of registered direct children MUST NOT exceed the amount committed by those distinct parent delegation operations, and each operation identifier MUST NOT fund more than one child receipt digest.

Reserve, Execute, and Commit

Reserve A reservation request contains the capability ID, capability receipt digest, operation ID unique under that capability, the immutable canonical exercise-action digest and CAID where used, positive integer amount, unit, scale, and authenticated holder proof. The same immutable action snapshot MUST be used for scope evaluation, authorization, reservation accounting, and the effect callback; a mutable caller object MUST NOT cross those boundaries. Validity and expiry MUST be evaluated from one authoritative time sample obtained inside the same state transaction; caller-supplied time is not authoritative. The relying party MUST pin a positive maximum pre-entry reservation interval. The store MUST derive and record a provider-entry deadline equal to the earlier of capability expiry and that authoritative transaction time plus the pinned interval. In one serializable transaction, or while holding an equivalent row lock, the store MUST:

load the registered capability and compare the receipt digest;
resolve the complete authority-bearing ancestor lineage in the same authoritative state domain and reject unavailable, inconsistent, or truncated state;
reject an unknown, not-yet-valid, expired, or revoked capability;
reject when any revoked ancestor has revocation_mode equal to cascade;
reject a unit or scale mismatch;
reject any already-seen operation key for that capability, regardless of its previous outcome;
verify that the amount is positive and no greater than total - consumed - reserved;
increase reserved by the amount; and
create an operation in state reserved with an unguessable reservation token, exercise-action digest, amount, and provider-entry deadline, and return that token only to the owner.

Scope evaluation and local authorization policy MUST succeed before the effect adapter is entered. Deployments SHOULD perform them before reserving to reduce abandoned reservations.

Effect Boundary The enforcement point enters the effect adapter only after a successful reservation. It MUST NOT expose an alternate path to the same effect that bypasses capability enforcement when the action requires this profile. Immediately before provider entry, the store MUST atomically verify reservation ownership and that its authoritative transaction time is earlier than the recorded provider-entry deadline, then record that provider entry has begun. A reservation that has reached its deadline MUST NOT enter the effect adapter. A serialized absence of the provider-entry marker after the deadline is authoritative proof of non-entry and may drive the not_entered transition in .

Commit A commit request contains the operation ID, reservation token, and one of three outcomes: executed, indeterminate, or delegated. In one atomic transaction, the store MUST verify ownership and reserved state, decrease reserved, increase consumed by the same amount, and make the operation terminal. A repeated commit, wrong reservation token, or commit against a non-reserved operation MUST refuse. A caller timeout does not justify retrying with a new operation ID; the caller MUST query the original operation or reconcile it. If the executor cannot prove that the effect boundary was not crossed, it MUST commit indeterminate and charge the budget. Availability loss is safer than allowing the same authority to be spent again after an unobserved external effect. Capability expiry or the provider-entry deadline prevents a new provider entry; it does not invalidate accounting for an operation that entered the provider beforehand. Such an operation MUST remain committable or reconcilable after those instants. This closes an already admitted attempt and does not extend authority to begin another effect.

Crash Recovery and Reconciliation Reservations survive process and replica failure. A deployment MUST define a reconciler for non-terminal operations. The reconciler may commit executed only with authenticated effect evidence. It may restore budget only when it can prove the effect boundary was never crossed. In every other case it MUST commit indeterminate. When non-entry is proved, the store MUST use one atomic transition to verify the reservation owner and exact action, decrease reserved without increasing consumed, and make the operation terminal with outcome not_entered. The operation key and its action binding MUST remain as a replay tombstone after budget restoration. A later presentation of that operation key MUST NOT create a new reservation. Repeated reconciliation is idempotent only for the same terminal outcome and authenticated evidence binding.

Executor and State-Domain Binding The state domain is a relying-party trust input. A portable capability receipt need not embed a globally meaningful domain identifier, but the registration and operation records SHOULD identify the domain and executor participant used for each admission so that a relying party can detect an unsupported state fork. When multiple executors are authorized to present one capability, the store MUST serialize their reservations and commitments in one domain. Merely replicating a signed receipt, copying a remaining counter, or exchanging eventual spending logs does not satisfy this requirement. A deployment that uses independent stores may still use signed receipts, but it MUST NOT describe the resulting behavior as one aggregate budget. A scope that names one executor is a valid narrower deployment choice. The applicable scope profile MUST define how that executor participant is identified and compared at admission. This removes the cross-executor guarantee requirement; it does not turn a local record into a global budget or provide offline double-spend prevention.

Narrowing Delegation A child capability MUST NOT outlive its parent, exceed the authenticated amount delegated from the parent, change unit or scale, or broaden the parent's scope. Its delegation chain MUST be bounded by deployment policy and MUST include the parent receipt digest. Before registering a child, the verifier MUST validate complete digest-linked ancestry to a trusted root within the configured depth bound, or enforce equivalent authenticated parent-edge constraints in one authoritative store. The verified lineage MUST form a simple path. The verifier MUST reject a repeated capability identifier or receipt digest, a missing or inconsistent parent, a substituted or reordered edge, or a chain whose trusted root cannot be established. A cycle, truncated lineage, or over-depth chain MUST fail closed. Per-receipt identifier uniqueness or a self-declared list of ancestors does not establish graph-wide acyclicity. An implementation MUST NOT infer acyclicity merely because its ordinary issuance path constructs children from known parents; verification applies the same check to imported and reconstructed chains. Creating a child is itself a parent-funded operation. Before registering the child, the issuer MUST reserve the delegated amount from the parent and MUST commit that exact reservation once with outcome delegated. The authenticated terminal operation record MUST bind the exact child receipt digest, delegated amount, unit, scale, scope, validity interval, and revocation mode before the child is registered; otherwise a valid parent spend could be paired with a different child. A shared store SHOULD perform parent commitment and child registration atomically. If that is impossible and child registration fails after the parent is committed, the parent budget remains consumed and the orphaned delegation MUST be retained for reconciliation. The system MUST NOT silently refund it.

Revocation Inheritance Across Delegation Lineage Delegation transfers bounded authority rather than leaving every child as a live reference to its parent. Direct revocation of an ancestor therefore does not, by itself, determine whether authority already transferred to registered descendants survives. The signed revocation_mode field makes that choice explicit. When a capability's revocation_mode is direct, revoking that capability MUST prevent new reservations and child allocations funded by that capability. It MUST NOT, solely because of that revocation, invalidate a child registered before the revocation committed. The child remains subject to its own validity, scope, budget, direct revocation, and any cascade-mode ancestor. When a capability's revocation_mode is cascade, revoking that capability MUST prevent every descendant from making a new reservation or funding a new child. The enforcement point MUST establish the current revocation state of every authority-bearing cascade-mode ancestor in the same authoritative atomic state domain used for the descendant reservation. A cached status value or eventually consistent notification does not establish immediate cascade revocation. The ancestor revocation transition and a descendant reservation MUST be serialized in that state domain. If revocation commits first, the descendant request MUST refuse. If the reservation commits first, the revocation is late for that operation and prevents later authority claims; it MUST NOT retroactively release the reservation, relabel an effect, or authorize a retry. Any operation whose effect outcome is unresolved remains subject to the reconciliation rules in . If complete current ancestor state cannot be established before reservation, the request MUST refuse without entering the effect adapter. This is a pre-effect status failure, not evidence that an external effect is indeterminate. A deployment using separate state domains or freshness-bounded status distribution MUST NOT claim immediate cascade revocation across those domains. Neither mode grants a grace period after revocation. Continued or wind-down authority MUST be established by a separate authorization with its own exact scope, budget, holder, and validity interval; it MUST NOT be inferred from an in-flight delegation. This document defines the consequence of an authenticated revocation within one state domain. It does not define who is entitled to revoke, how revocation is distributed, or how independently operated domains transfer exclusive admission ownership.

Evidence and Decision Vocabulary A capability receipt can be VERIFIED. A scope verifier can return the profile-local result IN_SCOPE, OUT_OF_SCOPE, or INDETERMINATE. This containment result is not the architecture's MATCH state, which is reserved for correlation of exact material actions. A relying-party evidence requirement can be SATISFIED. Successful local policy and an atomic reservation together can establish AUTHORIZED for one exercise. Separately authenticated effect evidence can establish EXECUTED. No earlier state implies a later one. Portable evidence for a capability-funded operation SHOULD include the capability receipt digest, issuance authorization digest, scope profile and digest, operation ID, the exact exercise action digest and CAID where used, amount, unit, scale, reservation timestamp, terminal outcome, and any authenticated effect statement. The integrity-protected operation record MUST bind the exercise action and the capability receipt digest. Holder secrets and reservation tokens MUST NOT be included. An Authorization Evidence Chain may carry that operation record as a native component whose verifier recursively verifies the capability receipt, issuance authorization, scope result, and operation-record integrity. The static grant is not a same-action component for every later exercise. Evidence satisfaction does not query or reserve current budget; that state transition remains at the enforcement point.

Failure Codes Implementations SHOULD expose stable, non-authorizing failure codes including:

capability_untrusted_issuer
capability_authorization_mismatch
capability_scope_mismatch
capability_scope_indeterminate
capability_holder_proof_invalid
capability_not_active
capability_expired
capability_revoked
capability_revocation_mode_invalid
capability_ancestor_revoked
capability_ancestor_status_unavailable
capability_budget_exceeded
capability_delegation_lineage_invalid
capability_delegation_not_narrowed
capability_operation_replay
capability_reservation_owner_mismatch
capability_reservation_expired
capability_commit_indeterminate

A failure code is diagnostic output, not an authorization artifact. Responses SHOULD avoid revealing secret, budget, or scope details to an unauthenticated caller.

Conformance A conforming implementation MUST pass positive and adversarial vectors for receipt canonicalization and signature, authorization-digest substitution, untrusted issuer, unknown scope profile, action mismatch, holder-proof failure, duplicate registration, concurrent overspend, operation replay, wrong reservation token, double commit, expiry, a cycle spread across separately signed receipts, repeated ancestors, leaf-as-ancestor, missing or truncated lineage, reordered or substituted parent links, parent-receipt and delegation-operation substitution, a single-hop child exceeding the authenticated delegated amount, unit or scale changes, scope or validity widening at every hop, over-depth chains, parent over-allocation, crash recovery, and indeterminate-effect charging. The conformance set MUST exercise revocation inheritance over a root, child, and grandchild. It MUST show that direct-mode revocation leaves previously registered descendant authority independently usable, while cascade-mode revocation refuses every later descendant reservation and child allocation. It MUST reject a missing or unknown revocation_mode, refuse when required ancestor state is unavailable, and cover a race between ancestor revocation and descendant reservation in which exactly one transition commits first. A reservation that commits first remains owned and reconcilable; a revocation that commits first prevents the reservation. The conformance set MUST also include multiple executor participants sharing one domain, an independent-store state fork, and a scope restricted to one executor; only the shared-domain case may claim one aggregate budget. The scope-profile conformance set MUST show exact CAID equality and non-strict subset attenuation, including unchanged parent and child sets. For a profile whose relation is mechanically checkable, it MUST enumerate the complete declared finite domain and test reflexivity and transitivity. It MUST also include a relation that passes every adjacent hop but fails transitivity, and demonstrate that the verifier labels those hop results local-only and refuses to claim chain-wide non-widening. An asserted-transitive profile MUST NOT be reported as demonstrably transitive. The set MUST cover both a verifier-performed enumeration and reliance on an authenticated prior conformance run, and MUST refuse chain-wide promotion when that prior record is unavailable, invalid, or does not cover the complete declared finite domain. The conformance set MUST include an authenticated prior record that differs from the current evaluation in the profile or rule content digest, complete-domain encoding, digest algorithm, digest or cardinality, or deterministic procedure identifier, version or content digest, and demonstrate that every such mismatch prevents chain-wide promotion. It MUST show that a stale record contributes no current local result, while a separately executed current comparison can still be reported local-only. It MUST also demonstrate that a matching prior record can support chain composition without repeating the enumeration, subject to relying-party policy. The conformance set MUST reject an establishment record from an authenticated but untrusted runner, a record using the same mutable version label over different profile or rule content, a chain value outside the mechanically enumerated domain, and a multi-hop chain whose adjacent comparisons use different relations that are each independently transitive. It MUST demonstrate that a local-only multi-hop result cannot establish descendant authority. The conformance set MUST cover a crash between issuance-authorization consumption and root-capability registration, an exact retry that resolves to the existing capability, and a conflicting retry that refuses. It MUST also show that authenticated proof of provider non-entry restores reserved budget while retaining a terminal replay tombstone, and that the same raw operation ID under a different capability is not by itself a replay. Reservation-lifetime cases MUST show refusal of provider entry at the deadline, recovery of an abandoned pre-entry reservation after the deadline, and successful terminal accounting after capability expiry for an operation whose provider entry was recorded beforehand. A split-domain root registration case MUST identify and exercise its concrete reconciliation profile; without one, the case MUST refuse the split deployment. The conformance set MUST reject a holder preimage of the wrong length or digest, and MUST demonstrate that a captured valid preimage does not bypass scope, budget, status, validity, operation replay, or provider-entry-deadline checks. It MUST also reject an amount-and-scale combination outside the operating range declared by the selected profile. For ed25519-operation-proof, it MUST include a valid proof and mutations of the public key, capability digest, operation ID, action digest, amount, unit, scale, audience, and state-domain digest; every mutation MUST refuse. It MUST also refuse a portable threshold other than m=1, n=1 for that method. The parent-over-allocation case MUST include at least three sibling child-creation attempts whose individually valid amounts collectively exceed the parent's available balance, with concurrent reservation ordering chosen by the implementation. At most a balance-preserving subset may commit. The case MUST also cover one operation identifier presented for two different child receipt digests and an orphaned child-registration failure after parent commitment. The former refuses as operation replay; the latter leaves the committed parent amount consumed pending reconciliation. A wire-format implementation that does not implement one shared atomic store is a receipt verifier, not a conforming spend-control implementation. A store implementation that accepts a capability without pinned issuer verification, issuance authorization, and scope matching is not conforming.

Relationship to Other Work Rich Authorization Requests carries fine-grained authorization details but deliberately leaves comparison semantics for arbitrary detail types to their specifications. This document defines an executor-side durable spend state machine and requires a named closed scope profile. OAuth Transaction Tokens propagate transaction-specific authorization context through a call chain. Bounded Capability Receipts instead address an aggregate budget shared across multiple operations and the reserve/commit boundary at the executor. A deployment can use both. The Delegation Receipt Protocol for AI Agent Authorization records delegation and narrowing. This document requires narrowing for child capabilities and additionally accounts delegated budget as a terminal parent spend. Attenuating Authorization Tokens for Agentic Delegation Chains describes constrained, attenuable agent tokens. This document's distinct contribution is not the existence of constrained tokens; it is the composition of a signed grant with shared reservation ownership, committed budget accounting, and conservative treatment of indeterminate external effects. The Agent Identity Protocol defines per-token budget ceilings and explicitly assigns cumulative spending enforcement to the orchestration runtime. A bounded capability budget is instead a balance-valued authority in one authoritative store: reservation and consumption reduce the amount available to every sibling allocation in that domain. PEDIGREE defines cryptographic delegation, mandate narrowing, and an operator-controlled ceiling. This document preserves that identity and policy role and addresses the adjacent runtime question of how one parent balance funds multiple children without multiplying aggregate authority. The Credential Broker for Agents defines proxy and short-lived-token delivery patterns that keep long-lived provider credentials away from agents. A deployment can use such a broker as the credential-owning effect adapter after this protocol grants one valid reservation; this document does not duplicate credential brokering. Condition-Bounded Credentials binds workload-key use to live, verifier-appraised conditions. That property composes with holder proof and provider entry, especially for stable attestable workloads. It does not replace aggregate balance accounting, and this document does not extend its hardware assumptions to hardware-less or cross-domain swarms. The affine Token Budgets work studies LLM cost overruns and uses Rust ownership to prevent cloning and use-after-delegation in one process. It is adjacent prior art. This document instead binds human- or policy-authorized consequential authority, exact exercise actions, durable provider-entry reservations, and conservative post-entry uncertainty across a transactional runtime. It does not claim that balance-valued budgets or affine ownership were invented here. The Attested Payment Authorization for Autonomous Agents binds an attested payment key and endorsed software identity to a payment authorization scope and requires verification before settlement. It is adjacent and complementary work: this document does not define hardware attestation or transparency registration, while that document does not specify the authoritative shared-state, reserve-and-commit, parent-funded delegation, and post-entry uncertainty machinery defined here. A deployment can compose the two by binding their decisions to the same exact exercise-action digest without making either verifier consume the other's evidence as a trust anchor.

Security Considerations Identifier substitution. Capability signatures bind the full issuance authorization digest, not only an identifier. Scope, budget units, parent, holder commitment, and validity are all inside the issuer signature. State forks. Two stores accepting the same capability lineage can each spend or delegate its full budget. Global offline or cross-domain double-spend prevention is therefore not provided. Deployments that cannot name one authoritative atomic state domain for a capability and every authority-bearing ancestor and descendant MUST NOT claim aggregate sibling conservation or an enforced aggregate budget. Executor federation. A multi-rail or multi-process deployment does not, by itself, establish a shared budget. Every executor that can admit an exercise must be bound to the same state domain, or the scope must be restricted to one executor and the claim must be stated as per-executor. Eventual reconciliation after independent admissions cannot retroactively prevent overspend. Crash ambiguity. Restoring budget after a timeout can authorize duplicate external effects. Once the effect boundary may have been crossed, uncertainty is charged as indeterminate. Reservation lifetime and expiry. An unbounded pre-entry reservation permits durable capacity denial and creates ambiguous expiry behavior. The provider-entry deadline bounds that state. Expiry prevents new provider entry but does not erase or reopen an attempt that entered before expiry; that attempt remains terminally accounted. A store that cannot serialize deadline recovery against provider entry MUST NOT restore the budget. External predicate freshness. Reservation protects the bounded budget; it does not make mutable world facts current. If an action depends on a record, counterparty status, market condition, or other external predicate that can change after scope evaluation, the deployment MUST require freshness-bound live evidence or re-evaluate that predicate in boundary policy before provider entry. A short reserve-to-effect interval reduces exposure but is not a correctness mechanism. If the re-evaluation refuses before provider entry, budget may be restored only through the authenticated not_entered transition in . Operation-key scope. Operation IDs are unique under one capability receipt rather than globally attacker-reserved across the state domain. The store MUST bind the capability receipt digest and operation ID as one operation key. Preventing the same material action from being admitted under two independently valid capabilities is a separate relying-party policy and action-fencing concern. Replay refusal in this document means refusal of an already-seen operation key. It does not prohibit two otherwise authorized operations with different operation IDs from carrying the same action digest. A deployment requiring one occurrence per material action MUST add a durable action fence or bind a unique occurrence identifier into the material action. Bearer and share theft. A raw holder secret or enough unauthenticated shares can authorize possession and every remaining in-scope operation. Confidential transport does not protect against an enforcement point, endpoint, or log that leaks the reusable preimage. Secret shares require confidential distribution, authenticated participants, compromise response, and rate limiting. Deployments that require non-exportable custody need a separately defined signature- or hardware-bound holder profile. The built-in ed25519-operation-proof prevents a reusable bearer secret from crossing the boundary, but protection of the signing key and resistance to signing-oracle abuse remain deployment responsibilities. Threshold custody is not human quorum. Revocation. Expiry and exhausted budget are not revocation. A deployment that requires early invalidation MUST consult a separately authenticated revocation or status source before reservation and define its freshness policy. Revocation inheritance is not inferred from lineage alone: the signed mode determines whether already transferred descendant authority survives. An immediate cascade claim requires the ancestor revocation transition and descendant reservation to be serialized in the same authoritative atomic state domain. Notification or eventual cache refresh cannot supply that guarantee. Full-lineage locking can make a high-fan-out ancestor a contention and denial-of-service hot spot; deployments MUST bound lineage depth, admission work, and lock acquisition time without weakening the fail-closed result. Units and arithmetic. All accounting uses integers with signed unit and scale. Floating-point arithmetic, implicit currency conversion, and caller-selected rounding MUST NOT occur in the authoritative budget path. The safe-integer ceiling and decimal scale jointly limit range; a high scale does not provide both arbitrary precision and arbitrary major-unit magnitude. Database authority. The capability tables contain authorization state. Deployments MUST restrict writes to the enforcement service, use least-privilege credentials, protect backups, and audit administrative changes. Delegation lineage. Local uniqueness checks over one presented receipt do not establish graph-wide acyclicity or complete ancestry. Separately presented receipts can omit links, substitute a parent operation, or form a cycle unless each parent edge is authenticated and resolved by digest, or an authoritative store enforces equivalent edge constraints. Implementations MUST fail closed on incomplete, cyclic, substituted, or non-narrowing lineage. Verifiers apply the complete traversal and refusal rules in to imported chains and chains reconstructed from storage. Comparison-proof substitution and exhaustion. A signed conformance record from an untrusted runner does not establish a relation property. Profiles that permit mechanical establishment MUST bound domain cardinality and procedure work, define one canonical domain encoding, and reject values outside the established domain for chain-composition purposes. Implementations MUST apply bounded parsing before processing a presented record and MUST NOT perform attacker-sized enumeration on the admission path. Semantic limits. A valid capability does not prove that an action is safe, lawful, beneficial, or correctly executed. Local policy and domain controls remain necessary. Cryptographic scope. This version uses SHA-256 and Ed25519. It does not provide a post-quantum signature profile or a zero-knowledge receipt. Algorithm agility and long-term preservation are separate concerns.

Privacy Considerations Capability receipts and operation records can reveal spending limits, organizational roles, intended action classes, counterparties, and timing. Profiles SHOULD minimize identifiers, separate portable evidence from operational secrets, and define retention and access controls. Hashing a low-entropy scope or identifier does not make it confidential.

Implementation Status The Apache-2.0 TypeScript reference implementation includes a signed pre-standard capability envelope, holder-secret commitment, optional threshold secret reconstruction, and a durable PostgreSQL reservation and commitment store. Its issuer-controlled delegation API, when used with one shared capability store, reserves and commits a child amount from the immediate parent before registering the child. Both the in-memory and PostgreSQL stores record a provider-entry deadline bounded by capability expiry, refuse late provider entry, retain an explicit provider-entry marker, and recover a timed-out pre-entry reservation as not_entered without deleting its operation record. The store has adversarial tests for overspend, replay, ownership fencing, expiry, terminal commitment, concurrent N-sibling aggregate over-allocation, one operation identifier paired with different child digests, orphaned registration after parent commitment, and an explicit two-store state-fork counterexample. These are same-team implementation and regression results, not independent implementation or production deployment evidence. The prototype wire format predates this document and does not yet implement all mandatory fields in this version, including full issuance authorization digest binding, an explicit action-scope profile, and explicit budget unit scale, digest-linked parent lineage, authenticated parent-delegation binding, not_before, and complete ingest-time cycle validation. It is therefore implementation experience, not a claim of conformance. There is no independent implementation, interoperability event, production transaction history, post-quantum profile, or zero-knowledge implementation. The executor-domain participant binding and per-action human-authorization composition added in -02 are protocol requirements and composition rules. The reference execution path now implements those two integrations: an aggregate budget claim requires an exact match to a relying-party-pinned atomic state-domain digest; a mismatch may fall back only to an explicitly pinned single executor; and a required per-action human authorization must pass a native verifier under relying-party pins and bind the exact exercise-action digest. Calls without an executor-domain binding are labeled local_store_only and do not claim aggregate enforcement. A configured state-domain digest is a deployment trust binding; the code cannot by itself prove that two processes connect to the same physical database. The reference implementation now signs and requires revocation_mode, records each capability's immediate parent, and implements direct and cascade revocation in both the in-memory test store and PostgreSQL store. A descendant reservation resolves the complete registered ancestor lineage. The PostgreSQL path locks those state rows in the reservation transaction, so an ancestor revocation that commits first refuses the reservation, while a reservation that commits first remains owned and reconcilable. Missing, malformed, or migration-incomplete ancestor state refuses before provider entry. The tracked migration quarantines legacy rows without an explicit mode rather than inferring direct or cascade. Regression cases cover the signed closed field, direct descendant survival, cascade refusal, unavailable ancestor state, child allocation after revocation, and both orderings of the revocation race. This is same-team implementation evidence inside one authoritative atomic state domain; it is not independent interoperability, revocation distribution, or cross-domain cascade enforcement. The -04 scope-profile contract and comparison-reporting rules are not yet implemented. In particular, the reference implementation does not yet emit per-component decidability records, relation reflexivity, transitivity classification or basis, mechanical-establishment provenance, or the local-only versus chain-composable result. No implementation or conformance claim is made for those additions. The -04 atomic root-issuance registration rule is also not implemented as a conforming protocol operation because the prototype does not yet bind and consume the full issuance authorization described here. The capability-scoped operation key and terminal budget-restoring not_entered behavior are implemented in the reference stores, but that implementation evidence does not close the other -04 gaps. The ed25519-operation-proof holder method is not yet implemented by the reference capability API; no implementation claim is made for it. The reference implementation does reject repeated delegation identifiers, repeated parent capability identifiers, a leaf named as its own parent, and increasing amounts within the delegation chain presented at mint or verification time. Those checks provide local simple-path and monotonic amount enforcement. They do not discover omitted parents or establish the digest-linked, graph-wide lineage required by , so they do not close the remaining conformance gap. The public repository contains two CI-gated bounded TLA+ models relevant here. The capability-accounting model covers registration, reservation, commitment, delegation, replay refusal, parent-funded child registration, and aggregate sibling conservation. A separate -03 revocation-inheritance model covers every direct/cascade assignment over a root, child, and grandchild; complete ancestor-state availability; future child allocation; and both serialized orderings of revocation and reservation. Exact state and obligation counts are emitted by governed proof-status artifacts. These are bounded results about the models, not refinement proofs of the TypeScript, SQL, transaction adapter, cryptography, lineage verification, or complete protocol defined here. Arbitrary implementation inputs still require the runtime traversal and refusal rules in . The main branch also runs a fixed-seed adversarial harness in per-push CI over the actual JavaScript in-memory capability and consumption stores. It includes a true-concurrency Promise.all race target and a deliberately non-atomic comparison store that demonstrates the race detector can expose over-commitment. Additional targets exercise accounting and ownership invariants at whole-method boundaries. This is regression evidence for those in-process stores, not complete protocol conformance: it does not fuzz the PostgreSQL capability transaction path, the atomic handshake RPC, replica or connection failures, and no deeper nightly sweep is scheduled.

Changes Since -03

Defined the mandatory CAID-set scope relation and required profiles to state reflexivity, transitivity, and the basis for transitivity.
Prevented local hop comparisons from being promoted into a chain-wide non-widening claim without a definition-derived or mechanically established transitive relation.
Required one immutable comparison context across every hop used for chain composition and prohibited local-only multi-hop evidence from establishing descendant authority.
Required mechanical-establishment provenance, including whether the deciding verifier ran the complete enumeration or relied on an authenticated prior conformance run.
Bound prior-run applicability to the exact profile, rule, complete domain, and procedure selected for the current evaluation; stale records now contribute no current comparison result.
Added relying-party trust of the conformance runner, complete-domain membership, immutable semantic pins, and resource bounds.
Made operation identity capability-scoped, defined terminal not_entered restoration with a retained replay tombstone, and made issuance consumption plus root registration one idempotent logical operation.
Separated bounded-budget reservation from freshness of mutable external predicates.
Bounded pre-entry reservation lifetime, defined expiry-versus-commit behavior, and required a concrete profile for split-domain root registration reconciliation.
Made bearer-secret exposure, cascade-lineage contention, and the safe-integer amount/scale range explicit.
Defined an Ed25519 operation-bound holder proof alongside the mandatory preimage interoperability baseline.
Clarified that reliance on an authenticated matching prior run is deliberately permitted and remains subject to relying-party policy.

Acknowledgments The author thanks Sumit P. Ahuja for the scope-comparison analysis that led to the transitivity-basis, mechanical-establishment provenance, and chain-composition requirements in .

IANA Considerations This document has no IANA actions. A future revision may request a media type and registries for receipt versions, scope profiles, holder methods, and failure codes after implementation experience stabilizes the protocol.