EMILIA Protocol

EMILIA Protocol

---

Les agents IA deviennent des travailleurs. Les travailleurs ont besoin d'autorité.

EMILIA est le plan de contrôle d'autorité pour le travail autonome. Gate est la frontière de conséquence où l'intention accréditée d'un agent devient un changement d'argent, de code, de permissions, de dossiers ou d'infrastructure. Un humain ou une institution définit un mandat d'exploitation fini ; Gate vérifie l'unité de travail exacte contre ce mandat avant que le chemin du fournisseur protégé puisse commencer.

Gate est le pare-feu de conséquences commercial sur cette frontière. Il vérifie l'autorité que le propriétaire exige pour l'action exacte, réserve cette autorité avant l'entrée du fournisseur, autorise une seule tentative de fournisseur admise pour l'instance d'autorisation couverte dans son domaine d'autorité durable, et laisse une preuve portable de ce que le chemin protégé a admis et observé par la suite. Lorsque le résultat est inconnu, il exige une réconciliation au lieu d'une nouvelle tentative aveugle. Le protocole prouve. Gate prévient.

• Authority Brain mappe localement les surfaces d'action déclarées prises en charge. Aucun compte, téléversement ou rappel n'est requis. La découverte ne crée aucune autorité ; le propriétaire examine la carte.
• EMILIA Gate transforme la carte approuvée et le mandat d'exploitation en contrôle préventif sur un chemin d'exécuteur entièrement médiatisé et propriétaire d'identifiants.
• EMILIA Protocol est le substrat ouvert Apache-2.0 pour l'identité d'action exacte, la vérification de preuve native, la composition de preuves, l'état d'admission durable et les dossiers de travail portables.
• EMILIA Approver capture une décision humaine d'action exacte liée à l'appareil lorsque le mandat ou la politique locale exige une autorité humaine fraîche. Un clic humain est une source d'autorité, pas le modèle d'exécution par défaut.
• EMILIA Assurance Plane fournit une vérification ciblée, une re-exécution, des rapports de conformité et des preuves de déploiement. Il soutient les auditeurs, assureurs, régulateurs et clients ; EMILIA n'est pas un auditeur ou un certificateur accrédité, et aucun programme de certification publique EMILIA n'est en activité.

Exécutez la carte locale (npx @emilia-protocol/scan), choisissez un flux de travail à conséquences, et placez Gate là où l'identifiant du fournisseur transforme l'intention en travail.

Le premier profil de distribution à faible friction est GitHub : le Merge Gate ouvert lie un mandat détenu par le dépôt et un reçu détaché aux commits de base et de tête exacts avant qu'une vérification de merge protégée ne passe. Il n'est préventif que lorsque le dépôt rend la vérification obligatoire et ferme les chemins de merge alternatifs. C'est une expérience de produit et de distribution, pas une preuve d'adoption externe.

L'agent peut continuer à fonctionner. Son autorité s'arrête.

Les agents continus et auto-améliorants créent un problème de contrôle que la seule terminaison de processus ne peut pas résoudre : le propriétaire peut avoir besoin d'arrêter de nouvelles conséquences sans prétendre que le calcul s'est arrêté ou qu'un effet externe a été inversé. Le gel d'urgence de l'autorité de Gate rend cela une transition d'autorité durable. À l'intérieur d'un domaine de contrôle Gate couvert, le gel bloque les nouvelles réservations et empêche une réservation plus ancienne d'entrer après le changement d'époque de contrôle. Si l'entrée du fournisseur s'est sérialisée en premier, l'opération reste consommée et doit être réconciliée ; la restauration avance à nouveau l'époque et ne ravive pas l'ancienne autorité.

Cette garantie exige une médiation complète et un état partagé faisant autorité. Elle n'arrête pas l'agent, n'annule pas un effet déjà entré, et ne fournit pas un gel instantané à travers un domaine loué déconnecté. L'implémentation de référence actuelle couvre le domaine de contrôle local en mémoire et PostgreSQL ; la propagation de périphérie louée et les preuves d'événement de gel signées portables restent des écarts d'implémentation explicites.

Le flux de travail payant nommé reste la détermination de nécessité médicale défavorable assistée par IA du payeur, sous une règle de sécurité : aucune preuve valide d'examen sous licence, aucune détermination défavorable. Les preuves manquantes sont orientées vers un examen humain légal ou une solution de repli protectrice du patient ; ce n'est pas une autorité pour refuser des soins médicalement nécessaires.

