EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

sec AI agents human authorization binding evidence A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" — an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference — and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification.

Introduction Record formats for agent actions are proliferating, and almost all of them make the same, sound scoping decision: human authorization is somebody else's format. The result is a set of reserved-but-empty slots. A post-execution action capsule carries an approver disposition whose authority is opaque; a pre-execution permit stubs an authority context; audit-trail records carry a human-override field with a privacy carve-out where the human should be; a provenance graph has an optional actor; an audit architecture requires a "signed grant" whose format is an unassigned work item; an intent chain names an approval reference with no semantics. Each slot is an invitation. Eleven invitations with eleven ad-hoc answers would be worse than none. This document is the single answer: a host-agnostic definition of what it means to bind named-human authorization evidence into any record, plus the small set of requirements that keep the binding trustworthy regardless of host. The reserved slots this profile serves appear, at this writing, in draft-mih-scitt-agent-action-capsule, draft-munoz-scitt-permit-profile, draft-sharif-agent-audit-trail, draft-bates-atp, draft-aylward-aiga, draft-nelson-agent-delegation-receipts, draft-rosenberg-aiproto-cheq, draft-yossif-psea, draft-kuehlewind-audit-architecture, the ACP charter, and the SPICE-adjacent intent-chain work — the mappings in are offered for those authors to correct or adopt. It deliberately does not define the authorization evidence itself — a bound artifact verifies under its own specification (for example for named-human receipts and quorum) — and the appendix mappings to host formats are informative descriptions of public slot fields, offered for host authors to correct or adopt.

Terminology 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. Host record: any signed or logged record about an agent action that carries the binding (a capsule, permit, audit record, provenance node, token, or chain). Authorization artifact: the evidence being bound (a named-human authorization receipt, a quorum receipt, or an equivalent artifact defined elsewhere).

Binding by Reference The reference form is a JSON member (claim name "human_authorization_ref"; see ) carried anywhere in the host record the host format designates: ", "format": "ep-receipt | ep-quorum | ", "locator": "" } ]]> The digest MUST be computed over the authorization artifact's canonical bytes as defined by the artifact's own specification (for EP artifacts, the JCS I-JSON profile). The locator is a hint only: a verifier obtains the artifact through whatever channel the deployment provides, and relies on digest equality, never on the channel. The reference form supports disclosure minimization: a host record can travel without the artifact, and a relying party that requires the evidence fails closed until the bytes are produced.

The Embedded Claim The embedded form carries the evidence inline as a compact, self-describing claim (claim name "human_authorization"): ", "mode": "single | quorum", "approvals": [ { "approver": "", "role": "", "key_class": "A | B | C", "signoff": { "...the approver's own signature object..." } } ], "policy": "", "quorum": { "required": 2, "distinct_humans": true, "ordered": false } } ]]> Each approval names an accountable human principal and carries that principal's own signature over the action binding, verifiable offline under the artifact specification the claim profiles. When mode is "quorum", the distinct-humans and ordering semantics of apply: the required number of DISTINCT accountable humans, not merely distinct signatures. Key classes classify key custody as defined by the receipts specification and imply nothing about assurance levels.

Binding Requirements Five requirements hold for every host, and they are what make the binding mean the same thing everywhere:

1. B1: Digest grounding. A binding is credited only against artifact bytes: the reference form by digest equality, the embedded form by verifying the contained signatures. A host field that merely asserts "a human approved" without either MUST NOT be treated as human-authorization evidence.
2. B2: Action agreement. When the host record binds an action (via an action digest, a subject digest, or equivalent), the authorization artifact's action binding MUST agree with it. An artifact authorizing a different action MUST invalidate the binding, not merely weaken it.
3. B3: Verified versus accepted. Verifying the binding (digests and signatures hold) is distinct from accepting it (the relying party trusts the artifact's issuer via out-of-band pinned key material). A verifier MUST report the two separately, and a binding from an unpinned issuer MUST NOT be accepted.
4. B4: Fail-closed absence. The absence of a binding is the absence of evidence, never a default. A relying party whose policy requires human authorization MUST treat an unbound or unresolvable binding as insufficient. Absence becomes positive evidence only through a signed observed-absence statement naming the search performed.
5. B5: Consistency. When a host record carries both forms, the embedded claim's canonical bytes MUST hash to the reference's digest; a mismatch invalidates both.

Expression for SCITT Signed Statements Transparency-logged agent-action statements (SCITT : capsules, permits, audit records) are the binding's most developed host family, and their expression is specified here concretely. The reference form's digest is one of the following, selected per deployment and FIXED for a given host-statement profile so that both sides bind identical bytes:

• receipt_payload_digest — SHA-256 over the JCS canonical bytes of the authorization receipt's payload; used for offline composition, where the relying party holds or can fetch the receipt directly.
• statement_digest — SHA-256 over the COSE_Sign1 bytes of the receipt expressed as a SCITT Signed Statement; RECOMMENDED when the receipt is registered in a transparency service, so the reference also resolves to a logged, inclusion-proofed entry.

The COSE encoding of the receipt as a Signed Statement (canonical payload, content type) is the EP SCITT profile's job and out of scope here: this section specifies only the digest a host statement embeds and the verification that B1-B5 already require. A host profile defines its own concrete carrier (a dedicated field, a capsule's opaque authority reference, a permit's authority context); this document mandates the digest semantics, never the carrier's name. The verifier obtains the receipt through whatever channel the deployment provides — held locally, conveyed with the statement, or fetched from the transparency service — and relies on digest equality, never on the channel.

Denial, Absence, and Observed Absence B4 (fail-closed absence) has one elaboration worth stating normatively for this host family, because settlement and audit flows rely on refusals as much as approvals. Three states, only two of which are evidence: a DENIAL (a named human refused, an approval was revoked, or a validity window lapsed and the expiry was recorded) is a signed event, and a host statement MAY reference a denied authorization exactly as it references an approval — "an accountable human refused this action" is a positive, verifiable fact. ABSENCE is not evidence and cannot be made so by assertion: the mere failure to present an authorization proves nothing. Absence becomes positive evidence only through a signed OBSERVED-ABSENCE statement — an attestation that the verifier performed a defined search against defined sources at a stated time and found no qualifying authorization; it attests the search and its emptiness, never a universal negative. A deterministic observed-absence vector ships with the reference implementation (examples/scitt/observed-absence-vector.mjs).

Claim Naming The canonical claim names are "human_authorization_ref" and "human_authorization". The claim was first deployed under the vendor-prefixed name "ep_human_authorization"; implementations SHOULD accept it and MUST treat it as an alias of the embedded form. Host formats that already name their slot (an authority context, an actor, an approval reference) MAY carry the binding object under their own member name; the object's members, not the slot's name, are what this document defines.

Security Considerations The slot is a target. An attacker who can fill a host record's authorization slot chooses what a relying party later treats as the human's approval; every defense here exists for that reason. B1 removes assertion-only filling; B2 defeats splicing a genuine artifact from a different action (the confused-deputy case); B3 prevents a self-issued artifact from being self-accepted; B4 prevents silence from being read as consent; B5 prevents the two forms from telling two stories. Replay and one-time-use semantics belong to the authorization artifact and its enforcement point; a host record MUST NOT extend an artifact's validity by carrying it. The reference form additionally serves privacy: the named human travels only in the artifact, which can be withheld until a relying party with a need to know requires it — at the cost, by B4, of the evidence not counting until produced.

IANA Considerations This document has no IANA actions. Registration of the claim names in the JWT and CWT claims registries is anticipated for a future revision, after host-format feedback.

References Normative References Informative References EMILIA Protocol, Inc. EMILIA Protocol, Inc.

Host-Format Mappings (Informative) The following mappings describe, from each cited document's public text, where the binding fits. They are informative, derived from the revisions named, and offered for the host authors to correct or adopt; absence of a format from this list implies nothing, and no mapping asserts a host author's endorsement.

• draft-mih-scitt-agent-action-capsule-01: a capsule whose disposition reports a human approver carries human_authorization_ref alongside the disposition; B2 binds it to the capsule's action digest.
• draft-munoz-scitt-permit-profile-00: the authority_context member carries the reference form; the permit's decision then rests on evidence, not assertion.
• draft-sharif-agent-audit-trail-00: the human_override field carries the reference form, giving the named-but-privacy-carved human an artifact rather than an inline identity.
• draft-bates-atp-00: a provenance node's actor field carries the reference form; validators add B1-B5 to lineage checks.
• draft-aylward-aiga-00: the reserved X.509v3 extension slot carries the reference digest, binding machine identity to the human authorization behind its issuance.
• draft-nelson-agent-delegation-receipts-10: a delegation receipt carries the embedded claim as a co-signing layer where multi-party approval is required (multi-party is out of the host's scope by its own statement).
• draft-rosenberg-aiproto-cheq-00: the confirmation object's signature, left TBD by the host, is the embedded claim; a quorum of confirmations aggregates under mode "quorum".
• draft-yossif-psea-02: a Verifier's attestation-result object (out of the host's scope) carries the reference form binding the presence proof to the authorization it evidenced.
• draft-kuehlewind-audit-architecture-00: the "signed grant" work item (WI-5) and step-up approval responses are instances of the embedded claim; Authorization Transition Records carry the reference form.
• The ACP (agent communication protocols) charter's "confirmation and evidence requirements for AI agent operations": the confirmation step's evidence is the embedded claim; scoped access tokens carry the reference form.
• SPICE-adjacent intent chains: the approval_ref member is the reference form's digest, giving the named field its missing semantics.

One adjacent family fits differently and deserves saying precisely. WIMSE workload credentials (WIT/WIC, and the WPT request binding) do not reserve a human-authorization slot; their working group is deliberately chartered for workload identity and explicitly does not define personal identities. They are, however, carry-capable: a WIT or transaction context is a JWT, and a deployment MAY carry human_authorization_ref as a claim alongside the workload identity — the workload credential then proves WHICH WORKLOAD is calling and proved possession, while the bound artifact proves WHICH ACCOUNTABLE HUMAN authorized the exact action it is about to perform. The two answers have different trust roots (a workload key versus a named human's key under organizational authority), which is why neither format can absorb the other and why the composition, rather than either alone, is what a relying party needs for an irreversible action.

Implementation Status The embedded claim profiles a shipped format (the EP receipt and quorum artifacts, three-language verifier suite with shared conformance vectors in one repository). The binding checks (digest grounding, action agreement, verified-versus-accepted, fail-closed absence) are exercised by the reference implementation's evidence-graph layer and by a deterministic binding vector published with the repository (examples/binding/human-authorization-binding-vector.mjs).