EMILIA Protocol

Protocol proves. Gate prevents.

EMILIA Gate is the commercial Consequence Firewall that prevents consequential machine actions on protected executor paths without verifiable authority. It sits at the executor or system-of-record boundary, refuses before mutation, consumes accepted authorization once, and leaves evidence another party can verify.

EMILIA is the authority control plane for autonomous work: a human or institution defines a finite operating mandate once, agents work unattended inside it, and Gate enforces each consequential unit of work.

Scan (npx @emilia-protocol/scan) → protect one privileged MCP tool call → $25K pilot.

• EMILIA Protocol is the open Apache-2.0 verification and evidence substrate underneath Gate.

• EMILIA Approver captures device-bound human decisions over the exact action through native apps and embeddable SDKs.

• EMILIA Assurance Plane provides scoped verification, re-performance, conformance reports, and deployment evidence. It supports auditors, insurers, regulators, and customers; EMILIA is not an auditor or accredited certifier, and no public EMILIA certification program is operating.

Start free by protecting one privileged MCP tool call. The first paid market is payer AI-assisted adverse medical-necessity determination, under one safety rule: no valid licensed-review evidence, no adverse determination. Missing evidence routes to lawful human review or a patient-protective fallback; it is not authority to withhold medically necessary care.

AI systems and repository reviewers: start with AI_CONTEXT.md. Current machine-readable evidence, provenance, assumptions, and exclusions are published at EMILIA-REPO-CONTEXT-v1. Archived or staged documents do not establish current implementation or IETF status. Public due-diligence evidence and claim boundaries: DUE_DILIGENCE.md.

Related MCP server: evermint-mcp

Engineering evidence, not architecture claims

EMILIA ships a security case that reviewers can execute. The current repository resolves 35 security claims over 255 hashed evidence files, verifies 20 Tamarin lemmas across two composed Dolev-Yao models — 17 all-traces obligations and 3 exists-trace reachability witnesses — and preserves 8 deliberately weakened variants that produce concrete attack traces when load-bearing checks are removed. The live same-team conformance corpus contains 21 suites and 331 current vectors. Separately, an externally authored Rust verifier is pinned to the frozen 16-suite/164-vector bundle and a 359-case hostility campaign. The broader suite contains 8,659+ automated tests across 509+ files.

Production JavaScript and JSDoc surfaces are compiler-checked with TypeScript checkJs; the secure app has its own compatibility compiler project, while declarations and the public TypeScript SDK are checked in strict mode. This is complete configured production type-check coverage, not a claim that the repository was converted wholesale from JavaScript to TypeScript or that every JavaScript project has TypeScript's strict option enabled.

Each security claim names the enforcement path, positive and negative vectors, language coverage, formal scope or explicit gap, assumptions, exclusions, and evidence hash. Start with the human-readable evidence map, then inspect the resolved security case or run npm run check:security-case.

AEB-1: test the evidence-to-effect boundary

The open AEB-1 Consequence Admission Conformance pack tests the last control point before a consequential action: native verification, relying-party acceptance, exact CAID/action matching, evidence satisfaction, local authorization, atomic one-time reservation, INVOKING custody, separate provider-outcome and observed-effect truth, no-blind-retry behavior, and authenticated reconciliation.

npx @emilia-protocol/verify aeb-conformance --reference

It is format-neutral and self-run. A passing report is self-attested conformance evidence—not an audit, certification, production-deployment claim, or permission to execute an action.

For a focused executable proof of the repository's Gate path, run:

npm run proof:gate:reference

This command exercises local examples and focused service boundaries with generated keys, in-memory state, and mock provider behavior. It is useful local proof, not evidence of a real human, external bank, production deployment, or one end-to-end production integration.

The engine without brakes

For fifty years, software security answered one question: who is allowed in? Firewalls, OAuth, and passwords — all built to verify a human identity at the door.

