EMILIA Protocol (EP) is an open standard for binding actor identity, authority, policy, and exact action context into a single cryptographic ceremony — before any high-risk action is allowed to proceed.
Most authorization systems verify who is acting. EP verifies whether this specific action should be allowed to proceed right now, given the full context of who is asking, what authority they hold, and what policy governs the decision.
Every EP ceremony follows the same disciplined flow.
Each ceremony transitions through a deterministic set of states. No ambiguity, no undefined behavior.
Actor identity. Authority chain. Exact action context. Policy version and hash. Nonce and expiry. One-time consumption. Immutable event traceability. Every ceremony. No exceptions. The eighth property — accountable signoff — applies whenever policy requires named human ownership.
Cryptographically verified identity of the entity requesting the action.
Complete delegation path from root authority to the acting principal.
The precise operation, target, parameters, and environmental conditions.
Immutable reference to the exact policy version that authorized this action.
One-time cryptographic nonce and strict temporal bounds on authorization.
Each ceremony token is consumed on use — no replay, no reuse, no ambiguity.
Append-only audit trail linking every authorization to its outcome.
Named human responsibility for the exact action, cryptographically bound to the ceremony.
EP Core v1.0 (authorization receipt, Trust Profile, Trust Decision) is frozen. Changes require a Protocol Improvement Proposal, 90-day review, and major version bump with 24-month deprecation. Extensions are added without touching Core.
Every consequential-action check EP makes is the same shape: a signed, offline-verifiable receipt carried in one envelope (EP-ENVELOPE-v1), dispatched by a profile. A single verifier handles them all — and a profile can only add a rejection, never weaken a shared check. Adding a new high-stakes action isn’t a new product; it’s a new row in the registry.
The registry is content-addressed and published at /.well-known/ep-profiles.json — verifiable offline, no call home. EMILIA hosts a mirror, not a trust root: the reserved private-use namespace urn:ep:profile:x-<vendor>:* lets anyone publish a profile without asking permission. That is how a toolbox becomes a standard — COSE did it for signing, MIME for content, Sigstore for trust.
EP rolls out in four phases. Most pilots begin in OBSERVE for 2–4 weeks to generate the “what would have been blocked” report before flipping to enforce.
Observe, shadow, then enforce. Eye runs alongside existing workflows — logging first, flagging without blocking, then enforcing full ceremony when ready.
Policy-bound pre-action trust enforcement. Canonical binding, replay resistance, one-time consumption. Seven properties verified before execution proceeds.
Named human ownership when policy requires it. Not MFA. Cryptographically bound, action-specific accountability before execution.
Atomic write to the immutable audit chain. Handshake consumed, signoff consumed, event chain sealed. Execution released. Cannot be undone.
EP has formal compliance mappings for 38 NIST AI RMF subcategories across all four functions (GOVERN, MAP, MEASURE, MANAGE) and EU AI Act Articles 9–15 + 26. SOC 2 Type II preparation is underway. Every mapping cites specific EP primitives — not aspirational claims.
Across GOVERN, MAP, MEASURE, MANAGE — see docs/compliance/NIST-AI-RMF-MAPPING.md
High-risk AI systems (Title III, Chapter 2) — see docs/compliance/EU-AI-ACT-MAPPING.md
Auditor selection in progress
EP is Apache 2.0 licensed. The spec, the formal verification, and the reference runtime are all public.
New drafts, conformance releases, and reference updates — sent only when there’s something worth your time.
No spam. One email field, nothing else.