Adds named-human approval, trust receipts, verification, disputes, and delegation for consequential AI-agent actions.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
We haven't yet run this listing's install command through our automated sandbox check. This isn't a red flag β we're steadily working through the catalog.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Inspect callable tools, capabilities, and parameters exposed to AI agents by Emilia Protocol.
EMILIA is building the universal authority toll booth for autonomous work. Gate is the customer-owned consequence boundary where an agent's credentialed intent can become a change to money, code, permissions, records, infrastructure, or machines. A human or institution defines a finite operating mandate; agents exercise it; Gate ensures the agent cannot quietly widen it.
At a configured protected boundary, Gate verifies the authority the owner requires for the exact action, reserves that authority before provider entry, permits one admitted provider attempt for the covered authorization instance within its durable authority domain, and leaves portable evidence of what the protected path admitted and later observed. When the result is unknown, it requires reconciliation instead of a blind retry. Protocol proves. Gate prevents on the covered paths a deployment completely mediates; it constrains no path that bypasses the enforcement point.
"Universal" describes the intended cross-stack contract, not current coverage or adoption. EMILIA does not operate a central global network today. The toll booth repeats at customer-owned protected boundaries and composes with native identity, authorization, approval, and policy evidence.
Run the local map (npx @emilia-protocol/scan@0.5.0), choose one consequential workflow, and place Gate
where authorized intent becomes consequential action.
The first low-friction distribution profile is GitHub: the open Merge Gate binds a repository-owned mandate and detached receipt to the exact base and head commits before a protected merge check passes. It is preventive only when the repository makes the check required and closes alternate merge paths. This is a product and distribution experiment, not evidence of external adoption.
Using Hugging Face smolagents? Wrap a tool you already use and try the synthetic refund demo. The integration is free and open source. The host supplies approval for the exact call; the wrapper refuses missing, changed, or reused authority on that covered path. It is not a sandbox: production enforcement still needs credentials outside the agent and shared, durable consumption state behind Gate.
Continuous and self-improving agents create a control problem that process termination alone cannot solve: the owner may need to stop new consequences without claiming that computation stopped or that an external effect was reversed. Gate's Emergency Authority Freeze makes that a durable authority transition. Inside a covered Gate control domain, freeze blocks new reservations and prevents an older reservation from entering after the control epoch changes. If provider entry serialized first, the operation remains consumed and must be reconciled; restore advances the epoch again and does not revive old authority.
This property holds only under complete mediation and authoritative shared state, and two gaps remain (below). It does not stop the agent, undo an entered effect, or provide instant freeze across a disconnected leased domain. The current reference implementation covers the local in-memory and PostgreSQL control domain; leased-edge propagation and portable signed freeze-event evidence remain explicit implementation gaps.
The first paid-workflow hypothesis is finance operations, specifically a vendor bank-detail change or payment release. The agent may prepare the action. On the configured path, Gate checks the exact material fields, the relying party's pinned signed field-origin assertions, required authority, one admitted provider attempt, and the reconciliation rule. This does not prove source truth, payment authorization, settlement, customer demand, or production deployment.
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.
EMILIA ships a security case that reviewers can execute. The current repository resolves 35 security claims over 259 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,601+ automated tests across 657+ 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.
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 reservation, INVOKING custody, separate
provider-outcome and observed-effect truth, no-blind-retry behavior, and
authenticated reconciliation.
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:
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 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.
Factual signals from GitHub, npm, and our automated checks β not a rating.
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/emiliaprotocol-emilia-protocol)<a href="https://allmcps.com/mcp/emiliaprotocol-emilia-protocol"><img src="https://allmcps.com/api/badge/emiliaprotocol-emilia-protocol?style=directory" alt="Emilia Protocol on AllMCPs" /></a>