EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

sec AI agents authorization receipts composition human oversight JCS A growing family of Internet-Drafts defines signed "receipts" about an AI agent's action: delegation receipts that attest an agent was authorized to act for a principal, policy or permit receipts that attest a policy allowed an external effect, decision and compliance receipts, route authorizations, and human-authorization receipts that attest a named, accountable human approved a specific action. The mature efforts independently converged on a common substrate: bind the action with a canonical digest (JSON Canonicalization Scheme, RFC 8785) and sign it. No specification, however, defines how a relying party verifies that, for one action, the several heterogeneous receipts it has been handed all bind the same canonical action and each verify under their own rules, yielding a single, offline, fail-closed ALLOW or DENY. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and an offline verification algorithm that references existing receipts, checks that every component binds one canonical action digest, dispatches each component to a verifier for its type, and evaluates a fail-closed requirement expression. EP-AEC introduces no new receipt type and replaces none; it is the verifier-side glue that lets independently specified receipts compose into one accountability decision.

Introduction As autonomous and semi-autonomous agents begin to take irreversible external actions -- moving funds, changing records, releasing data, invoking privileged APIs -- relying parties increasingly demand a verifiable artifact answering "was this exact action authorized, and by whom?" The IETF community has responded with a cluster of receipt formats, each answering one facet:

• Identity -- who or what the agent is.
• Delegation -- that the agent was authorized to act for a principal (e.g. , ).
• Policy or permit -- that policy permitted the effect before commit (e.g. , ).
• Decision or compliance -- that a decision or compliance check occurred (e.g. , ).
• Human authorization -- that a named, accountable human, or a quorum of distinct humans, approved the exact action (, ).
• Transparency -- that a statement was registered in an append-only log ().

These are complementary layers, not competitors: a single high-risk action may warrant a delegation receipt AND a policy permit AND a human authorization. Yet each effort defines only its own receipt. The relying party is left to correlate heterogeneous artifacts by hand, and in practice implementers hand-roll ad-hoc "composite proofs" with no shared correctness model -- in particular, no guarantee that the several receipts authorize the same action rather than different ones spliced together (a cross-binding attack). The Entity Attestation Token provides a CBOR mechanism (detached submodules / detached EAT bundles) for composing claims from multiple attesting environments into one token. No equivalent exists for the predominantly JSON/JCS receipt cluster described above. This document fills that gap.

Scope and non-goals EP-AEC defines (1) a composition object that references component receipts and declares a requirement over them, and (2) an offline verification algorithm. EP-AEC does NOT define any component receipt format, does not require any particular component to be present, and does not bless any component specification. It is deliberately minimal: its only novel normative content is the same-action binding check and the requirement evaluation.

Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Action Object

the canonical representation of the external effect being authorized, as defined by Section 3.

Canonical action digest

the SHA-256 digest of the JCS serialization of the Action Object, expressed as lowercase hexadecimal, optionally prefixed "sha256:". The Action Object MUST conform to the I-JSON profile of Section 3 (strings, booleans, null, arrays, objects, and safe integers only) so that the digest is byte-identical across implementations.

Component

one referenced receipt within a chain, carrying a type, the receipt evidence, and an optional human-readable label.

Component verifier

a function that verifies one component and returns both a validity result AND the canonical action digest that component attests it authorized.

Requirement

a Boolean expression over component types/labels that determines ALLOW.

The Authorization Evidence Chain object ", "components": [ { "type": "ep-quorum", "label": "two-person human authorization", "evidence": { ... EP-QUORUM-v1 object ... } }, { "type": "policy-permit", "label": "machine policy permit", "evidence": { ... permit receipt ... } }, { "type": "delegation", "label": "agent delegation", "evidence": { ... delegation receipt ... } } ], "requirement": "ep-quorum AND policy-permit" } ]]>

• "@version" (string, REQUIRED) -- MUST be "EP-AEC-v1".
• "action" (object, REQUIRED) -- the Action Object every component must authorize.
• "action_digest" (string, OPTIONAL) -- if present, MUST equal the canonical action digest recomputed from "action"; a mismatch is a fatal error.
• "components" (array, REQUIRED, non-empty) -- each has "type" (string), "evidence" (object), and optional "label" (string).
• "requirement" (string, REQUIRED) -- a Boolean expression ().

