The EMILIA Protocol Architecture: A Human-Authorization and Oversight Evidence Layer for Agentic and Autonomous Systems

Introduction Fifty years of access control answered "who is allowed in?" The dominant actors in software are no longer humans but agents that act on their behalf, and the unanswered question is no longer authentication but authorization at the moment of action: who approved that exact action, before it executed, and can anyone prove it later without trusting the system that produced the record? Today that proof is an operator-controlled log: forgeable, backfillable, and unverifiable by an outside party. Every governing instrument -- the EU AI Act's logging and human-oversight articles, the NIST AI Risk Management Framework, US sectoral controls requiring authorization and separation of duties, cyber and crime insurance conditions precedent, and, for defense autonomy, DoD Directive 3000.09's "appropriate levels of human judgment" -- requires verifiable human authorization and specifies no format for it. EP supplies the format. The architectural thesis is one sentence: no irreversible autonomous action without a verifiable human receipt.

Position in the Agent Stack EP is deliberately narrow in mechanism and broad in reach: it occupies the human-authorization layer and composes downward. Adjacent layers, and the relationship EP takes to each:

Identity -- who the agent is. Workload and agent-identity efforts (WIMSE/SPIFFE, ) authenticate the agent. EP does not re-solve this; it references the identity evidence a decision relied on () and authorizes the action above it.
Delegation -- the agent is authorized to act for a principal. (DRP), OAuth token-exchange / identity-chaining, and agent-grant profiles establish delegated authority. EP composes with these by reference; it does not duplicate them.
Policy / permit -- machine policy allows the effect. Policy-decision and route/permit efforts decide whether an effect is allowed. EP's enforcement point consumes such a decision and records the human authorization that backed it; EP is not the policy engine.
Transparency -- append-only logging. Transparency substrates (SCITT, COSE Receipts, CT-style logs) provide tamper-evident records. EP can anchor to them, but its receipts are self-contained and verifiable offline without a mandatory external log.
Human authorization and oversight -- a named, accountable human approved this exact action. This layer is thin and largely unfilled. It is EP's.

L4 to L7 binding. Because a human authorization is only as trustworthy as the upstream identity/delegation evidence it relied on, EP records that evidence inside the signed authorization context and can enforce its freshness fail-closed. This keeps EP agnostic to which identity or delegation standard prevails while making a stale or unconstrained upstream claim detectable after the fact.

Components EP is a small family of specifications around one primitive. Each makes a distinct, independently verifiable claim; together they form the human-authorization and oversight evidence layer. Component specifications are published as separate EMILIA Protocol Internet-Drafts (draft-schrock-ep-*).

Authorization Receipt -- the core primitive A named human's device-bound signoff over one exact, canonicalized action (JCS, ; Ed25519), producing a Trust Receipt that a third party verifies fully offline. The apex of the layer. Binding the signing key to a specific, named, accountable person is achieved through device-bound user verification together with an identity-binding profile (work in progress), so the authorizing party is a person rather than an opaque key. (draft-schrock-ep-authorization-receipts.)

Quorum -- multi-party human authorization M-of-N approval by distinct humans with ordering and separation of duties -- the cryptographic form of the two-person rule, which a single compromised or coerced approver cannot satisfy alone. (draft-schrock-ep-quorum.)

Enforcement Point -- the Receipt-Required rail The fail-closed gate: a high-risk action is refused (HTTP 428-style) unless a valid, in-scope, unrevoked authorization receipt is present. "No receipt, no execution," expressed as a manifest-driven policy enforcement point. After a permitted action runs, the same point emits a post-execution receipt bound to the authorization, so authorization and execution form one verifiable chain. (draft-schrock-ep-enforcement-point.)

Authorization Evidence Chain -- the composition seam A standard for binding the artifacts of the adjacent layers -- an identity attestation, a delegation receipt, a policy decision, a transparency inclusion proof, and the EP human authorization -- into a single, order-preserving, verifiable evidence record. This is the connective tissue that lets independently produced proofs be checked as one chain. (draft-schrock-ep-authorization-evidence-chain.)

Evidence Record -- long-term, crypto-agile preservation An Evidence Record Syntax-style () renewal chain so a receipt verifiable today remains verifiable after its original algorithms weaken (for example sha256 to sha384), meeting the multi-year retention schedules that regulation imposes on the records EP produces. (draft-schrock-ep-evidence-record.)

Authorization-Posture Advisories Verifiable, scope-bound advisory signals (for example a risk or posture indication) that inform a human approver or a policy decision. By construction an advisory is never itself an authorization: it MUST NOT be the sole gate on an action. This component is Experimental. (draft-schrock-emilia-eye.)

