EMILIA Protocol

EMILIA Protocol

---

Laissez votre agent préparer le paiement. Contrôlez ce qu’il peut débloquer.

Un agent prépare un paiement de 82 000 $ à un fournisseur. Quelqu’un l’approuve. Puis le montant ou la destination bancaire change. L’approbation précédente ne doit pas autoriser le paiement modifié.

EMILIA Gate vérifie l’autorité avant l’exécution d’un outil protégé. Le protocole ouvert rend les preuves obtenues vérifiables de manière indépendante selon les clés et règles de confiance propres au vérificateur. Conservez votre fournisseur d’identité, votre framework d’agent et vos systèmes métier.

Exécuter l’exemple de paiement

Avec Node.js 20.19 ou une version ultérieure et npm installés :

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

L’exemple refuse un appel sans approbation, lie l’approbation au montant, à la devise, au fournisseur et à la destination, accepte une fois l’appel correspondant, et refuse les détails de paiement modifiés, les rejeux et les preuves falsifiées. Consultez l’exemple et ses limites.

Il s’agit d’une démonstration locale : clés de signature générées, consommation en mémoire et outil de paiement simulé. Elle ne met pas en œuvre une véritable procédure humaine et ne transfère pas d’argent. La production nécessite des identifiants enrôlés, un état partagé durable et Gate sur chaque chemin menant à l’identifiant du fournisseur protégé. Une approbation valide ne prouve pas que les coordonnées bancaires sont légitimes.

Vous préférez un navigateur ? Essayez une passkey sur un paiement d’exemple. Cette démonstration distincte montre l’intégrité du reçu avec l’authentificateur de votre plateforme ; aucun paiement n’est envoyé.

Protéger un outil que vous utilisez déjà

Commencez par le service qui détient le véritable identifiant du fournisseur, et pas seulement par le processus de l’agent. Le propriétaire définit les opérations autorisées et les cas où une nouvelle approbation est requise. Un agent peut travailler dans ces limites sans qu’une personne approuve chaque appel.

• MCP ou HTTP : Gate Starter présente une action protégée.
• Hugging Face smolagents : encapsuler un outil existant.
• GitHub : Merge Gate lie une vérification à la fusion proposée. Cette vérification doit être obligatoire et les autres chemins de fusion doivent être fermés.

Le protocole prouve. Gate empêche sur les chemins entièrement médiés par le déploiement. Gate ne peut pas contraindre un chemin de contournement. Si le résultat d’un fournisseur est inconnu, le cycle de vie de production préserve cette incertitude pour la réconciliation au lieu de réessayer aveuglément.

Systèmes d’IA et personnes chargées de la revue des dépôts : commencez par AI_CONTEXT.md. Les preuves lisibles par machine actuelles, leur provenance, les hypothèses et les exclusions sont publiées dans EMILIA-REPO-CONTEXT-v1. Les documents archivés ou en préparation n’établissent ni l’implémentation actuelle ni le statut auprès de l’IETF. Éléments publics de diligence raisonnable et limites des affirmations : DUE_DILIGENCE.md.

Des preuves d’ingénierie, pas des affirmations d’architecture

EMILIA fournit un dossier de sécurité que les personnes chargées de la revue peuvent exécuter. Le dépôt actuel résout 35 affirmations de sécurité sur 264 fichiers de preuves hachés, vérifie 20 lemmes Tamarin dans deux modèles Dolev-Yao composés — 17 obligations valables pour toutes les traces et 3 témoins d’accessibilité par trace existante — et conserve 8 variantes volontairement affaiblies qui produisent des traces d’attaque concrètes lorsque des vérifications essentielles sont supprimées. Le corpus de conformité actif de la même équipe contient 21 suites et 340 vecteurs actuels. Séparément, un vérificateur Rust rédigé par un tiers est épinglé au lot figé de 16 suites/164 vecteurs et à une campagne d’hostilité de 359 cas. La suite plus large comprend plus de 10 700 tests automatisés répartis dans plus de 650 fichiers.

Les surfaces JavaScript de production et JSDoc sont vérifiées par le compilateur TypeScript checkJs ; l’application sécurisée dispose de son propre projet de compilation de compatibilité, tandis que les déclarations et le SDK TypeScript public sont vérifiés en mode strict. Il s’agit d’une couverture complète de vérification de types pour la production configurée, et non d’une affirmation selon laquelle le dépôt aurait été entièrement converti de JavaScript à TypeScript ou que chaque projet JavaScript aurait activé l’option strict de TypeScript.

