EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

Security agent authorization capability spend control delegation Agents sometimes need bounded authority to perform more than one consequential action without obtaining a new human approval for every operation. A signed token alone cannot enforce a shared budget across replicas, survive retries safely, or distinguish an operation that never crossed an effect boundary from one whose outcome is unknown. This document defines a bounded capability receipt and a durable reserve-execute-commit protocol. The receipt binds an issuance authorization, a closed action scope, a budget with explicit units, a holder proof, an expiry, and any parent capability. The state protocol atomically refuses overspend and replay, fences concurrent owners, and charges an indeterminate operation when an external effect may have occurred. Delegation transfers rather than copies authority: all direct child allocations are funded by committed parent operations before child registration, and their aggregate cannot exceed the parent balance within one authoritative atomic state domain. It also defines narrowing-only delegation and evidence interfaces. It does not make a bearer token into human approval, does not provide cross-domain or offline global double-spend prevention, and does not claim that an authorized action was safe, lawful, or successfully executed.

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:

1. a signed capability receipt that states the immutable authority boundary; and
2. 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.

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.

Operation ID:

A globally unique identifier for one attempted capability-funded operation within a capability-store domain.

Reservation token:

An unguessable owner-fencing value returned by a successful reservation and required for its commitment.

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, suspend, 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.

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.

holder:

A recognized holder-proof method and 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.

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, and validity interval. 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:

1. apply bounded parsing and reject duplicate JSON member names, unknown critical versions, malformed encodings, and out-of-range values;
2. select the issuer key from relying-party configuration, not from the presented object alone;
3. verify the issuer signature over the exact signature input;
4. natively verify the issuance authorization under its own pinned trust inputs and compare both receipt identifier and digest;
5. verify that the authorized action is issuance of this exact capability object, or of a digest that commits to it;
6. verify the scope digest and require a recognized, relying-party-enabled scope profile;
7. 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
8. 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, 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.

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. 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, comparison, unknown-field handling, numerical units, and an algorithm for proving that a delegated scope is no broader than its parent. 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. 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, 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. 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, globally unique operation ID, 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. In one serializable transaction, or while holding an equivalent row lock, the store MUST:

1. load the registered capability and compare the receipt digest;
2. reject an unknown, not-yet-valid, expired, or revoked capability;
3. reject a unit or scale mismatch;
4. reject any already-seen operation ID, regardless of its previous capability or outcome;
5. verify that the amount is positive and no greater than total - consumed - reserved;
6. increase reserved by the amount; and
7. create an operation in state reserved with an unguessable reservation token, exercise-action digest, and amount, 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.

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.

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.

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, and validity interval 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.

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_budget_exceeded
• capability_delegation_lineage_invalid
• capability_delegation_not_narrowed
• capability_operation_replay
• capability_reservation_owner_mismatch
• 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 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 records delegation and narrowing. This document requires narrowing for child capabilities and additionally accounts delegated budget as a terminal parent spend. OAuth Attenuating Tokens for Agentic AI 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.

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. 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. Bearer and share theft. A raw holder secret or enough unauthenticated shares can authorize possession. Secret shares require confidential distribution, authenticated participants, compromise response, and rate limiting. 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. 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. 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. 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. 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 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 also contains a CI-gated TLA+ model of capability registration, reservation, commitment, revocation, delegation, replay refusal, parent-funded child registration, and aggregate sibling conservation. The checked configuration contains one root, three possible children, three delegation operation identifiers, bounded amounts, bounded depth, and a bounded clock. Exact state and obligation counts are emitted by the governed proof-status artifact. This is bounded evidence about the model, not a refinement proof of the TypeScript, SQL, transaction adapter, cryptography, lineage verification, or complete protocol defined here. A separate repository witness module contains five reachability checks but is not executed by the CI workflow and is not represented as proving every assertion non-vacuous. The model obtains delegation acyclicity through its construction rules; arbitrary implementation inputs still require the explicit 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 -00

• Extended the mandatory atomic state domain from participants authorizing one identifier to the full authority-bearing capability lineage.
• Made parent reservation and exactly-once commitment before child registration explicitly normative.
• Stated aggregate direct-sibling conservation and injective operation-to-child binding in one place.
• Defined the concurrent N-sibling, replay-with-different-child, orphaned-registration, and cross-domain state-fork cases.
• Added precise relationships to AIP, PEDIGREE, CB4A, Condition-Bounded Credentials, and affine token-budget work without changing the receipt wire format or failure-code vocabulary.

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.

References Normative References Internet Engineering Task Force Informative References