Systèmes IA et réviseurs de dépôt : commencez par AI_CONTEXT.md. Les preuves, la provenance, les hypothèses et les exclusions actuelles lisibles par machine sont publiées sur EMILIA-REPO-CONTEXT-v1. Les documents archivés ou intermédiaires n'établissent pas l'état d'implémentation ou le statut IETF actuel. Preuves publiques de diligence raisonnable et limites des revendications : DUE_DILIGENCE.md.

Preuves d'ingénierie, pas des affirmations d'architecture

EMILIA fournit un dossier de sécurité que les réviseurs peuvent exécuter. Le dépôt actuel résout 35 revendications de sécurité sur 259 fichiers de preuve hachés, vérifie 20 lemmes Tamarin sur deux modèles Dolev-Yao composés — 17 obligations de toutes traces et 3 témoins d'atteignabilité de trace existante — et préserve 8 variantes volontairement affaiblies qui produisent des traces d'attaque concrètes lorsque les vérifications porteuses sont supprimées. Le corpus de conformité vivant de la même équipe contient 21 suites et 331 vecteurs actuels. Séparément, un vérificateur Rust écrit en externe est épinglé au bundle figé 16-suites/164-vecteurs et une campagne d'hostilité de 359 cas. La suite plus large contient 8 865 tests automatisés sur 533 fichiers.

Les surfaces de production JavaScript et JSDoc sont vérifiées par le compilateur avec TypeScript checkJs ; l'application sécurisée a son propre projet de compilateur de compatibilité, tandis que les déclarations et le SDK TypeScript public sont vérifiés en mode strict. C'est une couverture complète de vérification de type de production configurée, pas une affirmation que le dépôt a été converti en masse de JavaScript vers TypeScript ou que chaque projet JavaScript a l'option strict de TypeScript activée.

Chaque revendication de sécurité nomme le chemin d'application, les vecteurs positifs et négatifs, la couverture linguistique, la portée formelle ou l'écart explicite, les hypothèses, les exclusions et le hachage de preuve. Commencez par la carte de preuve lisible par l'humain, puis inspectez le dossier de sécurité résolu ou exécutez npm run check:security-case.

AEB-1 : testez la frontière preuve-à-effet

Le pack ouvert de conformité d'admission de conséquence AEB-1 teste le dernier point de contrôle avant une action à conséquences : la vérification native, l'acceptation par la partie de confiance, la correspondance exacte CAID/action, la satisfaction des preuves, l'autorisation locale, la réservation atomique, la garde INVOKING, la vérité séparée du résultat du fournisseur et de l'effet observé, le comportement sans nouvelle tentative aveugle, et la réconciliation authentifiée.

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

Il est neutre en format et auto-exécutable. Un rapport réussi est une preuve de conformité auto-attestée — pas un audit, une certification, une affirmation de déploiement en production, ou une permission d'exécuter une action.

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

npm run proof:gate:reference

Cette commande exerce des exemples locaux et des frontières de service ciblées avec des clés générées, un état en mémoire et un comportement de fournisseur simulé. C'est une preuve locale utile, pas une preuve d'un humain réel, d'une banque externe, d'un déploiement en production ou d'une intégration de production de bout en bout.

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

L'identité dit qui ou quoi appelle. La politique dit ce qui est généralement autorisé. Ni l'une ni l'autre ne définit le travail fini qu'un travailleur autonome peut effectuer maintenant : sa mission, ses limites d'actions matérielles, son budget, ses preuves requises, son expiration, ses règles de délégation et son chemin d'exception.

EMILIA maintient ces questions séparées :

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 sous ce mandat ?

Les identifiants accordent l'accès. L'autorité définit le travail. Toutes les actions n'ont pas besoin d'un humain ; chaque action à conséquences a besoin d'une autorité valide.

À la base, EP Core expose toujours trois objets interopérables : un reçu de confiance porte une preuve attribuable, un profil de confiance représente un état de confiance structuré, et une décision de confiance enregistre le résultat évalué par la politique de la partie de confiance. Les couches du plan de contrôle d'autorité ajoutent la liaison d'action exacte, les mandats finis, l'admission, la consommation et la preuve de résultat sans fusionner ces objets en une seule revendication.

---

Définissez le mandat une fois. Laissez l'agent travailler.

Le client définit la mission, les limites, les exigences de preuve, l'expiration et les règles d'exception. Le code local peut rétrécir cette autorité ; il ne peut pas l'inventer ou l'élargir. Gate lie chaque requête exécutable au mandat, réserve l'autorité couverte avant l'entrée du fournisseur, autorise une seule tentative de fournisseur admise pour cette instance d'autorisation à l'intérieur du domaine d'autorité durable partagé, et escalade uniquement lorsque l'autorité est manquante, périmée, épuisée ou trop étroite.