Chaque affirmation de sécurité précise le chemin d’application, les vecteurs positifs et négatifs, la couverture linguistique, la portée formelle ou la lacune explicite, les hypothèses, les exclusions et le hachage des preuves. Commencez par la carte des preuves en langage clair, puis examinez le dossier de sécurité résolu ou exécutez npm run check:security-case.

AEB-1 : tester la frontière entre les preuves et les effets

Le pack ouvert AEB-1 Consequence Admission Conformance teste le chemin CAID/AEC composé au dernier point de contrôle avant une action ayant des conséquences : vérification native, acceptation par la partie utilisatrice, liaison à l’action exacte, correspondance CAID requise, satisfaction des preuves AEC requises, autorisation locale, réservation atomique, garde de INVOKING, distinction entre la vérité du résultat du fournisseur et celle de l’effet observé, absence de nouvelle tentative aveugle, et réconciliation authentifiée.

Lire la frontière d’admission des conséquences pour connaître la répartition exacte des responsabilités entre le chemin CAID/AEC composé, le chemin natif direct, la garde AEB et les preuves du résultat du fournisseur.

npx @emilia-protocol/verify aeb-conformance --reference

Il est indépendant du format et s’exécute de manière autonome. Un rapport positif constitue une preuve de conformité auto-attestée, et non un audit, une certification, une affirmation de déploiement en production ou une autorisation d’exécuter une action.

Selon AEB-07, publié le 2026-09-25 en tant qu’Internet-Draft individuel et non adopté par un groupe de travail, CAID n’est utilisé que lorsque des actions encodées indépendamment doivent être jointes, et AEC n’est utilisé que lorsque la politique locale exige plusieurs éléments de preuve. Un corpus synthétique distinct de 26 cas modélise ce cycle de vie natif direct sur AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token et les résultats d’adaptateurs de mandats signés locaux :

npm run conformance:composition:consequence-admission

Le lanceur du corpus est un modèle de cycle de vie autonome, doté de son propre stockage en mémoire et de sa propre logique d’admission. Il n’exécute pas le code livré @emilia-protocol/verify ou @emilia-protocol/gate, et ne constitue donc pas une preuve pour ces packages, qui disposent de leurs propres suites de tests. Il ne prouve pas non plus que les protocoles natifs nommés sont conformes à AEB-07.

Pour une preuve exécutable ciblée du chemin Gate du dépôt, exécutez :

npm run proof:gate:reference

Cette commande exécute des exemples locaux et des tests ciblés des frontières de service avec des clés générées, un état en mémoire et un comportement de fournisseur simulé. Il s’agit d’une preuve locale utile, et non d’une preuve impliquant une véritable personne, une banque externe, un déploiement en production ou une intégration de production de bout en bout.

L’identité n’est pas une description de poste

L’identité indique qui ou quoi appelle. La politique indique ce qui est généralement autorisé. Ni l’une ni l’autre ne définit le travail limité qu’un agent autonome peut effectuer maintenant : sa mission, les limites des actions importantes, le budget, les preuves requises, l’expiration, les règles de délégation et la procédure d’exception.

EMILIA sépare ces questions :

Couche	Question
Identité	Qui ou quoi est présent ?
Politique	Qu’est-ce qui est généralement autorisé ?
Autorité	Quel travail exact cet agent peut-il effectuer dans le cadre de ce mandat ?

Les identifiants donnent accès. L’autorité définit le travail. Toutes les actions n’exigent pas une intervention humaine ; chaque action ayant des conséquences exige une autorité valide.

À la base, EP Core expose toujours trois objets interopérables : un Trust Receipt porte des preuves attribuables, un Trust Profile représente un état de confiance structuré et une Trust Decision consigne le résultat évalué selon la politique de la partie utilisatrice. Les couches du plan de contrôle de l’autorité ajoutent la liaison à l’action exacte, les mandats limités, l’admission, la consommation et les preuves de résultat, sans fusionner ces objets en une seule affirmation.

---

Définir le mandat une fois. Laisser l’agent travailler.

