Skip to main content
Glama
emiliaprotocol

emilia-mcp-server

Official

EMILIA Protocol

CI License Discord

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.

Install Server
A
license - permissive license
A
quality
B
maintenance

Maintenance

Maintainers
Response time
Release cycle
1Releases (12mo)
Commit activity

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