Human-Oversight Profile -- oversight of autonomous action An applicability profile for human-in-the-loop and human-on-the-loop oversight of autonomous and cyber-physical systems, mapping the components above to the human-oversight requirements of the NIST AI Risk Management Framework and, for civilian high-risk systems, EU AI Act Article 14, with DoD Directive 3000.09 as a further applicability. It introduces no new cryptography; it applies the receipt primitive at authorization boundaries. Primary applicability is civilian; defense (DoD 3000.09) and the UN CCW debate are secondary. (draft-schrock-ep-human-oversight-profile.)

Agent Trust Stack -- the composition map An informational map of how the layers compose across efforts -- identity, delegation, policy, transparency, and the EP human-authorization apex -- and the binding points between them. (draft-schrock-ep-agent-trust-stack.)

Crypto-Agility and Post-Quantum An explicit algorithm registry and a hybrid (classical plus post-quantum, for example Ed25519 with ML-DSA) signature mode, so long-lived receipts stay verifiable across the post-quantum transition, with a fail-closed verifier policy. (draft-schrock-ep-pqc.)

Vertical action-type profiles Domain profiles that apply the receipt to a specific irreversible action-type, registered in the EP profile registry. The first is grid curtailment / Proof-of-Curtailment for verifiable demand response. (draft-schrock-ep-grid-curtailment.)

Relationship to Other Work A per-component treatment appears in each component document; see in particular the Relationship to Other Work section of draft-schrock-ep-authorization-receipts, which positions EP against DRP, CIBA, WIMSE, receiver-attested logging, AgentROA/AIIP/CIRP, the Entity Attestation Token (), OAuth Transaction Tokens, and Evidence Record Syntax (). Two recent efforts are worth naming at the architectural level:

Delegation receipts (DRP, ). DRP records a user-signed delegation of a bounded scope to an agent. EP composes with it and is deliberately different: EP binds a named human to the exact irreversible action, per action by default rather than per scope, requires a named human rather than a bare key, and verifies fully offline. DRP delegates the scope; the EP receipt proves a named human authorized the specific act inside it.
Agent Authorization Profile for OAuth (AAP). AAP can express that an action requires human approval but states that the approval itself is out of scope and is not an offline-verifiable artifact. AAP and EP compose cleanly: AAP (or any policy layer) signals that approval is required; the EP receipt is the evidence that a named human gave it.
Agent communication frameworks (for example AIPF, draft-zahed-agent-comm-framework). Such frameworks scope an audit and non-repudiation requirement but defer the mechanism that records and verifies the authorizing party. EP is a concrete fill for that deferred slot.
Decoupled authorization models (an authorization decision point with a standardized input contract). EP's enforcement point consumes such a decision; the EP receipt records the human authorization that the decision point required.

Identity, discovery, and capability-advertisement efforts (WIMSE/SPIFFE, , and DNS- and registry-based agent discovery and capability advertisement) sit below the authorization layer; EP references their outputs and does not duplicate them.

Design Invariants Every component upholds the following, and any profile claiming EP conformance MUST preserve them:

Named human. The authorizing party is a real, accountable person (or a quorum of distinct persons), not a device, wallet, or vendor key.
Exact action. The signature covers the precise canonical action (tool and arguments), not a coarse scope or capability label.
Offline verifiable. A third party verifies the receipt without an account, without contacting the issuer, and without trusting the operator that produced it.
Fail closed. Absent a valid authorization, the action does not execute; absence of a receipt is the anomaly, not the default.
Non-repudiable and tamper-evident. Altering any covered byte invalidates verification; the record survives the issuer's disappearance.
Authorization, not wisdom. EP proves a human authorized the action. It does not prove the human understood it, or that the action was lawful, wise, or proportional. Necessary, not sufficient.

Security Considerations The dominant risk is over-trust: treating the existence of a receipt as proof that an action was legitimate. A receipt proves authorization occurred at a stated scope, currency, and authority -- nothing more. Deployments and downstream representations MUST NOT overstate it. EP proves a key signed; binding that key to the intended natural person is achieved through device-bound user verification and an identity-binding profile (work in progress), and is the explicit boundary of the architecture. Coercion of an authorized human, and a human authorizing an action they did not truly comprehend, are out of scope of the cryptographic guarantees; device-bound user verification and the display-fidelity requirements of the component specifications raise but do not eliminate these. Per-component security considerations are normative in each component document.

IANA Considerations This document has no IANA actions.