Le client définit la mission, les limites, les exigences en matière de preuves, l’expiration et les règles d’exception. Le code local peut restreindre cette autorité ; il ne peut ni l’inventer ni l’élargir. Gate lie chaque requête exécutable au mandat, réserve l’autorité couverte avant l’entrée chez le fournisseur, autorise une seule tentative d’appel au fournisseur admise pour cette instance d’autorisation dans le domaine d’autorité durable partagé, et ne demande une intervention que lorsque l’autorité est absente, périmée, épuisée ou trop limitée.

Les exemples MCP fournis mettent à l’épreuve un profil de politique exigeant une approbation à la frontière. Ils génèrent des clés de signature de démonstration et appellent des outils simulés. L’exemple de paiement lie les quatre champs importants déclarés ; les autres exemples illustrent des liaisons de ressources plus restreintes. Ils ne recueillent pas une véritable décision humaine et ne contactent pas de fournisseur :

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

La démonstration de composition plus approfondie exécute un paiement délégué lié à CAID par le véritable chemin de capacité limitée de Gate, puis vérifie hors ligne le certificat d’exécution signé :

npm run demo:receipt-program

Elle n’inclut volontairement ni blockchain ni affirmation simulée de preuve à divulgation nulle de connaissance. Consultez l’architecture du programme de reçus pour connaître les exigences de production en matière d’état et de confiance.

Commencez par une action MCP déclarée ayant des conséquences. Installez l’environnement d’exécution local exact, puis créez son Gate Starter et exécutez la vérification limitée en quatre cas :

npm install --save-exact @emilia-protocol/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

La vérification locale générée utilise un état de démonstration explicitement éphémère et prouve uniquement les cas synthétiques indiqués : absence, correspondance exacte, modification, rejeu et outil non analysé. La commande examinée crée un transfert de contexte respectueux de la confidentialité ; elle n’active pas Gate. La production nécessite un registre de provenance durable, un stockage partagé de consommation atomique, des clés épinglées et l’encapsuleur sur chaque chemin menant au véritable identifiant du fournisseur. Consultez examples/mcp/ et /mcp.

Bloquer les nouvelles actions sans prétendre annuler les anciennes

Le gel d’urgence de l’autorité de Gate bloque les nouvelles réservations et empêche les réservations antérieures d’entrer après le changement d’époque du domaine de contrôle couvert. Si l’entrée chez le fournisseur a déjà eu lieu, la tentative reste consommée et doit être réconciliée. Le rétablissement de l’autorité ne réactive pas une ancienne réservation.

Cela exige une médiation complète et un état partagé faisant autorité. Cela n’arrête pas les calculs, n’annule pas un effet et n’atteint pas instantanément les domaines déconnectés. Consultez l’implémentation et les limites du domaine de contrôle.

Essayez en 30 secondes

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

Essayez une passkey de plateforme sur un paiement d’exemple → Signez un paiement illustratif de 82 000 $, modifiez son montant et constatez l’échec de la vérification d’intégrité. Votre authentificateur peut utiliser la biométrie ou le code PIN d’un appareil. La page propose également une simulation logicielle distincte. Aucun des deux modes n’envoie de paiement ni n’établit une autorisation de production.

Vérifiez n’importe quel reçu dans votre navigateur — collez-le, rien n’est téléversé.

---

Fonctionnement — un cycle de vie de l’autorité

Exécutez-le vous-même : node examples/crash-test.mjs — entièrement hors ligne, sans clé API.

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

Mandat. La source d’autorité définit un travail limité. Il peut s’agir d’un programme opérationnel signé par le client, d’une capacité limitée, d’une décision humaine requise, d’un quorum ou d’une composition de preuves natives par une partie utilisatrice.

Travail exact. Gate lie la méthode, l’origine, l’appelé, la cible, l’occurrence et chaque champ important dans l’objet exécutable canonique. Une intention, une invite ou le texte d’un ticket ne constitue pas cet objet.

Vérifier, réserver et entrer. Les artefacts natifs restent natifs. La partie utilisatrice épingle les profils de confiance et de correspondance, évalue l’ensemble des preuves requises, prend la décision d’autorisation locale distincte et réserve l’autorité couverte avant que l’adaptateur détenant l’identifiant n’entre chez le fournisseur.

