The guard and sign-off calls say so themselves: they evaluate policy, capture a signed human yes bound to the exact action, and leave a receipt anyone can verify, but nothing stops the action unless the code that performs it checks the action hash and consumes the receipt first. Read it as the evidence layer — commit before, receipt after, delegation and handshake for who may act for whom — and build the choke point where the action actually happens.
A trust and authorization layer for agent actions: request human sign-off before something irreversible, bind the agent to a commit beforehand, verify the receipt afterwards, and check delegations and counterparty identity. Receipts verify offline, against the anchored root rather than a service that has to be up.
- A gate in front of an irreversible action: ep_guard_action submits the exact action — action type, amount, currency, destination, target resource and risk flags — for policy evaluation and human authorization, and ep_check_signoff polls the receipt id until a human has approved, consumed or denied it
- Proof after the fact: ep_verify_receipt checks a receipt's signature and Merkle inclusion against the anchored root and returns the verified claim — action, approver, outcome — with its anchor status
- Pre-action commits with a full lifecycle: ep_issue_commit binds the agent to an action type, entity and policy and returns a commit id, decision, expiry, scope and appeal path; ep_verify_commit confirms a commit is genuine and active; ep_get_commit_status reports active, revoked, expired or fulfilled; ep_revoke_commit terminally cancels it; ep_bind_receipt_to_commit links the outcome back to the authorization that allowed it
- Standing authority that can be checked rather than assumed: ep_create_delegation records that a principal authorizes an agent within a scope, expiry, value ceiling and constraints, and ep_verify_delegation answers valid, expired or not found before you accept a task from an agent claiming to act for someone
- Identity exchange between parties: ep_initiate_handshake opens an exchange governed by a policy, ep_add_presentation appends a party's claims under full, selective or zero-knowledge disclosure, ep_verify_handshake returns accepted, rejected or partial with reason codes, ep_get_handshake returns the full state, and ep_revoke_handshake closes it terminally
- A check before you install someone else's code: ep_install_preflight evaluates an npm package, GitHub app, browser extension or MCP server against a trust policy and returns allow, review or deny with reasons covering publisher, requested permissions, provenance and trust history
- ep_list_policies, for discovering which policy an evaluation should run against
Npx on your PATH. The verification tools work with no account at all — a receipt checks out offline against pinned keys. EP_API_KEY is what the rest need: the trust APIs and every write, including creating a delegation, adding a presentation and revoking a commit. A handshake needs at least two parties and a governing policy. Apache-2.0.
One command — npx -y @emilia-protocol/mcp-server