EMILIA Protocol vs HumanLayer
Same shelf, different layer. HumanLayer is excellent approval plumbing — it pauses a sensitive tool call and routes it to Slack or email. EMILIA is an enforcement-and-evidence layer: it binds the approval to the exact action and turns it into an artifact anyone can verify offline, years later.
Where HumanLayer is the right call
If you’re a developer wiring a human into your agent and you want a clean approval experience — Slack/email routing, escalations, timeouts — in an afternoon, HumanLayer is a strong, well-made choice, and we won’t pretend otherwise. For developer velocity and a friendly approval UX, it wins. If “a human clicked approve” is the whole question you need to answer, you don’t need EMILIA.
The different question EMILIA answers
Approval plumbing answers “did a human click approve?” The approval lives in your application layer, and your code decides whether to honor it. EMILIA answers the harder question auditors, regulators, and fraud teams actually ask: can anyone prove, later, that this exact irreversible action was authorized by an accountable, named human?
It does that by binding the signoff to the exact action hash, consuming it once via nonce, enforcing separation of duty in the protocol, and minting an authorization receipt (formerly Trust Receipt) that verifies offline with pure math (Ed25519 + Merkle) — no account, no call home. The policy engine underneath is formally verified, and you can run the model checker yourself.
Side by side
| Dimension | Approval plumbing (e.g. HumanLayer) | EMILIA Protocol |
|---|---|---|
| Core question | “Did a human click approve?” | “Can anyone prove this exact action was authorized by an accountable human?” |
| Where approval lives | Your application layer — your code decides to honor it | Bound into the protocol — action hash, nonce, separation of duty |
| Binding to the action | Approves a request; not cryptographically bound to the exact parameters | Signoff bound to the exact action hash — amount, destination, beneficiary |
| Replay | Reusable unless you prevent it | One-time consumable (nonce) |
| Evidence | A record in your own system — trust us | Authorization receipt — Ed25519 + Merkle, verifiable offline, no account, no call home |
| Assurance | A well-built product; trust the implementation | Formally verified policy engine — 26 TLA+ theorems + 35 Alloy facts, run the checker yourself |
| Best for | Fast, friendly approval UX — developer velocity | Provable authorization for auditors, regulators, fraud & treasury controls |
Based on HumanLayer’s public design as approval-routing middleware. If we’ve mischaracterized anything, tell us and we’ll correct it.
The honest part — what neither of us does in-process
A guard that runs inside a process the agent’s operator controls is skippable — that is true of HumanLayer and it is true of EMILIA. So EMILIA’s edge is not “we can’t be bypassed.” It is two things: the offline-verifiable receipt — evidence that survives outside the agent’s runtime and proves what was authorized — and the path to end-to-end enforcement, which is airtight only when the system of record (the bank API, the benefits system) verifies the receipt before it executes. We say this plainly on our security page, because pretending otherwise is exactly the claim this category should distrust.
Which do you need?
Need a fast human-in-the-loop UX, answerable to your own team? Use approval plumbing. Need to prove authorization to an auditor, an insurer, a regulator, or after a fraud loss — treasury, payments, benefits integrity, SOX-scoped controls? That is the line where you need a bound, replay-resistant, offline-provable receipt.