Autorité humaine récente lorsqu’elle est requise. Une politique peut exiger une décision WebAuthn/passkey liée à l’action exacte et à un hachage d’affichage déterministe. Cela réduit l’écart entre « ce que vous avez vu » et « ce que vous avez signé » ; cela ne prouve ni la compréhension, ni la sagesse, ni la légalité, ni le résultat. Pour les déploiements d’entreprise, Gate peut également exiger une confirmation du serveur d’autorisation vérifiée indépendamment et liée à cette preuve humaine exacte, à la même action exacte, à l’instantané d’identité effectivement observé par l’AS et à la clé du serveur de ressources visé. L’heure de l’instantané et l’âge maximal accepté par la partie utilisatrice sont explicites : un jeton récent ne peut pas rendre actuelles des données d’annuaire obsolètes. Le volet AS constitue une preuve fondée sur la confiance épinglée par le client ; il n’autorise jamais à lui seul, ne prouve pas le statut professionnel à l’instant présent et ne transforme pas l’orchestrateur de l’agent en autorité.

Résultat véridique. L’admission n’est pas l’exécution, et l’exécution n’est pas l’effet. Un enregistrement signé peut être vérifié hors ligne ; les preuves du fournisseur et de l’observateur restent distinctes. Une réponse perdue devient INDETERMINATE, un état à réconcilier — et non une autorisation de réessayer. Un recours est une nouvelle action autorisée et ne réécrit jamais l’ancien résultat.

---

Pourquoi les développeurs l’utilisent

Commencez par cartographier le travail localement, puis protégez une surface d’action déclarée avec le serveur MCP ou un wrapper SDK léger. L’analyseur propose une cartographie vérifiable ; le propriétaire définit le mandat ; Gate détient les identifiants du fournisseur et applique l’action exacte sur le chemin couvert. Aucun scan ne prouve une médiation complète, et la découverte seule ne confère aucune autorité.

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

L’agent reçoit la capacité d’effectuer un travail délimité, et non un identifiant permanent qu’il pourrait réinterpréter.

---

Pourquoi les entreprises en ont besoin

Les processus d’agent redémarrent et les modèles changent. Le mandat du client, l’état de consommation, la révocation, l’incertitude et l’historique du travail doivent leur survivre. EMILIA conserve cet état d’autorité durable à la frontière du client tout en acceptant des preuves externes par l’intermédiaire d’adaptateurs épinglés.

Le plan Gate et Assurance géré ajoute des opérations de mandat, des intégrations, des opérations de preuve, une nouvelle exécution, de l’assistance et des niveaux de service autour du protocole ouvert. Le client conserve le contrôle de l’autorité, des racines de confiance, des identifiants, de la politique et des preuves portables.

---

La norme

EMILIA Protocol est ouvert et sous licence Apache-2.0. Ses travaux de normalisation sont publiés sous la forme d’un ensemble de projets Internet individuels. Un projet Internet publié n’est ni une RFC, ni un élément adopté par un groupe de travail, ni une approbation de l’IETF ; Datatracker fait autorité pour les révisions et le statut.

Enregistrements IANA

Deux noms enregistrés fournissent aux implémenteurs une référence commune pour les formats EMILIA :

• application/vnd.emilia.authorization-evidence-challenge+json a été enregistré le 6 octobre 2026. Il désigne l’objet JSON AE-CHALLENGE-v1 brut défini par la spécification de sérialisation publiée. Les réponses HTTP de refus continuent d’utiliser application/problem+json.
• canactid: a été enregistré provisoirement le 5 octobre 2026. Il désigne des actions typées exactes selon CAID-05. Son numéro de schéma CRI corrigé est 1033.

Ces enregistrements publient les noms et leurs spécifications. Ils n’établissent ni adoption par l’IETF, ni approbation, ni certification, ni déploiement chez les clients.

Une surface de frontière de conséquence

La version publiée actuelle AEB-07, publiée le 2026-09-25 en tant que projet Internet individuel et non adoptée, fait d’AEB le point de composition après une décision native. OAuth, AuthZEN, COAZ, AP2 et les systèmes locaux conservent la maîtrise de leurs identifiants, de leurs correspondances d’opérations et de leurs décisions d’autorisation. AIMS (draft-ietf-wimse-aims) est un document informatif du groupe de travail WIMSE qui décrit des normes existantes telles que WIMSE et OAuth ; il ne délivre pas lui-même d’identifiants ni de décisions. AEB applique la décision native à la frontière du fournisseur protégé : il lie l’action finale si nécessaire, dérive une identité native de rejeu par autorisation, réserve avant l’entrée chez le fournisseur, refuse une seconde tentative pour la même action tant qu’une tentative antérieure est en cours ou incertaine, et maintient un résultat incertain verrouillé jusqu’à sa réconciliation authentifiée.

