emiliaprotocol/emilia-protocol

---
Let your agent prepare the payment. Control what it can release.
An agent prepares an $82,000 supplier payment. Someone approves it. Then the amount or
bank destination changes. The earlier approval must not release the changed payment.
**EMILIA Gate checks authority before a protected tool runs.** The open protocol makes
the resulting evidence independently checkable under the verifier's own trusted keys
and rules. Keep your existing identity provider, agent framework, and business systems.
Run the payment example
With Node.js 20.19 or newer and npm installed:
The example refuses a call without approval, binds approval to the amount, currency,
vendor, and destination, admits the matching call once, and refuses changed payment
details, replay, and forged evidence. See the example and its limits.
**This is a local demonstration:** generated signing keys, in-memory consumption, and a
mock payment tool. It does not perform a real human ceremony or move money. Production
needs enrolled credentials, durable shared state, and Gate on every path to the protected
provider credential. A valid approval does not establish that the bank details are legitimate.
Prefer a browser? Try a passkey on a sample payment.
That separate demo shows receipt integrity with your platform authenticator; no payment is sent.
Protect one tool you already use
Start at the service that holds the real provider credential, not only inside the agent's
process. The owner defines the allowed work and when a fresh approval is required. An agent
can work inside those limits without a person approving every call.
- **MCP or HTTP:** Gate Starter walks through one covered action.
- **Hugging Face smolagents:** wrap an existing tool.
- **GitHub:** Merge Gate binds a check to the proposed merge. The check must be required and alternate merge paths closed.
**Protocol proves. Gate prevents** on the paths the deployment completely mediates.
Gate cannot constrain a bypass path. If a provider's result is unknown, the production
lifecycle preserves that uncertainty for reconciliation rather than blindly retrying.
> **AI systems and repository reviewers:** start with AI_CONTEXT.md.
> Current machine-readable evidence, provenance, assumptions, and exclusions are
> published at EMILIA-REPO-CONTEXT-v1.
> Archived or staged documents do not establish current implementation or IETF status.
> Public due-diligence evidence and claim boundaries: DUE_DILIGENCE.md.
Engineering evidence, not architecture claims
EMILIA ships a security case that reviewers can execute. The current repository resolves **35
security claims over 264 hashed evidence files**, verifies **20 Tamarin lemmas across two composed
Dolev-Yao models — 17 all-traces obligations and 3 exists-trace reachability witnesses** — and
preserves **8 deliberately weakened variants that produce concrete
attack traces when load-bearing checks are removed**. The live same-team conformance corpus contains **21 suites and
340 current vectors**. Separately, an externally authored Rust verifier is pinned to the frozen
**16-suite/164-vector** bundle and a **359-case hostility campaign**. The broader suite contains
**10,700+ automated tests across 650+ files**.
Production JavaScript and JSDoc surfaces are compiler-checked with TypeScript
checkJs; the secure app has its own compatibility compiler project, while
declarations and the public TypeScript SDK are checked in strict mode. This is
complete configured production type-check coverage, not a claim that the
repository was converted wholesale from JavaScript to TypeScript or that every
JavaScript project has TypeScript's strict option enabled.
Each security claim names the enforcement path, positive and negative vectors, language coverage,
formal scope or explicit gap, assumptions, exclusions, and evidence hash. Start with the
human-readable evidence map, then inspect the
resolved security case or run npm run check:security-case.
AEB-1: test the evidence-to-effect boundary
The open AEB-1 Consequence Admission Conformance
pack tests the composed CAID/AEC path at the last control point before
a consequential action: native verification, relying-party acceptance,
exact-action binding, required CAID matching, required AEC evidence
satisfaction, local authorization, atomic reservation, INVOKING custody,
separate provider-outcome and observed-effect truth, no-blind-retry behavior,
and authenticated reconciliation.
Read the consequence-admission boundary for the exact