The chain carries the Action Object once; components reference the same action by digest rather than re-embedding it. This is what makes the same-action binding check possible and is the heart of the format.

Verification algorithm A verifier is configured with a set of component verifiers keyed by type. Given a chain C, the verifier MUST proceed fail-closed:

1. If C is malformed (missing "@version", wrong version, missing or non-object "action", empty "components", or missing "requirement"), return DENY.
2. Compute chain_digest = canonical action digest of C.action. If C.action_digest is present and does not equal chain_digest, return DENY.
3. For each component k:
   1. If no verifier is registered for k.type, mark k unsatisfied (reason: no verifier) and continue.
   2. Invoke the verifier on k.evidence. It returns valid and action_digest. Any exception marks k unsatisfied.
   3. k is SATISFIED iff valid is true AND the returned action_digest equals chain_digest. A valid component that binds a different action MUST be treated as unsatisfied (reason: binds a different action). This is the cross-binding defense.
   4. If satisfied, add k.type and k.label (if present) to the satisfied set.
4. Evaluate C.requirement over the satisfied set (). Return ALLOW iff it evaluates true; otherwise DENY.
5. Any unexpected error at any step MUST yield DENY.

The result SHOULD include, per component, whether it verified and whether it was bound, with a reason for any failure, to support audit.

Requirement expressions A requirement is a Boolean expression with the grammar: IDENT matches a component type or label in the satisfied set; an unknown identifier evaluates to false. Implementations MUST evaluate the expression with a bounded parser and MUST NOT use a general-purpose evaluator. Operator precedence is left-associative; parentheses group explicitly. Example: "ep-quorum AND (policy-permit OR delegation)" requires a human quorum plus either a policy permit or a delegation receipt, all bound to the same action.

The human-authorization leg Of the receipt families enumerated in , only the EP human-authorization receipt binds a named, accountable human (or, via , a quorum of distinct humans under separation of duties) to the exact action. Several policy/permit formats reserve a slot for a threshold or multi-party signature but specify no human semantics behind it. EP-AEC lets a relying party require the human leg explicitly (e.g. requirement includes "ep-quorum") while composing it with machine-side delegation and permit receipts. The built-in component verifiers "ep-quorum" and "ep-receipt" are defined by and respectively; all other types are supplied by the relying party.

Security Considerations Cross-binding (action substitution). The core threat is splicing receipts that authorize different actions into one chain. Step 3c of defeats this by requiring every satisfied component to attest the chain's exact canonical digest. The strength of this defense rests entirely on the canonical digest being byte-identical across implementations; the I-JSON profile ( Section 3) is therefore normative. Component verifier trust. A chain is only as sound as its weakest registered verifier and the keys it trusts. Relying parties MUST configure verifiers and trust anchors explicitly; an unconfigured type is unsatisfied, never assumed. Requirement under-specification. A weak requirement yields a weak decision. Requirements SHOULD name every leg the relying party depends on, including the human leg where accountability is required. Freshness and revocation. EP-AEC composes point-in-time evidence; it does not by itself prove the absence of a later revocation. Components that carry status/freshness evidence SHOULD be verified against the relying party's freshness policy. No transport assumptions. EP-AEC is a data structure; it inherits the confidentiality and integrity properties of whatever conveys it. It is fail-closed by construction ().

Relationship to Other Work EP-AEC is complementary to, and composes, the efforts in . It is the JSON/JCS analogue of the EAT detached-bundle composition model and can itself be registered as a SCITT signed statement for transparency. It neither extends nor constrains , , , or ; each plugs in as a component type.

IANA Considerations This document has no IANA actions. A future revision may request a media type (e.g. "application/ep-aec+json") and a registry of component type identifiers should the work be adopted.

Implementation Status A reference verifier and a runnable demonstration (composing a real EP human quorum with a policy-permit leg, and rejecting both a cross-binding attack and a missing human leg) are maintained as open-source software and are exercised offline, with no network dependency, by three independent implementations (JavaScript, Python, Go) that agree on a shared conformance vector set.

Normative References EMILIA Protocol, Inc. EMILIA Protocol, Inc. Informative References IETF SCITT WG