Les exemples MCP fournis démontrent un profil de politique dans lequel une décision humaine fraîche est requise à la périphérie. Ils exécutent la boucle locale complète — preuve manquante refusée, action exacte signée, une tentative de fournisseur admise, preuve falsifiée rejetée — sans prétendre que chaque action autonome nécessite un clic humain :

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émo de composition plus approfondie exécute un paiement délégué lié au CAID à travers le chemin réel à capacité bornée de Gate, puis vérifie le certificat d'exécution signé hors ligne :

npm run demo:receipt-program

Elle n'inclut délibérément aucune blockchain ni revendication simulée de connaissance nulle. Voir l'architecture du programme de reçus pour l'état de production et les exigences de confiance.

Commencez par une exécution à sec contre votre surface d'outils déclarée, puis générez les fichiers d'intégration révisables :

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

La vérification locale générée utilise un état de démonstration explicitement éphémère et prouve seulement que son gestionnaire synthétique n'a pas été appelé. La production exige un registre de provenance durable, un magasin de consommation atomique partagé, des clés épinglées et le wrapper sur chaque chemin vers l'identifiant réel du fournisseur. Voir examples/mcp/ et /mcp.

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 vraie signature Face ID → Approuvez un virement de 82 000 $ avec votre propre passkey. Voyez ce que signifie VERIFIED. Falsifiez le reçu. Voyez-le échouer.

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

---

Comment ça fonctionne — un cycle de vie d'autorité

Exécutez-le vous-même : node examples/crash-test.mjs — entièrement hors ligne, aucune 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 le travail fini. Cela peut être un programme d'exploitation signé par le client, une capacité bornée, une décision humaine requise, un quorum ou une composition par la partie de confiance de preuves natives.

Travail exact. Gate lie la méthode, l'origine, l'appelé, la cible, l'occurrence et chaque champ matériel dans l'objet exécutable canonique. L'intention, une invite ou le texte d'un ticket n'est pas cet objet.

Vérifier, réserver et entrer. Les artefacts natifs restent natifs. La partie de confiance épingle les profils de confiance et de mappage, évalue l'exigence de preuve complète, prend la décision d'autorisation locale séparée, et réserve l'autorité couverte avant que l'adaptateur propriétaire d'identifiants n'entre chez le fournisseur.

Autorité humaine fraîche lorsque requise. Une politique peut exiger une décision WebAuthn/passkey liée à l'action exacte et au hachage d'affichage déterministe. Cela réduit l'écart « ce que vous avez vu est ce que vous avez signé » ; cela ne prouve pas la compréhension, la sagesse, la légalité ou le résultat.

Pour les déploiements d'entreprise, Gate peut en outre exiger une confirmation de serveur d'autorisation vérifiée indépendamment, liée à cette preuve humaine exacte, à la même action exacte, à l'instantané d'identité que l'AS a réellement observé, et à la clé de serveur de ressources prévue. Le temps d'instantané et l'âge maximal de la partie de confiance sont explicites : un jeton frais ne peut pas rendre des données d'annuaire périmées actuelles. La jambe AS est une preuve sous confiance épinglée par le client ; elle n'autorise jamais par elle-même, ne prouve pas un statut d'emploi instantané, ni ne transforme l'orchestrateur d'agents 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 séparées. Une réponse perdue devient INDETERMINATE, un état à réconcilier — pas une permission de réessayer. Un correctif 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. Le scanner propose une carte révisable ; le propriétaire définit le mandat ; Gate détient l'identifiant 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 n'accorde 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 borné, pas un identifiant permanent qu'il pourrait réinterpréter.

---

Pourquoi les entreprises en ont besoin

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

La Gate gérée et le plan d'assurance ajoutent des opérations de mandat, des intégrations, des opérations de preuve, la re-exécution, le support et des niveaux de service autour du protocole ouvert. Le client conserve le contrôle de l'autorité, des racines de confiance, des identifiants, des politiques et des preuves portables.

---

La norme

EMILIA Protocol est ouvert et sous licence Apache-2.0. Ses travaux de normalisation sont publiés sous forme de portefeuille de brouillons Internet individuels. Un brouillon Internet publié n'est pas une RFC, un élément adopté par un groupe de travail, ni une approbation de l'IETF ; Datatracker fait autorité pour la révision et le statut.

Surface de présentation canonique en quatre documents

