Put a refusal boundary in front of consequential machine action.
Protocol proves. Gate prevents.
On a configured, exclusively mediated path, EMILIA Gate sits immediately before protected execution. Before money moves, infrastructure changes, regulated records update, or irreversible state changes, Gate verifies the exact authority and evidence the resource owner requires, consumes accepted authorization once, and records the result.
On a fully mediated path, missing, stale, mismatched, or replayed evidence never reaches mutation. The open Protocol lets the relying party reproduce why the exact action passed or failed under its own pinned trust inputs.
If the required evidence does not verify, the protected system does not mutate.
The gate is deployed by the resource owner — the bank, the cloud API, the database, the robot controller, the grid. An agent that wants to act must present the mandate and evidence the owner requires for that exact work. The guarantee is only as strong as that mediation: every protected path must reach Gate at the actual system of record or actuator. Verification itself is open and can run offline without an EMILIA service.
Carry accepted evaluation evidence without turning it into execution authority.
Gate Qualification v2 converts accepted evaluation evidence into a portable, time-bounded qualification for one exact measured candidate and assignment. The qualification stays bound to its campaign, current status, runtime measurement, assignment, policy, and protected request.
Qualification travels. Authorization stays local. Gate controls the consequence.
The accepted campaign graph and current measurement match this exact candidate, assignment, policy, and request.
The resource owner separately requires AEB and AEC evidence, then applies local policy to decide whether this exact action may proceed.
Gate atomically reserves the operation and consumes one-time authority before the protected adapter can enter the provider.
Qualification is not authorization, certification, deployment evidence, or proof of a successful effect. A QUALIFIED result is evidence the local Gate may require; it cannot reserve resources, call a provider, or establish that an action is wise, legal, or safe.
Bound unresolved exposure without turning risk evidence into authorization.
Gate now carries customer-owned responsibility terms, declared open exposure, exact technical refusals, and bounded loss evidence alongside the existing authorization lifecycle. Each artifact stays a separate evidence leg under the relying party’s pinned program and authorities.
The relying party pins a separately signed loss-allocation schedule to the exact Reliance Program as an admissibility-profile policy input. The schedule never authorizes execution.
Before provider invocation, the durable ledger atomically reserves declared exposure against configured ceilings. INVOKING and INDETERMINATE stay open until independent reconciliation.
A signed statement binds the technical refusal to the exact action, failed requirements, challenge, nonce, custody, and time. It is not a legal or adverse-benefit denial.
A bounded-period attestation signs the supplied system-of-record and receipt roots, counts, joins, exceptions, and uncertainty. It does not prove that either population is complete.
Governed aggregate receipt buckets use coarse primary suppression. Signed loss-experience records preserve external provenance and correction lineage without becoming adjudicated losses.
The boundary: EMILIA does not insure, bear or allocate loss, adjudicate disputes or losses, establish legal enforceability, prove coverage, causation, solvency, or population completeness, or move money.
The product is the refusal sequence.
A dangerous action is not argued with. It is challenged, verified, bound to real execution fields, consumed once, and turned into a reliance packet. The demo runs locally with generated keys; no EMILIA server is trusted.
node packages/gate/demo.mjs # output: # release_payment, no receipt -> REFUSE 428 (receipt_required) # release_payment, observed drift -> REFUSE 428 (execution_binding_failed) # release_payment, class_a + bound -> ALLOW # same receipt again -> REFUSE 428 (replay_refused) # reliance packet -> RELY
Default packs for high-risk action families.
This is not just an amount threshold. EMILIA Gate treats entire action categories as high risk and binds the material system-of-record fields for each category.
Request → challenge → sign → verify → execute → proof.
When a mandate requires a fresh exact-action human or quorum decision, Gate can run this approval loop. It is one supported profile, not a requirement that every action receive a new human click; bounded mandates can authorize unattended work inside their finite scope.
Assurance tiers set the floor per action: software — A valid receipt — a software-held key. class_a — A device-bound human signoff (WebAuthn / passkey). quorum — m-of-n distinct humans — the cryptographic two-person rule.
Gate enforces. The surrounding layers keep authority bounded, open, and reproducible.
A distinct job at each control layer.
AgentROA governs calls. ORPRG proves policy permitted the effect. EMILIA verifies the exact authority and any required approver evidence under the relying party’s pinned rules, then controls admission at covered consequence boundaries.
EMILIA does not collapse machine delegation, machine policy, and human authorization into one verdict. CAID can correlate their native action descriptions only under the exact mapping profiles the relying party pins. A match is not authorization, and a missing or lossy mapping returns INDETERMINATE instead of guessing.
A QUALIFIED decision can satisfy only the qualification leg of Gate composition. Local authorization, atomic admission, provider entry, and effect evidence remain separate decisions.
One ordered path: reserve, execute, commit, prove.
`gate.run()` makes the ordering hard to get wrong. It reserves the receipt while the action is in flight, commits one-time consumption only after success, releases on pre-mutation failure, and returns the reliance packet.
Gate's experimental recovery developer surface follows buyer policy before execution. The reference scaffold demonstrates a mocked PostgreSQL transaction-control trace; it does not establish database mutation, durability, or sandbox confinement. After a provider may have acted but the result cannot be established, Gate consumes the reservation as indeterminate: no blind retry or refund. Any remedy is a new, separately authorized action. Remote compensation is a reserved-capacity building block, not a guarantee that an external effect can be reversed.
import { createTrustedActionFirewall } from '@emilia-protocol/gate';
const gate = createTrustedActionFirewall({
trustedKeys: [process.env.EMILIA_ISSUER_PUBKEY],
store: sharedConsumptionStore,
});
const observedAction = await paymentSystem.describeRelease('pi_123');
const out = await gate.run({
selector: { protocol: 'mcp', tool: 'release_payment' },
receipt,
observedAction,
}, () => paymentSystem.release(observedAction));
if (!out.ok) return out.body; // 428 Receipt Required
return out.packet; // auditor-ready reliance artifactAuthorize a bounded mission once. Let agents operate locally inside it.
A human signs the permitted action classes, targets, time window, and typed limits. The local engine checks each exact action against that program before the credential-owning adapter can act.
Child authority transfers from the signed root; it is never copied into an unlimited fleet credential.
Risk signals may reduce budgets, require review, suspend, or refuse. They cannot widen human-granted authority.
A lost provider result becomes INDETERMINATE and stays closed until authenticated reconciliation.
Current boundary: a private, single-host alpha for governed pilots. It makes no complete-mediation or customer-deployment claim; only actions forced through its adapter receive this control.
Design a bounded-authority pilot →The instruction, delegated budget, effect, and terminal evidence stay bound.
The receipt-program kernel freezes one CAID-bound action and stable operation ID, executes it through Gate's real bounded-capability path, and signs and records a content-addressed certificate over the bounded result and Gate evidence. It is a developer surface behind the Consequence Firewall, not a second policy engine or ledger.
Provider deadline expiry, response loss, or invalid output becomes INDETERMINATE. The budget and operation remain closed to blind replay. Production requires durable capability state, an atomic evidence log, KMS/HSM signing, a pinned certificate context, and a pinned result projection. Signing or logging failure preserves the Gate outcome without claiming complete proof.
npm run demo:receipt-program # Parent capability: 1000 USD -> delegated 100 USD # CAID: recomputed from the exact payment action # RECEIPT -> MATCH -> RESERVE -> EXECUTE -> COMMIT -> CERTIFY # Child capability remaining: 50 USD # Certificate: context-bound and present in the evidence log
Integrity and exact internal binding under a relying-party-pinned operator key and context, including CAID re-performance, action and operation identity, result digest, opcode sequence, authorization-to-execution linkage, and the complete certificate evidence record.
It is not a ZK proof, consensus result, provider attestation, or proof of legal, physical, or commercial correctness. Full re-performance still verifies the referenced authorization, capability, and evidence records under independent trust inputs.
One Gate pattern, several integration boundaries.
Does your integration actually enforce the gate — or are you just claiming it?
CF-1 is a public self-description, not a certification. EG-1 is the runnable Gate harness behind it: point the harness at your dangerous action; if it passes all eight checks, you have a reproducible conformance record instead of a claim. It makes an open PR crisp:“this makes delete_row earn EG-1 / CF-1.”
node packages/gate/eg1.mjs # EG-1 Conformance — does this integration ENFORCE EMILIA Gate? # PASS missing receipt -> 428 # PASS software receipt on Class-A action -> refused # PASS observed execution drift -> refused # PASS valid Class-A/quorum receipt -> runs # PASS same receipt replay -> refused # PASS tampered receipt -> refused # PASS execution proof binds to authorization decision # PASS reliance packet returns verdict "rely" # ✓ EG-1 Enforced (8/8)
Public definition: CF-1 Consequence Firewall conformance.
It does not stop every bad actor. It makes unauthorized paths visible and refusable.
A bad actor can build an unguarded machine. EMILIA Gate makes legitimate infrastructure refuse consequential actions that lack the authority evidence the resource owner requires — so parties with leverage can require an appropriate profile. It cannot constrain a path that bypasses Gate. Complete mediation requires the resource owner to place the verifier immediately before every protected mutation and to remove alternate execution paths. Necessary, not sufficient.