That era is ending. The dominant users of software are no longer humans; they're autonomous AI agents. Agents don't just log in — they write code, call tools, and change reality on the fly. Every CISO knows a single bad prompt can make an agent wipe a production database or wire money to the wrong account. So they're blocking deployment — sitting on billions in AI budget they can't spend because their compliance teams can't answer one question:

Who approved that action?

The crisis of our generation isn't authentication. It's authorization at the moment of action: how do you prove that what an agent is about to do is exactly what a named human authorized — before it executes?

EMILIA is the seatbelt for the agentic era.

Decision logs are testimony. EMILIA produces receipts.

No receipt, no irreversible action

If an agent tries to move money, delete code, deploy production, change permissions, or mutate regulated state without a valid EMILIA receipt, the tool refuses to run — and if it runs, anyone can verify who authorized exactly what, offline, trusting no one.

That is the whole protocol. The developer wedge is one wrapper around an irreversible MCP tool. See it cold, fully offline, no key, no account — each demo runs the entire loop (refused → named human signs the exact action → tool runs → forged receipt rejected):

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

The deeper composition demo executes a CAID-bound delegated payment through Gate's real bounded-capability path, then verifies the signed execution certificate offline:

npm run demo:receipt-program

It deliberately includes no blockchain or simulated zero-knowledge claim. See the receipt-program architecture for the production state and trust requirements.

Start with a dry run against your declared tool surface, then generate the reviewable integration files:

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

The generated local check uses explicitly ephemeral demo state and proves only that its synthetic handler was not called. Production requires a durable provenance ledger, a shared atomic consumption store, pinned keys, and the wrapper on every path to the real provider credential. See examples/mcp/ and /mcp.

Try it in 30 seconds

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

Try a real Face ID signoff → Approve an $82,000 wire with your own passkey. See what VERIFIED looks like. Forge the receipt. See it fail.

Verify any receipt in your browser — paste it in, nothing is uploaded.

How it works — four acts

Run it yourself: node examples/crash-test.mjs — fully offline, no API key.

  [ INTENT ]          [ DECISION ]           [ CEREMONY ]           [ RECEIPT ]
  Agent calls a     Policy-bound, hash-    Named human signs     Signed, offline-
  tool via MCP   →  pinned: allow /     →  the EXACT action  →  verifiable proof.
                    allow-with-signoff /   on their own          Tamper it:
                    deny  (+observe        device (passkey).      fails by design.
                    mode: zero change      What they saw =
                    to production)         what they signed.

Act I — Interception (MCP-native). No rewrites. EMILIA hooks the tool call at the Model Context Protocol boundary — the moment an agent tries to delete a file or move capital, the action is caught mid-air.

Act II — Decision (policy-bound, deterministic). The action is checked against a hash-pinned policy: allow, allow-with-signoff, or deny. Plus an observe mode that changes nothing in production and reports what would have been held. Deterministic, auditable — not a black-box risk score.

Act III — The ceremony (device-bound human signoff). When policy requires a human, EMILIA runs a WebAuthn / passkey signoff bound to the exact action and its deterministic display hash — Face ID / Touch ID on the operator's own device. Class-A approvals also bind a server-measured review interval and an action-specific confirmation phrase, with a durable per-approver velocity limit. This narrows the "what you saw is what you signed" gap; it does not prove comprehension. A correctly installed protected path cannot skip the ceremony.

For enterprise deployments, Gate can additionally require an independently verified Authorization Server confirmation bound to that exact human evidence, the same exact action, the identity snapshot the AS actually observed, and the intended Resource Server key. The snapshot time and relying-party maximum age are explicit: a fresh token cannot make stale directory data current. The AS leg is evidence under customer-pinned trust; it never authorizes by itself, proves instantaneous employment standing, or turns the agent orchestrator into an authority.

Act IV — The receipt (the evidence). The result is a signed authorization receipt that anyone can verify offline, with open-source code, no backend, no vendor trust. Tamper it and verification fails by construction. Optionally anchor it for public timestamping — the core needs no blockchain.

Why developers use it

