emilia-mcp-server
OfficialEMILIA 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-server90-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 |
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 |
|
Embed widget |
|
Discovery |
|
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
create policy
initiate handshake
present evidence
verify
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.
Maintenance
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/emiliaprotocol/emilia-protocol'
If you have feedback or need assistance with the MCP directory API, please join our Discord server