EMILIA Protocol: An Authority Control Plane for Agent Actions
Authority control plane for autonomous work. EMILIA Gate enforces finite customer-owned mandates at protected executor boundaries; the open protocol keeps evidence verifiable.
At a glance
- What is it?
- EMILIA Gate places a customer-owned consequence boundary in front of protected executor paths, reserving authority before an action and issuing portable receipts after it. The protocol is Apache-2.0 TypeScript, and its README is unusually explicit about what it does not cover.
- Who is it for?
- Adopt EMILIA if you own the executor path end to end and can make Gate the only route to a consequential action, especially for vendor bank-detail changes or payment release where exact-field checks matter. Do not adopt it if your agents reach providers through paths you cannot fully mediate, or if you need freeze semantics to propagate across disconnected leased domains; the README states that leased-edge propagation remains an implementation gap.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem EMILIA targets: agents that widen their own authority
An agent that can call a payment API, merge a pull request, or change a permission record has a scope problem, not a model problem. The README frames it as a control problem that process termination cannot solve: the owner may need to stop new consequences without claiming that computation stopped or that an external effect was reversed. Killing the process is a blunt instrument that also destroys the work in flight.
EMILIA's answer is a boundary rather than a kill switch. A human or institution defines a finite operating mandate. Agents exercise it. Gate exists so the agent cannot quietly widen it. The README describes Gate as the customer-owned consequence boundary where credentialed intent can become a change to money, code, permissions, records, infrastructure, or machines.
The intended audience is not every team running an LLM. It is teams that already own the credentials and the executor path, and that need a preventive check before a specific action rather than a log line after it. The README names finance operations, specifically a vendor bank-detail change or payment release, as the first paid-workflow hypothesis. That is a narrow starting point, and the document says so.
How Gate admits exactly one provider attempt
The mechanism is a reserve-then-admit sequence at a configured protected boundary. According to the README, 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.
That ordering is the whole design. Reservation before provider entry is what makes double-spend of a mandate visible; a single admitted attempt is what stops a retry loop from consuming authority twice; reconciliation on unknown outcome is what stops a timeout from being treated as a failure and replayed.
The README draws a line the marketing copy elsewhere often blurs: protocol proves, Gate prevents, and only on covered paths a deployment completely mediates. It constrains no path that bypasses the enforcement point. The word universal in the project's own framing is qualified in the same paragraph as describing an intended cross-stack contract, not current coverage or adoption. EMILIA does not operate a central global network today.
The component list matters for scoping. Authority Map maps supported declared action surfaces locally with no account, upload, or callback, and discovery creates no authority until the owner reviews the map. EMILIA Approver captures a device-bound exact-action human decision when the mandate or local policy requires fresh human authority, and the README is careful to say a human click is one authority source, not the default execution model.
Emergency Authority Freeze and the epoch rule
The freeze is the most interesting part of the design because it is defined as an authority transition rather than a stop command. Inside a covered Gate control domain, freeze blocks new reservations and prevents an older reservation from entering after the control epoch changes. Restore advances the epoch again and does not revive old authority.
The epoch is doing the work. A reservation taken under an earlier epoch cannot slip through after a freeze because the epoch moved, not because a flag was checked at admission time. That is a cleaner primitive than a boolean, and it is the kind of detail that suggests the authors thought about races between the freeze and an in-flight request.
The README is equally direct about the limits. If provider entry serialized first, the operation remains consumed and must be reconciled. The property holds only under complete mediation and authoritative shared state. 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, and leased-edge propagation plus portable signed freeze-event evidence remain explicit implementation gaps. Anyone evaluating this for a multi-region deployment should read that sentence twice.
Getting the local map and the smolagents wrapper running
The README gives one command for the discovery step: npx @emilia-protocol/scan@0.5.0. It runs locally, requires no account, and produces an Authority Map of supported declared action surfaces. The owner reviews the map before anything is enforced. This is the lowest-commitment entry point and the one to try first, because it tells you whether your action surfaces are even in scope.
The second concrete path is the Hugging Face smolagents integration. The README points to packages/smolagents/README.md for wrapping a tool you already use, and to examples/huggingface-refund-space/README.md for a synthetic refund demo. The release list shows smolagents-v0.1.1 with the description guarded tools and refund demo. The host supplies approval for the exact call; the wrapper refuses missing, changed, or reused authority on that covered path.
The README states plainly that this integration is not a sandbox, and that production enforcement still needs credentials outside the agent and shared, durable consumption state behind Gate. That is the correct warning to give, and it is the reason the wrapper alone is not a deployment.
The third path is the GitHub Merge Gate, described as the first low-friction distribution profile. It binds a repository-owned mandate and detached receipt to the exact base and head commits before a protected merge check passes. The README adds the condition that matters: it is preventive only when the repository makes the check required and closes alternate merge paths. A required check on a repository with an admin bypass is decoration.
Verification tooling is published as @emilia-protocol/verify on npm, and the repository ships a Verify Sample Receipt workflow in CI. Pinning that package version against the receipt format your Gate emits is the kind of thing worth checking before, not after, you rely on a receipt in an audit.
Where EMILIA is the wrong tool
The failure mode is bypass, and the README names it without hedging. Gate constrains no path that bypasses the enforcement point. If an agent holds provider credentials directly, or a second service can reach the same database, or a human can perform the same action through a console, then the boundary is advisory. Complete mediation is a property of your deployment, not of the library.
The second limitation is scope of truth. For the finance workflow, the README says 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. It then says this does not prove source truth, payment authorization, settlement, customer demand, or production deployment. A receipt that a field matched a pinned assertion is not a receipt that the bank account belongs to the vendor.
The third is the freeze gap already described: no instant freeze across a disconnected leased domain, and no portable signed freeze-event evidence in the current reference implementation. If your threat model includes a partitioned edge site that keeps acting, this release does not close it.
Finally, the README's own framing is worth taking literally. EMILIA is not an auditor or accredited certifier, and no public EMILIA certification program is operating. If your compliance story requires a third-party attestation, this project is upstream of that, not a substitute for it.
How this differs from an OPA or Cedar policy decision point
The closest familiar alternative is a policy engine such as Open Policy Agent or Cedar, deployed as a decision point in front of a service. The difference in approach is what gets decided and when. A policy engine answers whether a request is permitted given a policy and some input attributes. It is typically stateless with respect to the action itself, and it does not consume anything when it says yes.
EMILIA's reservation step makes authority a finite resource that is spent. The README describes reserving authority before provider entry and permitting one admitted provider attempt for the covered authorization instance within its durable authority domain. That durable consumption state is the part a policy engine does not give you, and it is the part that makes reuse of a stale approval detectable rather than merely against the rules.
The second difference is the evidence artifact. EMILIA emits authorization receipts, and the project maintains an IETF Internet-Draft, draft-schrock-ep-authorization-receipts, for the format. A policy engine logs a decision; it does not produce a detached, portable receipt bound to an exact action that a third party can verify independently. The npm package @emilia-protocol/verify exists for that verification step.
The trade-off is operational weight. A policy engine is a process you run. EMILIA wants to own the credential-owning executor path and the shared consumption state behind it. That is a larger commitment, and it is only worth it when the action is consequential enough that a reused approval would be a real incident.
Maintenance cost, licence, and the evidence package
The licence is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms. Nothing in the README suggests a dual-licence or open-core split, and the npm verification package is published under the same project. I am not a lawyer and this is not legal advice; the point is only that the licence text is the standard Apache grant, not a custom one that needs review.
Upgrade cost depends on which surface you adopt. The scan tool is versioned separately (@emilia-protocol/scan@0.5.0 in the README), the smolagents wrapper has its own release line (smolagents-v0.1.1), and the protocol itself is at v1.0.0 with a clean-room challenge release in between. Four independently versioned surfaces means four upgrade paths to track, and the receipt format is the one where a mismatch would be expensive.
The repository's own maintenance posture is visible in what it ships. The README claims 35 security claims over 259 hashed evidence files, 20 Tamarin lemmas across two composed Dolev-Yao models (17 all-traces obligations and 3 exists-trace reachability witnesses), and 8 deliberately weakened variants that produce concrete attack traces when load-bearing checks are removed. It also points to public/.well-known/emilia-context.json as the machine-readable context and warns that archived or staged documents do not establish current implementation or IETF status. That warning is the right instinct, and it is the reason to read the context file rather than the badges.
Editorial conclusion
Adopt EMILIA if you own the executor path end to end and can make Gate the only route to a consequential action, especially for vendor bank-detail changes or payment release where exact-field checks matter. Do not adopt it if your agents reach providers through paths you cannot fully mediate, or if you need freeze semantics to propagate across disconnected leased domains; the README states that leased-edge propagation remains an implementation gap. Before committing, verify three things in the repository itself: that the PostgreSQL control domain is the one you intend to run, that the Merge Gate check is marked required and alternate merge paths are closed, and that the @emilia-protocol/verify package version you pin matches the receipt format your Gate emits.
Community notes