EMILIA Protocol is a control plane for managing autonomous work authority: it lets AI agents prepare actions such as payments, but controls what they can actually release. It keeps the customer's existing identity providers, agent frameworks, and business systems unchanged, enforces authority checks at a protected executor boundary (the EMILIA Gate), and makes the resulting evidence independently checkable under the relying party's own trusted keys and rules.
Purpose and main capabilities
- Check authority before irreversible operations (such as payments, deployments) are executed: the Gate checks permissions before a protected tool runs, can require named human approval, and binds the approval to material fields such as amount, currency, vendor, and destination.
- Bounded authority and precise action binding: customers define tasks, material action limits, budgets, required evidence, expiration, delegation rules, and exception paths. The Gate binds the method, source, callee, target, occurrence, and every material field into a canonical executable object; intent, prompts, or ticket text do not count as that object.
- Proof and prevention: the protocol layer is responsible for "proving," and the Gate is responsible for "preventing" on fully mediated deployment paths. The Gate cannot constrain bypass paths; if the provider result is unknown, the production lifecycle preserves that uncertainty for reconciliation rather than blindly retrying.
- Offline-verifiable evidence: a Trust Receipt carries attributable evidence, a Trust Profile represents structured trust state, and a Trust Decision records the relying party's policy evaluation result.
- Emergency authority freeze: prevents new reservations and prevents old reservations from entering after a validation domain epoch change. If the provider entry has already occurred first, the attempt remains consumed and requires reconciliation; restoring authority does not revive old reservations.
How to use it (provided in the materials) Run the payment example: requires Node.js 20.19 or later and npm. The example rejects unapproved calls, binds approval to amount, currency, vendor, and destination, allows only one matching call, and rejects changed payment details, replays, and forged evidence. This is a local demo: it uses generated signing keys, in-memory consumption, and a simulated payment tool, and does not execute a real human process or move funds. Protect a tool already in use: start from a service that holds real provider credentials, not just inside the agent process. MCP or HTTP can go through one covered action via Gate Starter; Hugging Face smolagents can wrap an existing tool; GitHub's Merge Gate puts the checkBound to the proposed merge (the check must be required, and alternative merge paths are closed). Browser trial: use a platform passkey to try signing on an example payment, demonstrating receipt integrity; you can also paste the receipt into the browser for offline verification, without uploading the content. Command examples: npm run check:security-case; node examples/crash-test.mjs (fully offline, no API key required).
Applicable scenarios
- Agents initiating irreversible actions: payments, deployments, merges, and other scenarios that require "valid authority first, then execution."
- Human-in-the-loop approval needed: policies can require WebAuthn/passkey decisions bound to the exact action and a deterministic display hash.
- Enterprise environments: customers keep authorization, trust roots, credentials, policies, and portable evidence within their own boundary; the hosted Gate and Assurance Plane add task operations, integrations, evidence operations, replay, support, and service levels around open protocols.
Limitations and boundaries (explicitly stated in the materials)
- The local demo uses generated keys, in-memory state, and mock tools; it does not execute real human processes or move funds. Production requires enrolled credentials, persistent shared state, and deployment of the Gate on every path leading to protected provider credentials. A valid approval does not prove that bank details are legitimate.
- The Gate can only block on paths it fully mediates and cannot constrain bypass paths; it cannot stop computation, reverse effects, or instantly reach disconnected domains.
- A passing report is self-attesting consistency evidence, not an audit, certification, production deployment claim, or permission to execute an action.
- The synthetic corpus runner in the repository does not execute the published @emilia-protocol/verify or @emilia-protocol/gate code, so it is not evidence for those packages.
- An Internet-Draft is not an RFC, is not a project adopted by a working group, and does not represent IETF endorsement.
Open source license EMILIA Protocol is open source, under the Apache-2.0 license.