CAID-05 est utilisé lorsque des représentations encodées indépendamment doivent être comparées. Les nouveaux identifiants utilisent le schéma URI canactid: enregistré provisoirement par l’IANA. Cet enregistrement ne constitue ni une adoption par l’IETF, ni une approbation, ni une certification, ni un statut permanent. CAID n’est pas une seconde correspondance obligatoire lorsque le PEP qui assume déjà la responsabilité de la conséquence dérive et applique une décision actuelle sur l’opération finale. Essayez l’environnement de test des actions exactes ou consultez le guide de migration de CAID-04 vers CAID-05. AEC-06 est utilisé lorsque la partie utilisatrice exige plusieurs volets de preuve. Les profils Authorization Receipts, Human Authorization Binding et Authority Introduction restent disponibles pour les déploiements qui en ont besoin ; ils ne sont pas des prérequis pour chaque intégration AEB. Architecture-03 reste le document de référence pour la navigation.

Le guide d’admission des conséquences précise la frontière d’implémentation et les cas où AEB est inutile. Le profil de transfert natif direct est un profil d’implémentation du dépôt qui montre comment une autorisation existante parvient à Gate sans couche CAID ou AEC supplémentaire. AEB-07 spécifie ce qu’un tel transfert de passerelle atteste et comment la frontière le vérifie, mais laisse l’encodage aux épinglages du déploiement ; il cite un instantané épinglé de ce profil comme encodage de référence informatif. Les octets exacts soumis pour la version -07 et leur enregistrement de publication sont conservés dans standards/staged/NEXT-AEB-07.

L’ensemble actif complet comprend 26 enregistrements Datatracker : 21 rédigés par un seul auteur et cinq coécrits, chacun ayant son propre périmètre, son historique de révision et son statut de maintenance enregistré. Consultez le guide des normes, le portefeuille et l’inventaire des statuts lisible par machine.

Projets Internet de l’IETF	Chemins de l’instantané local actuel : inventaire des statuts · inventaire des projets publiés par un seul auteur · statut officiel en direct : IETF Datatracker
Vérificateurs multilingues	JavaScript · Python · Go — les trois ont démontré leur concordance sur des vecteurs de conformité adversariaux, à chaque push (npm run conformance). Vérification de cohérence entre les ports d’une même équipe, et non implémentations indépendantes réalisées en environnement vierge. Séparément, une implémentation Rust externe, écrite à partir des spécifications (source publique), réussit le lot épinglé de 16 suites/164 vecteurs et la campagne d’hostilité épinglée de 359 cas lors d’une reconstruction contrôlée par l’évaluateur à partir d’un arbre source immuable. Les éléments de construction enregistrés dans le dépôt restent signés par l’implémenteur, et non attestés par un tiers (déclaration signée) ; l’acceptation stricte en environnement vierge attend le manifeste corrigé attesté par un tiers et la clé d’attestateur épinglée indépendamment.
Éléments de preuve du modèle formel	26 propriétés de sûreté TLA+ bornées sont vérifiées dans leurs espaces d’états configurés ; cela ne constitue ni un raffinement de l’implémentation ni une preuve non bornée · 35 faits Alloy, 32 assertions réparties sur quatre modèles · deux modèles symboliques Dolev-Yao composés couvrant le défi, CAID, deux approbations, les épinglages d’émetteur et d’autorité, la vue du registre, la révocation, la consommation, l’exécution et six limites de revendication dédiées. Vingt lemmes Tamarin sont vérifiés — 17 obligations valables pour toutes les traces et 3 témoins d’existence de trace ; huit variantes volontairement affaiblies produisent des traces d’attaque concrètes lorsque des contrôles essentiels sont supprimés (formal/tamarin/).
Distribution MCP	Paquet npm @emilia-protocol/mcp-server · la publication officielle dans le Registry est suivie séparément dans MCP-REGISTRY.md ; la présence dans les agrégateurs n’est déduite d’aucun de ces états
Licence	Apache-2.0

Trois ports de référence de la même équipe (JS / Python / Go) concordent sur les 21 suites et les 340 vecteurs. Séparément, une implémentation Rust externe, reconstruite à partir d’un arbre source public épinglé, réussit le lot en environnement vierge épinglé de 16 suites/164 vecteurs et une campagne d’hostilité de 359 cas, relancée dans sa propre voie CI à chaque modification. Les nouvelles suites d’acceptation AEC et de résolution à quatre résultats ne sont pas attribuées à Rust. Il s’agit d’éléments de preuve d’interopérabilité externe, et non d’une acceptation stricte de construction en environnement vierge ; le dossier CI agrégé indique zéro acceptation stricte en attente d’une attestation indépendante. Consultez CONFORMANCE.md, ou vérifiez vous-même un reçu sur emiliaprotocol.ai/verify.

