EMILIA Protocol

EMILIA Protocol

---

Laissez votre agent préparer le paiement. Contrôlez ce qu'il peut libérer.

Un agent prépare un paiement fournisseur de 82 000 $. Quelqu'un l'approuve. Ensuite, le montant ou la destination bancaire change. L'approbation antérieure ne doit pas libérer le paiement modifié.

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

Exécutez l'exemple de paiement

Avec Node.js 20.19 ou plus récent et npm installé :

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, admet l'appel correspondant une seule fois, et refuse les détails de paiement modifiés, la relecture et les preuves falsifiées. Voir l'exemple et ses limites.

Ceci est une démonstration locale : clés de signature générées, consommation en mémoire et outil de paiement simulé. Elle n'effectue pas une véritable cérémonie humaine ni ne déplace de l'argent. La production nécessite des identifiants enregistrés, un état partagé durable et Gate sur chaque chemin vers l'identifiant du fournisseur protégé. Une approbation valide n'établit 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émo séparée montre l'intégrité du reçu avec votre authentificateur de plateforme ; aucun paiement n'est envoyé.

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

Commencez par le service qui détient le véritable identifiant du fournisseur, pas seulement à l'intérieur du processus de l'agent. Le propriétaire définit le travail autorisé et le moment 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 vous guide à travers une action couverte.
• Hugging Face smolagents : enveloppez un outil existant.
• GitHub : Merge Gate lie une vérification à la fusion proposée. La vérification doit être requise et les chemins de fusion alternatifs fermés.

Le protocole prouve. Gate empêche sur les chemins que le déploiement médiatise complètement. 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 plutôt que de réessayer aveuglément.

Systèmes d'IA et réviseurs de dépôt : commencez par AI_CONTEXT.md. Les preuves actuelles lisibles par machine, la provenance, les hypothèses et les exclusions sont publiées à EMILIA-REPO-CONTEXT-v1. Les documents archivés ou provisoires n'établissent pas l'implémentation actuelle ni le statut IETF. 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 264 fichiers de preuves hachés, vérifie 20 lemmes Tamarin sur deux modèles Dolev-Yao composés — 17 obligations toutes-traces et 3 témoins de reachability existe-trace — et préserve 8 variantes délibérément 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 340 vecteurs actuels. Séparément, un vérificateur Rust écrit en externe est épinglé au bundle 16-suites/164-vecteurs gelé et à une campagne d'hostilité de 359 cas. La suite plus large contient plus de 10 700 tests automatisés sur plus de 650 fichiers.

Les surfaces JavaScript et JSDoc de production sont vérifiées par 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. Il s'agit d'une couverture complète de vérification de type de production configurée, pas d'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 des preuves. Commencez par la carte des preuves 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

La conformité d'admission de conséquence AEB-1 ouverte pack de tests teste le chemin CAID/AEC composé au dernier point de contrôle avant une action consécutive : vérification native, acceptation par la partie de confiance, liaison exacte de l'action, correspondance CAID requise, satisfaction des preuves AEC requises, autorisation locale, réservation atomique, garde INVOKING, vérité séparée du résultat du fournisseur et de l'effet observé, comportement sans réessai aveugle, et réconciliation authentifiée.

Lisez la frontière d'admission de conséquence pour la division exacte des responsabilités sur le chemin CAID/AEC composé, le chemin natif direct, la garde AEB et les preuves de résultat du fournisseur.

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 revendication de déploiement en production, ou une permission d'exécuter une action.

Sous AEB-07, publié le 2026-09-25 en tant qu'Internet-Draft individuel et non adopté par aucun groupe de travail, CAID est utilisé uniquement lorsque des actions encodées indépendamment doivent être jointes, et AEC est utilisé uniquement lorsque la politique locale exige plusieurs branches de preuves. Un corpus synthétique séparé de 26 cas modélise ce cycle de vie natif direct sur les résultats d'adaptateurs AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token et mandat signé local :

npm run conformance:composition:consequence-admission

L'exécuteur du corpus est un modèle de cycle de vie autonome avec son propre stockage en mémoire et sa logique d'admission. Il n'exécute pas le code @emilia-protocol/verify ou @emilia-protocol/gate livré, donc il ne constitue pas une preuve pour ces paquets, qui ont leurs propres suites de tests. Il ne constitue pas non plus une preuve que les protocoles natifs nommés se conforment à 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 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 de 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, les preuves requises, l'expiration, les règles de délégation et le chemin d'exception.

EMILIA garde 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écutive a besoin d'une autorité valide.

