“Stop my agent before it does something irreversible” is a real category now, with real, good products in it. Here is the honest map — what each does well, and the few things that are genuinely EMILIA’s. We concede the rest, because a comparison you can’t trust isn’t worth citing.
| Dimension | EMILIA | HumanLayer | Tenet | DRP (Authproof) |
|---|---|---|---|---|
| Category | Enforcement + evidence layer | Approval-routing middleware | Governance layer — gates + audit | Authorization protocol (individual I-D) |
| Gates irreversible actions | Yes — policy engine + signoff | Yes — routes to Slack/email | Yes — auto-pause | Yes — 14 pre-action checks |
| Tamper-evident evidence | Ed25519 + Merkle receipt | A log line in your own app | SHA-256 hash chain | Append-only log + RFC 3161 timestamps |
| Offline-verifiable receipt | Yes — @emilia-protocol/verify, no network | No | Verify the chain yourself; no offline receipt lib | No — verification requires the log |
| Formal verification | Yes — 26 TLA+ theorems + 35 Alloy facts, in CI | No | No | No — spec with 14 checks |
| Separation of duties | Enforced — approver ≠ initiator | Whoever clicks the button | Not addressed | Implicit, not formalized |
| Approver key custody | Device-bound WebAuthn keys (Class A) — shipped; server-side legacy fallback | — | — | User holds the key (client-signed) |
| Standard / licensing | Apache-2.0 + open spec & conformance | Open core | Commercial SaaS ($29/mo) | Individual Internet-Draft (no IETF standing); Authproof hosted |
| Best for | Provable authorization for auditors, regulators, fraud/treasury | Fast approval UX, dev velocity | Turnkey gates + audit, multi-framework | A future interop standard, if adopted |
Based on each project’s public docs and, for DRP, the Internet-Draft draft-nelson-agent-delegation-receipts (an individual submission with no IETF standing — read directly). If we’ve mischaracterized anything, tell us and we’ll correct it.
Cryptographic receipts are no longer rare — a fast-growing cluster of projects (below) already signs agent actions with Ed25519 and hash-chains them. So we don’t lead with the receipt. We lead with what almost no one else has:
@emilia-protocol/verify checks it with pure Ed25519 + Merkle math — no log, no network, no account.A fast-growing set of open-source projects ships cryptographic accountability for agent actions — among them nobulex (Ed25519 + hash-chains, pre-action enforcement, “trust capital for machines”), Agent Receipts (a signing daemon that mints a W3C Verifiable Credential per tool call), and signet. They are real and genuinely well-built, and we share their conviction: every irreversible agent action should leave tamper-evident, independently verifiable proof. On that, EMILIA is not unique — offline receipts are becoming table stakes, and we’d rather say so than pretend otherwise.
The line we draw is who signs. In that cluster the agent signs its own receipts, or an operator-run daemon auto-signs every call — which proves what the software did and that no one edited it afterward, but not that an accountable human authorized that specific action. EMILIA’s signature is produced by a named human on their own device, before the action runs — the one thing neither a compromised agent nor an operator can manufacture — backed by separation of duties and a machine-checked protocol the cluster doesn’t claim. Receipts are table stakes; a provably accountable human is the wedge.
DRP is the serious one to watch — an individual Internet-Draft for user-signed delegation receipts (Authproof’s spec; no IETF working-group standing yet, the same early status any new proposal in this space has, ours included). We are not here to rebut it. Its core choice is right: the signing key belongs on the human’s own device, removing the operator from the trust path. EMILIA now does the same — approver-held WebAuthn keys (Class A), shipped and verified on real hardware, with a server-side legacy fallback (documented in our threat model). The remaining distinction is whose key signs: DRP binds the delegating user; EMILIA binds the accountable approver, under enforced separation of duties.
Where EMILIA adds beyond DRP: a formally-verified policy engine, an offline-verifiable receipt (DRP’s draft states verification requires the append-only log), enforced separation of duties, and one-time global consumption. The honest aim is to be a rigorous, offline-verifiable realization of the delegation-receipt idea — not a competing silo.
The nearest peer to EMILIA is PSEA (draft-yossif-psea, Yuthent) — an EAT token profile for action-bound, user-verification-gated transaction confirmation. It reached the IETF datatracker before our draft, and we’ll say that plainly. It is also the strongest evidence we have that this is a real problem and not one vendor’s framing: two efforts arrived at the same core construction — a canonical hash of the exact action, a user-verification-gated signature, and fail-closed verifier rules — without contact. We treat it as convergent, not competing.
The lanes are genuinely different. PSEA explicitly scopes out FIDO2/WebAuthn — its model needs a conforming authenticator and a mobile SDK; EMILIA profiles exactly that excluded path, so the approver signs with a commodity passkey already in their pocket (Face ID / a browser), nothing to install. And where Yuthent’s implementation is proprietary and patent-pending, EMILIA is Apache-2.0, with public dated history and a verifier anyone can run — including in their own browser at /verify, with nothing uploaded. Different authenticator model, different openness posture, same verifier philosophy. We’ve offered, on the public list, to align claim names so the two profiles don’t gratuitously diverge for implementers.
Any in-process guard is skippable by the operator who controls the process — true of every product here. The differentiator is the evidence that survives outside the runtime, and end-to-end enforcement only when the system of record verifies the receipt before executing. We say this plainly on our security page.