---

La pile d’autorité

Couche	Fonction
Mandat	Définit la mission, les limites, les preuves, l’expiration, la délégation et les règles d’exception.
CAID / action exacte	Compare le sens matériel lorsque l’autorisation et l’exécution utilisent des représentations encodées indépendamment ; n’autorise pas.
AEC	Lorsque cela est requis, évalue si des preuves vérifiées et mises en correspondance indépendamment satisfont l’exigence multipartite de la partie utilisatrice ; n’autorise pas.
AEB / Gate	Applique la décision d’autorisation native ou locale à la frontière de conséquence, réserve l’autorité couverte et contrôle l’entrée chez le fournisseur.
Preuves de résultat	Distingue l’invocation, la réponse du fournisseur, l’effet observé et l’incertitude.

---

Points de preuve

Indicateur	Valeur
Cas de test automatisés	Plus de 10 700 répartis sur plus de 650 fichiers ; tous les cas applicables à la plateforme doivent réussir
Propriétés de sûreté TLA+	26 invariants bornés vérifiés dans l’espace d’états configuré ; ne constituent ni un raffinement de l’implémentation ni une preuve non bornée — voir PROOF_STATUS.md
Assertions relationnelles Alloy	35 faits + 32 assertions répartis sur quatre modèles — vérifiés en CI
Cas d’équipe rouge répertoriés	86 — RED_TEAM_CASES.md
État de sécurité de la version	Les contrôles de sécurité du dépôt réussissent ; chaque constat Strix concernant les modifications auditées est corrigé avec une couverture de régression et son fil de revue est résolu
Conformité (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Conformité multilingue	340 vecteurs · 21 suites : reçus · validations d’appareil · résolution à quatre résultats · quorum multipartite · révocation · liaison de résultat (sémantique + cryptographie réelle) · jonction émetteur du document/de la preuve d’autorité · attestation temporelle · reçu de confiance (2 profils) · provenance · enregistrement de preuve · canonicalisation · frontière · acceptation AEC · devise · attestation de l’initiateur · preuve de consommation · témoin · preuve d’horodatage (RFC 3161). Les vérificateurs JS / Python / Go concordent (node conformance/run.mjs). La référence Rust externe reste à 164 vecteurs / 16 suites. Voir CONFORMANCE.md.
p95 de création de poignée de main	575 ms à 50 VU — PERFORMANCE_PROOF.md

Longévité cryptographique (avec limites de déploiement explicites)

Les preuves destinées à être vérifiées des années plus tard doivent survivre aux algorithmes avec lesquels elles ont été signées. EP fournit quatre capacités délimitées à cette fin, chacune assortie d’une limite exacte qui fait partie de l’affirmation :

• Signatures hybrides (EP-RECEIPT-HYBRID-v1). Ed25519 et ML-DSA-65 sur les mêmes octets canoniques, avec l’ensemble d’algorithmes requis inscrit dans les octets signés, de sorte que la suppression d’une composante invalide la signature restante. Cette capacité est activée de manière facultative lors du déploiement ; dès qu’un signataire double approuvé est enregistré et que la politique autorise sa composante PQ, une posture Gate non épinglée choisit par défaut l’émission double. Sinon, elle reste exclusivement classique, avec une raison explicite. Les vérificateurs v1 rejettent proprement les reçus hybrides au lieu d’accepter une seule composante. Le contrat du signataire externe et l’adaptateur AWS KMS sont implémentés, mais aucune signature AWS en direct, clé de production, vérification par une partie utilisatrice ni validation FIPS de ML-DSA n’est revendiquée. Voir conformance/hybrid-receipts/ et lib/pq-custody-aws-kms.ts.
• Profil SCITT Signed Statement (EP-SCITT-STATEMENT-v1). Une structure complète de Signed Statement conforme à la RFC 9943 pour les reçus EP, y compris l’en-tête protégé CWT Claims. Limite : aucun Transparency Service n’a accepté de déclaration EP ; l’enregistrement externe est une étape distincte soumise à autorisation, et aucun enregistrement n’a été effectué. Voir EP-RECEIPT-SCITT-PROFILE.md.
• Réattestation (EP-EVIDENCE-REATTESTATION-v1). Les preuves signées avec un algorithme vieillissant peuvent être réancrées avec un algorithme actuel avant que l’ancien ne s’affaiblisse. Limite : la réattestation doit précéder la compromission ; elle ne peut pas réparer les preuves après coup.
• Mode de déploiement FIPS (EP-FIPS-MODE-v1). Exécute les opérations classiques au moyen d’un fournisseur validé FIPS 140-3 fourni par l’opérateur, la voie ML-DSA étant soumise à une confirmation explicite de l’utilisation d’une implémentation non validée. Limite : cela permet de revendiquer des « algorithmes fondés sur FIPS, avec un mode de déploiement utilisant un fournisseur validé » et dépend du fournisseur de l’opérateur et du périmètre de certification déclaré ; il ne s’agit pas d’une revendication générale de conformité, et rien ici n’est validé FIPS. Voir FIPS-MODE.md.

Le programme hybride à l’échelle de la pile (toutes les surfaces de signature internes) est décrit dans pq-hybrid-program.md et n’est pas terminé ; tant qu’il ne l’est pas, aucune revendication générale concernant l’ensemble de la pile n’est formulée.

---

Objets fondamentaux du protocole

Objet	Description
Programme d’autorité / capacité délimitée	Un mandat limité avec un périmètre, un budget ou des unités, une expiration, une délégation et des règles de consommation explicites.
CAID	Un identifiant canonique pour une action matérielle selon un profil de correspondance nommé ; la correspondance ne vaut pas autorisation.
Exigence de preuve et résultat AEC	La règle épinglée par la partie utilisatrice et son évaluation SATISFIED, UNSATISFIED ou INDETERMINATE.
Admission AEB et registre de garde	Le registre côté exécuteur de l’autorisation, de la réservation, de l’entrée chez le fournisseur et de l’état de rapprochement.
Preuves d’autorisation et de résultat	Des artefacts natifs ou EP portables qui conservent exactement leur émetteur, leur périmètre et les limites de leurs revendications.

---

Démarrage rapide

1. Installez le runtime de garde local exact, puis exécutez npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify, en remplaçant sendWire par un outil conséquent exact et déclaré.
2. Examinez la carte d’autorité générée, le manifeste d’action, les champs matériels, la limite sélectionnée et les angles morts nommés.
3. Exécutez la commande distincte --reviewed --crossing-profile <launch-profile> pour créer le transfert réservé au propriétaire et l’espace de travail Lab non scellé à partir de ces octets inchangés.
4. Installez Gate sur le chemin qui détient les identifiants du fournisseur et l’état de consommation durable.
5. Définissez le mandat opérationnel ainsi que les règles d’exception exigeant une intervention humaine récente ou un quorum.
6. Exécutez les cas de refus, d’action exacte, de rejeu, de délai d’attente et de rapprochement avant d’activer l’application des règles.

Démo de 90 secondes · Démarrage rapide · Présentation guidée de l’agent · Brouillon IETF · Discord

---

Ce qu’est EP — et ce qu’il n’est pas

EMILIA est une infrastructure d’autorité pour le travail autonome, et non un système d’identité, un portefeuille, un score de réputation, un mécanisme de règlement ou un moteur de politiques universel.

• C’est : un plan de contrôle pour les mandats opérationnels limités, la vérification d’actions exactes, l’état d’admission durable, la représentation fidèle de l’incertitude et les preuves portables sur les chemins d’exécution couverts.
• Ce n’est pas : un remplacement d’OAuth/OIDC, de l’identité des charges de travail ou des moteurs de politiques. Ceux-ci restent des entrées natives selon les paramètres épinglés par la partie utilisatrice.
• Ce n’est pas : une exigence d’approbation humaine pour chaque action. Un mandat peut autoriser le travail automatique dans des limites finies et exiger une nouvelle autorisation uniquement à la limite.
• Ce n’est pas : une preuve qu’une action admise a été exécutée avec succès ou a produit l’effet voulu.
• Ce n’est pas : un contrôle propriétaire du protocole. Le cœur est sous licence Apache-2.0 et les Internet-Drafts sont des soumissions individuelles, pas des RFC ni une approbation de l’IETF.

Voir CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Pacte de neutralité