Authority Control Plane for Autonomous Work
EMILIA Protocol introduces an authority control plane designed to manage and enforce finite, customer-owned mandates for autonomous systems. At its core, the protocol operates through EMILIA Gate, a mechanism that enforces these mandates at protected executor boundaries. This ensures that autonomous agents—such as AI-driven tools or software agents—operate strictly within predefined limits. The open protocol architecture guarantees that all evidence of compliance remains verifiable, providing transparency and accountability in autonomous workflows.
The protocol separates identity, policy, and authority into distinct layers. Identity determines who or what is calling, policy defines what is generally allowed, and authority specifies the exact work an agent may perform under a given mandate. This separation prevents ambiguity and ensures that every consequential action is bound to a valid, finite authority.
The foundation of EMILIA Protocol consists of three interoperable objects: Trust Receipt, Trust Profile, and Trust Decision. A Trust Receipt carries attributable evidence, a Trust Profile represents structured trust state, and a Trust Decision records the relying party’s policy-evaluated result. These objects work together to enforce exact action binding, finite mandates, admission, consumption, and outcome evidence without collapsing into a single claim.
The protocol’s design ensures that mandates are set once and remain immutable unless explicitly updated. Agents operate within these predefined limits, and any deviation—such as a change in payment amount, recipient, or other critical parameters—triggers a refusal. This mechanism prevents unauthorized modifications and ensures that approvals are tied to specific, unalterable actions.
How It Works
EMILIA Gate functions as a gatekeeper at the boundary between an autonomous agent and a protected executor, such as a payment system, code deployment tool, or data access interface. Before an agent can execute a consequential action, Gate verifies that the request aligns with the predefined mandate. This verification process includes checking the exact action, its parameters, and the validity of any associated approvals.
The protocol employs a handshake mechanism for pre-action authorization, ensuring canonical binding, replay resistance, and one-time consumption of authority. Once an approval is granted, it is consumed and cannot be reused or modified. This design prevents replay attacks and ensures that each approval is tied to a specific instance of an action.
Gate operates alongside existing identity providers, agent frameworks, and business systems without requiring modifications to these components. It integrates seamlessly with tools like MCP (Machine-Centric Protocol) or HTTP-based services, Hugging Face’s smolagents, and GitHub merge checks. For example, in a GitHub workflow, Gate can bind a merge check to the proposed changes, ensuring that only approved actions proceed.
The protocol’s open architecture allows for independent verification of evidence. Any party can audit the evidence generated by EMILIA Gate using their own trusted keys and rules. This transparency is achieved through the use of verifiable receipts and structured trust profiles, which document the entire lifecycle of an action—from approval to execution and outcome.
For production deployments, EMILIA requires enrolled credentials, durable shared state, and Gate enforcement on every path leading to the protected provider credential. This ensures that no bypass paths exist where authority could be circumvented. The protocol does not guarantee the legitimacy of provider details (e.g., bank accounts) but focuses on enforcing the authority to perform actions within defined limits.
Use Cases
For example, an agent preparing an $82,000 supplier payment must adhere to the exact amount, currency, vendor, and destination specified in the approval. If any of these details change after approval, the system refuses to release the payment, maintaining the integrity of the financial process.
For instance, a production deployment tool can be configured to require approval for every release, with Gate binding the deployment to the specific version, environment, and authorized personnel. This prevents unauthorized or accidental deployments.
For AI-driven workflows, such as those involving Hugging Face’s smolagents, EMILIA provides a layer of control over tool execution. Agents can prepare actions like refunds or data processing, but these actions are only executed if they match the approved mandate. The protocol’s integration with smolagents allows developers to wrap existing tools with exact-action receipt checks, ensuring compliance with predefined rules.
In enterprise environments, EMILIA can be deployed to manage access to sensitive systems or data. For example, a GitHub merge check can be bound to a specific set of criteria, such as code review approvals or security scans. Gate ensures that only merges meeting these criteria are permitted, closing alternate paths that could bypass the enforcement mechanism.
The protocol also supports synthetic scenarios for testing and red teaming. These scenarios simulate real-world workflows without involving actual funds or production systems. For example, a synthetic refund demo allows users to test approval workflows, changed amounts, replay attacks, and lost provider responses in a controlled environment.
Key Features and Capabilities
The repository resolves 35 security claims over 264 hashed evidence files and verifies 20 Tamarin lemmas across two composed Dolev-Yao models. These models include 17 all-traces obligations and 3 exists-trace reachability witnesses, ensuring that the protocol adheres to strict security principles.
The protocol’s security posture includes 11,491 automated tests, 340 conformance vectors, and 35 executable security claims. These tests cover a wide range of scenarios, including boundary conditions, edge cases, and adversarial attacks. The security case is designed to be executable by reviewers, allowing them to verify the protocol’s claims independently.
The Python SDK relies solely on the standard library, ensuring broad compatibility. Both SDKs are compiler-checked with TypeScript’s checkJs for production type-check coverage.
The protocol’s open architecture allows for interoperability with existing systems. Users can integrate EMILIA with their current identity providers, agent frameworks, and business systems without requiring significant changes.
EMILIA provides tools for independent verification and conformance testing. The AEB-1 Consequence Admission Conformance pack tests the composed CAID/AEC path at the last control point before a consequential action. This includes native verification, relying-party acceptance, exact-action binding, and authenticated reconciliation. The results are self-attested conformance evidence, not an audit or certification.
These packs include preconfigured policies, signoff orchestration, and audit exports, making it easier for organizations to deploy the protocol in regulated environments.
EMILIA also supports a workforce workspace for managing AI-driven tasks. This workspace allows organizations to define jobs, set limits, and track work records for autonomous agents. The system ensures that agents operate within their mandates and that all actions are reviewable and accountable. This capability is particularly useful for red teaming and testing autonomous systems in controlled environments.
Security and Verification
The protocol’s security model is built on formal methods and extensive testing. Tamarin lemmas and Dolev-Yao models are used to verify the protocol’s resistance to common attacks, such as replay attacks, forgery, and unauthorized modifications. The security case is designed to be executable, allowing third-party reviewers to validate the protocol’s claims.
EMILIA includes a hostility campaign with 10,700+ automated tests across 650+ files. These tests cover a broad range of scenarios, including synthetic attacks, edge cases, and real-world adversarial conditions. The results are published as part of the protocol’s conformance evidence, ensuring transparency and accountability.
The protocol’s verification process includes a clean-room kit for independent implementation. This kit provides byte-pinned specifications, conformance suites, and implementation instructions, allowing external parties to build their own verifiers without accessing EMILIA’s source code. This ensures that the protocol’s security claims can be validated independently.
For TypeScript and JavaScript projects, EMILIA enforces strict type-checking using checkJs and TypeScript’s strict mode. The protocol’s security claims are explicitly documented, including enforcement paths, positive and negative vectors, language coverage, and assumptions.
The protocol’s documentation includes detailed evidence maps, security case resolutions, and conformance reports. These resources provide a comprehensive view of the protocol’s security posture and allow reviewers to inspect the evidence supporting its claims. The open format ensures that all evidence is verifiable and reproducible.