EMILIA Protocol

A named human's signed "yes" before an AI agent does anything irreversible — with a receipt anyone can verify offline.

Try it in one line (Claude / Cursor / Cline):

npx -y @emilia-protocol/mcp-server

90-second demo · Quickstart · Agent code walkthrough · Discord

What is EP?

EMILIA Protocol (EP) is a protocol-grade trust substrate for high-risk action enforcement.

EP does not stop at identity. It verifies whether a specific actor, operating under a specific authority context, should be allowed to perform a specific high-risk action under a specific policy, exactly once, with replay resistance and durable event traceability.

EP enforces trust before high-risk action.

EP is not a generic identity platform, not a wallet, and not a social reputation layer. It is protocol infrastructure for binding actor identity, authority, policy, and exact action context before execution.

EP Core consists of three interoperable objects:

• Trust Receipt
• Trust Profile
• Trust Decision

EP Extensions add stronger enforcement for high-risk workflows. The most important extension is Handshake, which binds actor identity, authority, policy, exact action context, nonce, expiry, and one-time consumption into a pre-action authorization flow.

When policy requires named human ownership, EP can also require Accountable Signoff before execution.

The protocol is open. Managed policy, verification, signoff orchestration, monitoring, evidence tooling, and sector-specific packs are optional product layers built on top.

---

The EP stack

• EP Eye — observes and classifies agent behavior (OBSERVE → SHADOW → ENFORCE)
• EP Handshake — cryptographic consent ceremony with 7-property binding
• EP Signoff — named human ownership of outcomes
• EP Commit — atomic, immutable action close

Eye observes. Handshake verifies. Signoff owns. Commit seals.

---

Proof points

Metric	Value
Automated tests	3,430 across 129 files
TLA+ safety properties	20 verified (T1–T20) — TLC 2.19, 2026-04-02 — see formal/PROOF_STATUS.md. 6 additional EP-IX properties (T21–T26) specified, model run pending.
Alloy relational assertions	32 facts, 15 assertions — Verified (Alloy 6.1.0, 2026-04-02)
Red team cases	85 cataloged in docs/conformance/RED_TEAM_CASES.md
Security findings remediated	31
CI quality gates	See .github/workflows/ (~13 workflows)
Full 7-step signoff chain	Proven end-to-end under load
Handshake create p95	575ms at 50 VUs (per docs/operations/PERFORMANCE_PROOF.md)

See Performance Proof | Operating Envelope | Security Policy | Audit Methodology | API Compatibility Policy

Conformance status

Metric	Value
Spec version	EP-CORE-v1.0
Conformance test	7/7 required checks PASS
Standalone verify	npm install @emilia-protocol/verify — zero deps, Apache-2.0 (npmjs.com)
Embed widget	<ep-trust-badge entity-id="...">
Discovery	/.well-known/ep-trust.json + /.well-known/ep-keys.json
Formal models	TLA+ + Alloy
CodeQL	Active
SBOM / Provenance	Active

---

EP Core / EP Extensions / EP Product Surfaces

EP is a three-layer system. The core is deliberately small. Everything else is either an optional extension or a product surface built on top.

• EP Core — the interoperable standard: Trust Receipt, Trust Profile, and Trust Decision.
• EP Extensions — stronger enforcement where systems must constrain execution:
  • Handshake
  • Accountable Signoff
  • Commit
  • Delegation and attribution
  • Disputes and appeals where governance requires them
• EP Product Surfaces — reference implementations and commercial layers:
  • Open runtime
  • Cloud control plane
  • Enterprise deployment layer
  • Government, financial, and agent-governance packs

A skeptical reader should be able to answer in 30 seconds: Core = the minimum interoperable standard. Extensions = stronger enforcement you opt into. Product Surfaces = tools built on top, not the protocol itself.

---

Four canonical high-risk action contexts

EP is decision infrastructure. Every serious deployment should anchor to a concrete action surface such as:

Context	Example
Government	payment destination change, benefit redirect, operator override
Financial	beneficiary change, payout destination change, treasury approval
Enterprise	privileged production change, secrets rotation, permission escalation
AI / Agent	destructive tool use, autonomous irreversible action

---

Three core objects

EP standardizes three interoperable objects:

Object	What it is	One-line
Trust Receipt	A portable record of an observed event relevant to trust	What happened
Trust Profile	A standardized summary of observable trust state	What is known
Trust Decision	A policy-evaluated result with reasons and appeal path	What to do now

If a third party can implement these three objects and interoperate, EP has a real standard.

---

Quickstart in five calls

1. create policy
2. initiate handshake
3. present evidence
4. verify
5. signoff and consume

That is the irreducible EP story.

---

Why EP exists

Most systems verify who is acting. Very few verify whether this exact high-risk action should be allowed to proceed under this exact policy by this exact actor right now.

That is the gap EP closes.