À la base, EP Core expose toujours trois objets interopérables : un Trust Receipt transporte des preuves attribuables, un Trust Profile représente un état de confiance structuré, et un Trust Decision enregistre le résultat évalué par la politique de la partie de confiance. Les couches du plan de contrôle d'autorité ajoutent une liaison exacte de l'action, des mandats finis, l'admission, la consommation et les preuves de résultat sans réduire ces objets à une seule revendication.

---

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

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

Les exemples MCP fournis exercent un profil de politique exigeant une approbation à la frontière. Ils génèrent des clés de signature de démonstration et invoquent des outils simulés. L'exemple de paiement lie les quatre champs matériels déclarés ; les autres exemples démontrent des liaisons de ressources plus étroites. Ils ne capturent pas une décision humaine réelle ni ne contactent un 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émo de composition plus profonde exécute un paiement délégué lié CAID à travers le chemin de capacité bornée réel 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 de connaissance zéro simulée. Voir l'architecture du programme de reçus pour les exigences d'état de production et de confiance.

Commencez par une action MCP consécutive déclarée. Installez le runtime local exact, puis créez son Gate Starter et exécutez la vérification bornée en quatre cas :

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

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.5.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 déclarés de manque, de correspondance exacte, de mutation, de relecture et d'outil non scanné. La commande examinée crée un transfert à confidentialité bornée ; elle n'active pas Gate. La production nécessite un registre de provenance durable, un magasin de consommation atomique partagé, des clés épinglées et l'enveloppe sur chaque chemin vers l'identifiant réel du fournisseur. Voir examples/mcp/ et /mcp.

Arrêtez de nouvelles actions sans prétendre défaire les anciennes

Le gel d'autorité d'urgence de Gate bloque les nouvelles réservations et empêche les anciennes réservations d'entrer après le changement d'époque du domaine de contrôle couvert. Si l'entrée du fournisseur a eu lieu en premier, la tentative reste consommée et nécessite une réconciliation. Restaurer l'autorité ne ravive pas une ancienne réservation.

Cela nécessite une médiation complète et un état partagé faisant autorité. Cela ne stoppe pas le calcul, n'inverse pas un effet, ni n'atteint instantanément des domaines déconnectés. Voir l'implémentation du domaine de contrôle et ses limites.

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 voyez la vérification d'intégrité échouer. Votre authentificateur peut utiliser la biométrie ou un code PIN d'appareil. La page offre également une simulation logicielle séparée. Aucun mode n'envoie un 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échargé.

---

Comment cela fonctionne — un cycle de vie d'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 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 de 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 un texte de 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 complète de preuves, prend la décision d'autorisation locale séparée, et réserve l'autorité couverte avant que l'adaptateur détenant l'identifiant n'entre dans 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 indépendamment vérifiée du serveur d'autorisation, 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é du serveur de ressources prévu. L'heure de l'instantané et l'âge maximal de la partie de confiance sont explicites : un jeton frais ne peut pas rendre des données d'annuaire obsolètes actuelles. La branche AS est une preuve sous la confiance épinglée par le client ; elle n'autorise jamais par elle-même, ne prouve pas une situation d'emploi instantanée, 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, qui est un état à réconcilier—pas une permission de réessayer. Un remède 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 le wrapper SDK léger. Le scanner propose une carte révisable ; le propriétaire définit le mandat ; Gate possède la référence du fournisseur et applique l'action exacte sur le chemin couvert. Aucune analyse 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 limité, pas une référence permanente qu'il peut réinterpréter.

---

Pourquoi les entreprises en ont besoin

Les processus d'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 maintient cet état d'autorité durable à la frontière du client tout en acceptant des preuves étrangères via des adaptateurs épinglés.

Le Gate géré et le plan d'assurance ajoutent des opérations de mandat, des intégrations, des opérations de preuve, la re-performance, 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 références, de la politique et des preuves portables.

---

La norme

EMILIA Protocol est ouvert et sous licence Apache-2.0. Son travail de normalisation est publié comme un portefeuille de projets individuels Internet-Drafts. Un Internet-Draft publié n'est pas un RFC, un élément adopté par un groupe de travail, ni une approbation de l'IETF ; Datatracker est faisant autorité pour la révision et le statut.

Une surface de limite de conséquence

Le AEB-07 actuellement publié, posté le 2026-09-25 comme Internet-Draft individuel et non adopté, fait de l'AEB le point de composition après une décision native. OAuth, AuthZEN, COAZ, AP2 et les systèmes locaux conservent la propriété de leurs références, de leurs mappages 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 profile des normes existantes telles que WIMSE et OAuth ; il n'émet pas lui-même de références ou de décisions. L'AEB applique la décision native à la frontière du fournisseur protégé : il lie l'action finale lorsque nécessaire, dérive une identité de rejeu native par subvention, réserve avant l'entrée du fournisseur, refuse une seconde tentative de la même action pendant qu'une précédente est en vol ou incertaine, et maintient un résultat incertain verrouillé jusqu'à la réconciliation authentifiée.

CAID-04 est utilisé lorsque des représentations encodées indépendamment doivent être comparées. Ce n'est pas un second mappage obligatoire lorsque le PEP propriétaire de la conséquence dérive déjà et applique une décision actuelle sur l'opération finale. AEC-06 est utilisé lorsque la partie de confiance exige plusieurs branches de preuve. Les reçus d'autorisation, la liaison d'autorisation humaine et l'introduction d'autorité restent des profils 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 navigation.

Le guide d'admission des conséquences énonce la limite d'implémentation et les cas où l'AEB est inutile. Le profil de transfert natif direct est un profil d'implémentation de dépôt qui montre comment un permis existant atteint Gate sans une seconde couche CAID ou AEC. 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 épingles de déploiement ; il cite un instantané épinglé de ce profil comme une référence informative d'encodage. Les octets exacts soumis -07 et leur enregistrement de publication sont conservés dans standards/staged/NEXT-AEB-07.

Le portefeuille actif complet est de 26 enregistrements Datatracker : 21 enregistrements en auteur unique et cinq enregistrements en co-auteur, chacun avec sa propre portée, son historique de révision et son statut de maintenance enregistré. Voir le guide des normes, le portefeuille, et l'inventaire de statut lisible par machine.

Internet-Drafts IETF	Chemins d'instantanés locaux actuels : inventaire de statut · inventaire publié en auteur unique · statut en direct faisant autorité : IETF Datatracker
Vérificateurs multi-langues	JavaScript · Python · Go — les trois prouvés d'accord sur des vecteurs de conformité adverses, à chaque push (npm run conformance). Une vérification de cohérence entre les ports d'une même équipe, pas des implémentations indépendantes en chambre blanche. Séparément, une implémentation Rust écrite en externe à partir de la spécification (source publique) passe le bundle é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. Ses preuves de construction vérifiées restent signées par l'implémenteur, non attestées par un tiers (déclaration signée) ; l'acceptation stricte en chambre blanche attend le manifeste corrigé attesté par un tiers et la clé d'attestation épinglée indépendamment.
Preuves de modèle formel	26 propriétés de sécurité 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 composés symboliques Dolev-Yao couvrant le défi, CAID, deux approbations, les épingles d'émetteur et d'autorité, la vue de registre, la révocation, la consommation, l'exécution et six limites de revendications dédiées. Vingt lemmes Tamarin vérifient — 17 obligations de toutes traces et 3 témoins de traces existantes ; huit variantes délibérément affaiblies produisent des traces d'attaque concrètes lorsque les vérifications porteuses sont supprimées (formal/tamarin/).
Distribution MCP	Paquet npm @emilia-protocol/mcp-server · la publication officielle du registre est suivie séparément dans MCP-REGISTRY.md ; les listes d'agrégateurs ne sont pas déduites de l'un ou l'autre état
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 340 vecteurs. Séparément, une implémentation Rust écrite en externe reconstruite à partir d'un arbre source public épinglé passe le bundle de chambre blanche épinglé de 16 suites/164 vecteurs et une campagne d'hostilité de 359 cas, ré-exécutée dans sa propre voie CI à chaque changement. Les suites plus récentes d'acceptation AEC et de résolution à quatre résultats ne sont pas attribuées à Rust. C'est une preuve d'interopérabilité externe, pas une acceptation stricte de construction en chambre blanche ; l'enregistrement CI agrégé compte l'acceptation stricte comme zéro en attendant une attestation indépendante. Voir CONFORMANCE.md, ou vérifiez un reçu vous-même à 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	Compare la signification matérielle lorsque l'autorisation et l'exécution utilisent des représentations encodées indépendamment ; il n'autorise pas.
AEC	Lorsque requis, évalue si des preuves vérifiées indépendamment et appariées satisfont l'exigence multi-branches de la partie de confiance ; il n'autorise pas.
AEB / Gate	Applique la décision d'autorisation native ou locale à la limite de conséquence, réserve l'autorité couverte et contrôle l'entrée du fournisseur.
Preuve de résultat	Maintient l'invocation, la réponse du fournisseur, l'effet observé et l'incertitude distincts.

---

Points de preuve

Métrique	Valeur
Cas de test automatisés	10 700+ sur 650+ fichiers ; tous les cas applicables à la plateforme doivent passer
Propriétés de sécurité TLA+	26 invariants bornés maintenus dans l'espace d'états configuré ; pas une preuve de raffinement d'implémentation ou 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	86 — 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é multi-langues	340 vecteurs · 21 suites : reçus · signatures d'appareils · résolution à quatre résultats · quorum multi-parties · révocation · liaison de résultat (sémantique + crypto réelle) · jointure émetteur/preuve de document d'autorité · attestation de temps · reçu de confiance (x2 profils) · provenance · enregistrement de preuve · canonicalisation · limite · 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 de référence Rust externe reste à 164 vecteurs / 16 suites. Voir CONFORMANCE.md.
Poignée de main créer p95	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 sous lesquels elles ont été signées. EP fournit quatre capacités bornées pour cela, chacune avec une limite exacte qui fait partie de la revendication :

• Signatures hybrides (EP-RECEIPT-HYBRID-v1). Ed25519 et ML-DSA-65 sur les mêmes octets canoniques, avec l'ensemble d'algorithmes requis engagé dans les octets signés afin que le retrait d'une branche casse la signature survivante. La capacité est opt-in au déploiement ; une fois qu'un signataire double approuvé est enregistré et que la politique permet sa branche PQ, une posture Gate non épinglée se résout en émission double par défaut. Sinon, elle reste classique uniquement avec une raison nommée. Les vérificateurs v1 refusent proprement les reçus hybrides plutôt que d'accepter une branche. Le contrat de signataire externe et l'adaptateur AWS KMS sont implémentés, mais aucun appel de signature AWS en direct, clé de production, vérification de partie de confiance ou validation FIPS ML-DSA n'est revendiqué. Voir conformance/hybrid-receipts/ et lib/pq-custody-aws-kms.ts.
• Profil de déclaration signée SCITT (EP-SCITT-STATEMENT-v1). Une forme complète de déclaration signée RFC 9943 pour les reçus EP, y compris l'en-tête protégé CWT Claims. Limite : aucun service de transparence n'a accepté une déclaration EP ; l'enregistrement externe est une étape séparée et verrouillée et aucune n'a été effectuée. Voir EP-RECEIPT-SCITT-PROFILE.md.
• Ré-attestation (EP-EVIDENCE-REATTESTATION-v1). Les preuves signées sous un algorithme vieillissant peuvent être ré-ancrées sous un algorithme actuel avant que l'ancien ne s'affaiblisse. Limite : la ré-attestation doit précéder le compromis ; 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 via un fournisseur validé FIPS 140-3 fourni par l'opérateur, avec le chemin ML-DSA verrouillé derrière un accusé de réception explicite d'implémentation non validée. Limite : cela vaut "algorithmes basés sur FIPS, avec un mode de déploiement de fournisseur validé" et dépend du fournisseur de l'opérateur et de la limite de certificat déclarée ; ce n'est pas une revendication de conformité générale, et rien ici n'est validé FIPS. Voir FIPS-MODE.md.

Le programme hybride à l'échelle de la pile (chaque surface de signature interne) est mappé dans pq-hybrid-program.md et n'est pas complet ; jusqu'à ce qu'il le soit, aucune revendication générale sur l'ensemble de la pile n'est faite.

---

Objets de protocole de base

Objet	Ce que c'est
Programme d'autorité / capacité bornée	Un mandat fini avec un périmètre 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 par la partie de confiance 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 du fournisseur et de l'état de rapprochement.
Autorisation et preuve de résultat	Artefacts natifs ou EP portables qui conservent leur émetteur, leur périmètre et leur limite de revendication exacts.

---

Démarrage rapide

1. Installez l'environnement d'exécution de garde local exact, puis exécutez npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify, en remplaçant sendWire par un outil consécutif déclaré exact.
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 séparée --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 possède l'identifiant du fournisseur et l'état de consommation durable.
5. Définissez le mandat d'exploitation et toute règle d'exception humaine fraîche ou de 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.

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

---

Ce qu'est EP — et ce qu'il 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, un rail de règlement ou un moteur de politique universel.

• Est : un plan de contrôle pour des mandats d'exploitation finis, une 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 pour OAuth/OIDC, l'identité de charge de travail ou les 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 exiger une autorité fraîche uniquement à la limite.
• N'est pas : une preuve qu'une action admise a été exécutée avec succès ou a provoqué l'effet prévu.
• N'est pas : un contrôle de protocole propriétaire. Le cœur est sous licence Apache-2.0 et les Internet-Drafts sont des soumissions individuelles, pas des RFC ou une approbation de l'IETF.

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