Pour la navigation du lecteur, le chemin de preuve canonique est :

1. Authorization Receipts-11 définit le profil de preuve d'approbation lié à l'action. La révision actuellement publiée est la -11, déposée comme soumission individuelle candidate au Standards Track.
2. Human Authorization Binding-00 lie un artefact d'autorisation humaine nommée dans un enregistrement hôte adjacent.
3. Authority Introduction-03 établit des racines de confiance épinglées par la partie de confiance et une autorité à portée limitée.
4. Authorization Evidence Chain-05 évalue si des preuves vérifiées nativement et correspondant à l'action satisfont l'exigence de la partie de confiance ; elle renvoie SATISFIED ou UNSATISFIED, jamais AUTHORIZED.

Cette surface de quatre documents n'est que présentation. Elle ne fusionne, ne retire, ne remplace, ne met à jour, n'obsolète, ne subordonne ni ne rétrograde aucun brouillon du portefeuille actif.

Colonne vertébrale d'exécution séparée

Le chemin d'exécution est Architecture-02 → CAID-02 → AEC-05 → AEB-03 : frontières système, correspondance exacte d'action matérielle, satisfaction de preuve, puis admission côté exécuteur et garde durable des conséquences. AEC apparaît dans les deux vues parce que la satisfaction de preuve alimente l'admission d'exécution, pas parce que les vues sont équivalentes.

Le portefeuille actif complet reste de 23 enregistrements Datatracker : 20 enregistrements draft-schrock-* actifs et trois enregistrements co-écrits, chacun avec sa propre portée et son historique de révision. Voir le guide des normes, le portefeuille et l'inventaire de statut lisible par machine.

Brouillons Internet IETF	Instantanés locaux actuels : inventaire publié · statut en direct faisant autorité : IETF Datatracker
Vérificateurs multi-langues	JavaScript · Python · Go — les trois prouvent leur accord sur des vecteurs de conformité adverses, à chaque push (npm run conformance). Un contrôle de cohérence entre les ports d'une même équipe, pas des implémentations indépendantes en environnement maîtrisé. Séparément, une implémentation Rust écrite en externe à partir de la spécification (source publique) passe le lot épinglé de 16 suites/164 vecteurs et la campagne d'hostilité épinglée de 359 cas sous une reconstruction contrôlée par l'évaluateur à partir d'un arbre source immuable. Sa preuve de construction vérifiée reste signée par l'implémentateur, non attestée par un tiers (déclaration signée) ; l'acceptation stricte en environnement maîtrisé attend le manifeste corrigé attesté par un tiers et la clé d'attestation épinglée indépendamment.
Preuve de modèle formel	26 propriétés de sûreté TLA+ bornées maintenues dans leurs espaces d'états configurés ; ce n'est pas un raffinement d'implémentation ni une preuve non bornée · 35 faits Alloy, 32 assertions sur quatre modèles · deux modèles symboliques composés Dolev-Yao couvrant le challenge, le CAID, deux approbations, les épingles d'émetteur et d'autorité, la vue de registre, la révocation, la consommation, l'exécution et six frontières de revendication dédiées. Vingt lemmes Tamarin vérifient — 17 obligations sur toutes les traces et 3 témoins existants sur des traces ; huit variantes délibérément affaiblies produisent des traces d'attaque concrètes lorsque les contrôles porteurs sont supprimés (formal/tamarin/).
Registres MCP	Registre MCP officiel · Glama (Grade A, badge Officiel) · Smithery
Licence	Apache-2.0

Trois ports de référence de la même équipe (JS / Python / Go) s'accordent sur les 21 suites et 331 vecteurs. Séparément, une implémentation Rust écrite en externe, reconstruite à partir d'un arbre source public épinglé, passe le lot en environnement maîtrisé épinglé de 16 suites/164 vecteurs et une campagne d'hostilité de 359 cas, relancée dans sa propre voie CI à chaque changement. Les suites plus récentes d'acceptation AEC et de résolution à quatre issues ne sont pas attribuées à Rust. C'est une preuve d'interopérabilité externe, pas une acceptation stricte de construction en environnement maîtrisé ; l'agrégat CI enregistre le nombre d'acceptations strictes à zéro en attendant une attestation indépendante. Voir CONFORMANCE.md, ou vérifiez vous-même un reçu sur emiliaprotocol.ai/verify.

---

La pile d'autorité

Couche	Ce qu'elle fait
Mandat	Définit la mission, les limites, les preuves, l'expiration, la délégation et les règles d'exception.
CAID / action exacte	Fige l'objet exécutable matériel pour que la preuve ne puisse pas se déplacer vers un autre travail.
AEC	Évalue si des preuves vérifiées indépendamment et correspondantes satisfont l'exigence de la partie de confiance ; elle n'autorise pas.
AEB / Gate	Prend la décision d'autorisation locale, réserve l'autorité couverte et contrôle l'entrée du fournisseur.
Preuve de résultat	Maintient distincts l'invocation, la réponse du fournisseur, l'effet observé et l'incertitude.

---

Points de preuve

Métrique	Valeur
Cas de test automatisés	8 865 sur 533 fichiers ; tous les cas applicables à la plateforme doivent passer
Propriétés de sûreté TLA+	26 invariants bornés maintenus dans l'espace d'états configuré ; pas une preuve de raffinement d'implémentation ni non bornée — voir PROOF_STATUS.md
Assertions relationnelles Alloy	35 faits + 32 assertions sur quatre modèles — vérifiés en CI
Cas d'équipe rouge catalogués	85 — RED_TEAM_CASES.md
Statut de sécurité des versions	Les vérifications de sécurité du dépôt passent ; chaque constat Strix sur les changements audités est corrigé avec une couverture de régression et son fil de revue résolu
Conformité (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Conformité inter-langues	331 vecteurs · 21 suites : reçus · signatures d'appareil · résolution à quatre issues · quorum multi-parties · révocation · liaison de résultat (sémantique + crypto réelle) · jointure d'émetteur de document/preuve d'autorité · attestation de temps · reçu de confiance (2 profils) · provenance · enregistrement de preuve · canonisation · frontière · acceptation AEC · devise · attestation d'initiateur · preuve de consommation · témoin · preuve d'horodatage (RFC 3161). Les vérificateurs JS / Python / Go s'accordent (node conformance/run.mjs). La base Rust externe reste à 164 vecteurs / 16 suites. Voir CONFORMANCE.md.
p95 de création de liaison	575 ms à 50 VU — PERFORMANCE_PROOF.md

---

Objets de protocole centraux

Objet	Ce que c'est
Programme d'autorité / capacité bornée	Un mandat fini avec une portée explicite, un budget ou des unités, une expiration, une délégation et des règles de consommation.
CAID	Un identifiant canonique pour une action matérielle sous un profil de mappage nommé ; la correspondance n'est pas une autorisation.
Exigence de preuve et résultat AEC	La règle épinglée de la partie de confiance et son évaluation SATISFIED, UNSATISFIED ou INDETERMINATE.
Enregistrement d'admission et de garde AEB	L'enregistrement côté exécuteur de l'autorisation, de la réservation, de l'entrée du fournisseur et de l'état de réconciliation.
Autorisation et preuve de résultat	Artefacts portables natifs ou EP qui conservent leur émetteur, leur portée et leur frontière de revendication exacts.

---

Démarrage rapide

1. Exécutez npx @emilia-protocol/scan protect ./tools.json pour cartographier les surfaces déclarées prises en charge.
2. Examinez le manifeste d'action généré, les champs matériels, les identifiants et les angles morts nommés.
3. Installez Gate sur le chemin qui possède l'identifiant du fournisseur et l'état de consommation durable.
4. Définissez le mandat d'exploitation et les éventuelles règles d'exception humaines fraîches ou de quorum.
5. Exécutez les cas de refus, d'action exacte, de rejeu, de délai d'attente et de réconciliation avant d'activer l'application.

Démo de 90 secondes · Démarrage rapide · Parcours agent · Brouillon IETF · Discord

---

Ce qu'EP est — et n'est pas

EMILIA est une infrastructure d'autorité pour le travail autonome, pas un système d'identité, un portefeuille, un score de réputation, une voie de règlement ni un moteur de politique universel.

• Est : un plan de contrôle pour des mandats d'exploitation finis, la vérification d'action exacte, un état d'admission durable, une incertitude véridique et des preuves portables sur les chemins d'exécuteur couverts.
• N'est pas : un remplacement d'OAuth/OIDC, de l'identité de charge de travail ou des moteurs de politique. Ceux-ci restent des entrées natives sous les épingles de la partie de confiance.
• N'est pas : une exigence qu'un humain approuve chaque action. Un mandat peut permettre un travail automatique dans des limites finies et n'exiger une autorité fraîche qu'à la frontière.
• N'est pas : une preuve qu'une action admise a été exécutée avec succès ou a causé l'effet voulu.
• N'est pas : un contrôle de protocole propriétaire. Le cœur est sous licence Apache-2.0 et les brouillons Internet 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é