emilia-protocol

EMILIA Protocol

---

Let your agent prepare the payment. Control what it can release.

An agent prepares an $82,000 supplier payment. Someone approves it. Then the amount or bank destination changes. The earlier approval must not release the changed payment.

EMILIA Gate checks authority before a protected tool runs. The open protocol makes the resulting evidence independently checkable under the verifier's own trusted keys and rules. Keep your existing identity provider, agent framework, and business systems.

Run the payment example

With Node.js 20.19 or newer and npm installed:

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

The example refuses a call without approval, binds approval to the amount, currency, vendor, and destination, admits the matching call once, and refuses changed payment details, replay, and forged evidence. See the example and its limits.

This is a local demonstration: generated signing keys, in-memory consumption, and a mock payment tool. It does not perform a real human ceremony or move money. Production needs enrolled credentials, durable shared state, and Gate on every path to the protected provider credential. A valid approval does not establish that the bank details are legitimate.

Prefer a browser? Try a passkey on a sample payment. That separate demo shows receipt integrity with your platform authenticator; no payment is sent.

Protect one tool you already use

Start at the service that holds the real provider credential, not only inside the agent's process. The owner defines the allowed work and when a fresh approval is required. An agent can work inside those limits without a person approving every call.

• MCP or HTTP: Gate Starter walks through one covered action.
• Hugging Face smolagents: wrap an existing tool.
• GitHub: Merge Gate binds a check to the proposed merge. The check must be required and alternate merge paths closed.

Protocol proves. Gate prevents on the paths the deployment completely mediates. Gate cannot constrain a bypass path. If a provider's result is unknown, the production lifecycle preserves that uncertainty for reconciliation rather than blindly retrying.

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.

Engineering evidence, not architecture claims

EMILIA ships a security case that reviewers can execute. The current repository resolves 35 security claims over 264 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 340 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 10,700+ automated tests across 650+ 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 composed CAID/AEC path at the last control point before a consequential action: native verification, relying-party acceptance, exact-action binding, required CAID matching, required AEC evidence satisfaction, local authorization, atomic reservation, INVOKING custody, separate provider-outcome and observed-effect truth, no-blind-retry behavior, and authenticated reconciliation.

Read the consequence-admission boundary for the exact division of responsibility across the composed CAID/AEC path, the direct native path, AEB custody, and provider outcome evidence.

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.

Under AEB-07, posted on 2026-09-25 as an individual Internet-Draft and not adopted by any working group, CAID is used only when independently encoded actions must be joined, and AEC is used only when local policy requires several evidence legs. A separate 26-case synthetic corpus models that direct-native lifecycle over AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token, and local signed-mandate adapter results:

npm run conformance:composition:consequence-admission

The corpus runner is a standalone lifecycle model with its own in-memory store and admission logic. It does not execute the shipped @emilia-protocol/verify or @emilia-protocol/gate code, so it is not evidence for those packages, which have their own test suites. It is also not evidence that the named native protocols conform to AEB-07.

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.

Identity is not a job description

Identity says who or what is calling. Policy says what is generally allowed. Neither defines the finite job an autonomous worker may perform now: its mission, material-action limits, budget, required evidence, expiry, delegation rules, and exception path.

EMILIA keeps those questions separate:

Layer	Question
Identity	Who or what is present?
Policy	What is generally allowed?
Authority	What exact work may this agent perform under this mandate?

Credentials grant reach. Authority defines the job. Not every action needs a human; every consequential action needs valid authority.

At the foundation, EP Core still exposes three interoperable objects: a Trust Receipt carries attributable evidence, a Trust Profile represents structured trust state, and a Trust Decision records the relying party's policy-evaluated result. The authority-control-plane layers add exact action binding, finite mandates, admission, consumption, and outcome evidence without collapsing those objects into one claim.

---

Set the mandate once. Let the agent work.

The customer defines the mission, limits, evidence requirements, expiry, and exception rules. Local code may narrow that authority; it cannot invent or widen it. Gate binds each executable request to the mandate, reserves the covered authority before provider entry, permits one admitted provider attempt for that authorization instance inside the shared durable authority domain, and escalates only when authority is missing, stale, exhausted, or too narrow.

The bundled MCP examples exercise a policy profile requiring approval at the boundary. They generate demonstration signing keys and invoke mock tools. The payment example binds all four declared material fields; the other examples demonstrate narrower resource bindings. They do not capture a real human decision or contact a provider:

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 one declared consequential MCP action. Install the exact local runtime, then create its Gate Starter and run the bounded four-case check:

npm install --save-exact @emilia-protocol/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

The generated local check uses explicitly ephemeral demo state and proves only the stated synthetic missing, exact-match, mutation, replay, and unscanned-tool cases. The reviewed command creates a privacy-bounded handoff; it does not activate Gate. 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.

Stop new actions without pretending to undo old ones

Gate's emergency authority freeze blocks new reservations and prevents older reservations from entering after the covered control domain's epoch changes. If provider entry happened first, the attempt remains consumed and needs reconciliation. Restoring authority does not revive an old reservation.

This requires complete mediation and authoritative shared state. It does not stop computation, reverse an effect, or instantly reach disconnected domains.