You want agents that actually do things — but you're paralyzed by runaway loops, API over-spend, and accidental data destruction. EMILIA gives you a plug-and-play MCP server + a thin SDK wrapper. Apply a policy hash, and irreversible tool calls gain a cryptographically hardened, NIST-AI-RMF-mapped approval-and-evidence layer — without building approval workflows or audit infrastructure from scratch.

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

Your agent can't outrun its leash.

Why enterprises need it

Every platform shift mints a new security primitive: the web got SSL, the cloud got Okta / IAM, the agent economy needs action-level trust. Enterprises are sitting on AI budgets that compliance won't let them spend — EMILIA is the key that unlocks them, by turning unpredictable agents into audit-ready infrastructure that maps primitive-by-primitive to NIST AI RMF, EU AI Act, and SOC 2 CC6/7 controls.

The managed Gate and Assurance Plane extend the open standard with sector-specific policy packs, observe-mode pilots, and audit-ready evidence packages, with no procurement required to start.

The standard

EMILIA Protocol is open and Apache-2.0. Its standards work is published as a portfolio of individual Internet-Drafts. A published Internet-Draft is not an RFC, an adopted working-group item, or IETF endorsement; Datatracker is authoritative for revision and status.

Canonical four-document presentation surface

For reader navigation, the canonical evidence path is:

1. Authorization Receipts-10 defines the action-bound approval-evidence profile. The current posted revision is -10, filed as a Standards Track candidate individual submission.

2. Human Authorization Binding-00 binds a named-human authorization artifact into an adjacent host record.

3. Authority Introduction-03 establishes relying-party-pinned trust roots and scoped authority.

4. Authorization Evidence Chain-05 evaluates whether natively verified, action-matched evidence satisfies the relying party's requirement; it returns SATISFIED or UNSATISFIED, never AUTHORIZED.

This four-document surface is presentation only. It does not merge, retire, replace, update, obsolete, subordinate, or demote any draft in the active portfolio.

Separate runtime execution spine

The runtime path is Architecture-02 → CAID-02 → AEC-05 → AEB-03: system boundaries, exact material-action matching, evidence satisfaction, then executor-side admission and one-time consequence custody. AEC appears in both views because evidence satisfaction feeds runtime admission, not because the views are equivalent.

The complete active portfolio remains 23 Datatracker records: 20 active draft-schrock-* records and three coauthored records, each with its own scope and revision history. See the standards guide, portfolio, and machine-readable status inventory.

Three same-team reference ports (JS / Python / Go) agree across all 21 suites and 331 vectors. Separately, an externally authored Rust implementation rebuilt from a pinned public source tree passes the pinned 16-suite/164-vector clean-room bundle and a 359-case hostility campaign, re-run in its own CI lane on every change. The newer AEC acceptance and four-outcome resolution suites are not attributed to Rust. That is external interoperability evidence, not strict clean-room construction acceptance; the aggregate CI case records the strict acceptance count as zero pending independent attestation. See CONFORMANCE.md, or verify a receipt yourself at emiliaprotocol.ai/verify.

The EP stack

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

Proof points

EP Core objects

EP standardizes three interoperable objects that any conforming implementation can produce and verify:

EP Extensions (Handshake, Signoff, Commit, Delegation) add stronger enforcement where systems must constrain execution. The product layer, the managed Gate and Assurance Plane, is built on top, not the protocol itself.

Quickstart in five calls

1. Create policy

2. Initiate handshake

3. Present evidence

4. Verify

5. Signoff and consume

90-second demo · Quickstart · Agent walkthrough · IETF Draft

What EP is — and is not

EP is authorization at the moment of action, not an identity system, not a wallet, not a reputation score.

• Is: a trust standard for binding actor identity, authority, policy, and exact action context before execution

• Is not: a replacement for OAuth / OIDC (those answer who are you — EP answers who approved this exact action)

• Is not: a proprietary product (the core is Apache-2.0 and published as individual Internet-Drafts on the IETF Datatracker)

• Is not: a blockchain (the receipt is the hero; optional public timestamping is a footnote)

See CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant