EMILIA Protocol

EMILIA Protocol

---

Lassen Sie Ihren Agenten die Zahlung vorbereiten. Kontrollieren Sie, was er freigeben kann.

Ein Agent bereitet eine Lieferantenzahlung über 82.000 $ vor. Jemand genehmigt sie. Dann ändern sich der Betrag oder das Bankziel. Die frühere Genehmigung darf die geänderte Zahlung nicht freigeben.

EMILIA Gate prüft die Berechtigung, bevor ein geschütztes Tool ausgeführt wird. Das offene Protokoll macht die daraus entstehenden Nachweise anhand der eigenen vertrauenswürdigen Schlüssel und Regeln des Verifizierers unabhängig überprüfbar. Behalten Sie Ihren bestehenden Identitätsanbieter, Ihr Agent-Framework und Ihre Geschäftssysteme bei.

Zahlungsbeispiel ausführen

Mit Node.js 20.19 oder neuer und installiertem npm:

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

Das Beispiel verweigert einen Aufruf ohne Genehmigung, bindet die Genehmigung an Betrag, Währung, Anbieter und Ziel, lässt den passenden Aufruf einmalig zu und verweigert geänderte Zahlungsdetails, Wiederholungen und gefälschte Nachweise. Siehe Beispiel und seine Grenzen.

Dies ist eine lokale Demonstration: generierte Signaturschlüssel, Verbrauch im Arbeitsspeicher und ein simuliertes Zahlungstool. Sie führt keine echte menschliche Zeremonie durch und bewegt kein Geld. Für den Produktionseinsatz sind registrierte Anmeldedaten, dauerhafter gemeinsamer Zustand und Gate auf jedem Pfad zur geschützten Anbieteranmeldung erforderlich. Eine gültige Genehmigung belegt nicht, dass die Bankdaten legitim sind.

Lieber einen Browser? Passkey für eine Beispielzahlung ausprobieren. Diese separate Demo zeigt die Integrität eines Belegs mit Ihrem Plattform-Authenticator; es wird keine Zahlung gesendet.

Ein Tool schützen, das Sie bereits verwenden

Beginnen Sie beim Dienst, der die echte Anbieteranmeldung verwahrt, nicht nur innerhalb des Agentenprozesses. Der Verantwortliche legt die zulässigen Arbeiten fest und bestimmt, wann eine neue Genehmigung erforderlich ist. Ein Agent kann innerhalb dieser Grenzen arbeiten, ohne dass eine Person jeden Aufruf genehmigen muss.

• MCP oder HTTP: Gate Starter führt durch eine geschützte Aktion.
• Hugging Face smolagents: ein vorhandenes Tool umschließen.
• GitHub: Merge Gate bindet eine Prüfung an den vorgeschlagenen Merge. Die Prüfung muss verpflichtend sein und alternative Merge-Pfade müssen geschlossen werden.

Das Protokoll beweist. Gate verhindert auf den Pfaden, die die Bereitstellung vollständig vermittelt. Gate kann keinen Umgehungspfad einschränken. Ist das Ergebnis eines Anbieters unbekannt, bewahrt der Produktionslebenszyklus diese Ungewissheit zur Abstimmung, statt blind erneut zu versuchen.

KI-Systeme und Repository-Prüfer: Beginnen Sie mit AI_CONTEXT.md. Aktuelle maschinenlesbare Nachweise, Herkunftsinformationen, Annahmen und Ausschlüsse sind unter EMILIA-REPO-CONTEXT-v1 veröffentlicht. Archivierte oder vorbereitete Dokumente belegen weder die aktuelle Implementierung noch den IETF-Status. Öffentliche Due-Diligence-Nachweise und Grenzen der Aussagen: DUE_DILIGENCE.md.

Technische Nachweise statt Architekturbehauptungen

EMILIA liefert einen Sicherheitsnachweis, den Prüfer ausführen können. Das aktuelle Repository löst 35 Sicherheitsbehauptungen anhand von 264 gehashten Nachweisdateien auf, verifiziert 20 Tamarin-Lemmas über zwei zusammengesetzte Dolev-Yao-Modelle hinweg — 17 Verpflichtungen für alle Ausführungsverläufe und 3 Erreichbarkeitszeugen für existierende Ausführungsverläufe — und bewahrt 8 absichtlich abgeschwächte Varianten, die konkrete Angriffsspuren erzeugen, wenn tragende Prüfungen entfernt werden. Der aktuelle Konformitätskorpus desselben Teams umfasst 21 Suites und 340 aktuelle Vektoren. Separat ist ein extern erstellter Rust-Verifizierer an das eingefrorene Paket mit 16 Suites/164 Vektoren und eine 359 Fälle umfassende Angriffskampagne gebunden. Die umfassendere Suite enthält mehr als 10.700 automatisierte Tests in über 650 Dateien.

Produktions-JavaScript-Oberflächen und JSDoc-Oberflächen werden mit TypeScript compilergeprüft checkJs; die sichere App verfügt über ein eigenes Kompatibilitäts-Compilerprojekt, während Deklarationen und das öffentliche TypeScript-SDK im strikten Modus geprüft werden. Dies ist eine vollständige Typprüfabdeckung der konfigurierten Produktionsoberflächen. Es ist keine Behauptung, dass das Repository vollständig von JavaScript zu TypeScript konvertiert wurde oder dass für jedes JavaScript-Projekt die TypeScript-Option strict aktiviert ist.

Jede Sicherheitsbehauptung benennt den Durchsetzungspfad, positive und negative Vektoren, Sprachabdeckung, formalen Geltungsbereich oder eine explizite Lücke, Annahmen, Ausschlüsse und den Nachweis-Hash. Beginnen Sie mit der menschenlesbaren Nachweisübersicht, und prüfen Sie anschließend den aufgelösten Sicherheitsnachweis oder führen Sie npm run check:security-case aus.

AEB-1: die Grenze zwischen Nachweis und Wirkung testen

Das offene Paket AEB-1 Consequence Admission Conformance testet den zusammengesetzten CAID/AEC-Pfad am letzten Kontrollpunkt vor einer folgenreichen Aktion: native Verifizierung, Annahme durch die vertrauende Partei, Bindung an die exakte Aktion, erforderlicher CAID-Abgleich, Erfüllung der erforderlichen AEC-Nachweise, lokale Autorisierung, atomare Reservierung, Verwahrung durch INVOKING, getrennte Wahrheitswerte für Anbieterergebnis und beobachtete Wirkung, Verhalten ohne blinde Wiederholungsversuche und authentifizierte Abstimmung.

Lesen Sie die Grenze der Zulassung folgenreicher Aktionen, um die genaue Aufgabenteilung zwischen dem zusammengesetzten CAID/AEC-Pfad, dem direkten nativen Pfad, der AEB-Verwahrung und den Nachweisen zum Anbieterergebnis zu verstehen.

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

Das Paket ist formatneutral und kann eigenständig ausgeführt werden. Ein bestandener Bericht ist selbst attestierter Konformitätsnachweis, kein Audit, keine Zertifizierung, keine Behauptung einer Produktionsbereitstellung und keine Erlaubnis, eine Aktion auszuführen.

Gemäß AEB-07, veröffentlicht am 2026-09-25 als individueller Internet-Draft und von keiner Arbeitsgruppe übernommen, wird CAID nur verwendet, wenn unabhängig kodierte Aktionen verknüpft werden müssen, und AEC nur, wenn lokale Richtlinien mehrere Nachweisbestandteile erfordern. Ein separater synthetischer Korpus mit 26 Fällen modelliert diesen direkten nativen Lebenszyklus über AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token und Ergebnisse lokaler Adapter für signierte Mandate:

npm run conformance:composition:consequence-admission

Der Korpus-Runner ist ein eigenständiges Lebenszyklusmodell mit eigenem In-Memory-Speicher und eigener Zulassungslogik. Er führt weder den ausgelieferten Code @emilia-protocol/verify noch @emilia-protocol/gate aus und ist daher kein Nachweis für diese Pakete, die über eigene Testsuiten verfügen. Er belegt außerdem nicht, dass die genannten nativen Protokolle AEB-07 entsprechen.

Für einen gezielten ausführbaren Nachweis des Gate-Pfads im Repository führen Sie Folgendes aus:

npm run proof:gate:reference

Dieser Befehl führt lokale Beispiele und gezielte Dienstgrenzen mit generierten Schlüsseln, In-Memory-Zustand und simuliertem Anbieterverhalten aus. Er ist ein nützlicher lokaler Nachweis, aber kein Nachweis für einen echten Menschen, eine externe Bank, eine Produktionsbereitstellung oder eine durchgängige Produktionsintegration.

Identität ist keine Aufgabenbeschreibung

Identität sagt aus, wer oder was aufruft. Richtlinien legen fest, was allgemein zulässig ist. Keines von beiden definiert die begrenzte Aufgabe, die ein autonomer Worker jetzt ausführen darf: seinen Auftrag, die Grenzen folgenreicher Aktionen, das Budget, erforderliche Nachweise, den Ablaufzeitpunkt, Delegierungsregeln und den Ausnahmeweg.

EMILIA hält diese Fragen getrennt:

Ebene	Frage
Identität	Wer oder was ist vorhanden?
Richtlinie	Was ist allgemein zulässig?
Berechtigung	Welche konkrete Arbeit darf dieser Agent im Rahmen dieses Mandats ausführen?

Anmeldedaten gewähren Zugriff. Berechtigungen definieren die Aufgabe. Nicht jede Aktion erfordert einen Menschen; jede folgenreiche Aktion erfordert eine gültige Berechtigung.

Auf der Grundlage stellt EP Core weiterhin drei interoperable Objekte bereit: Ein Trust Receipt enthält zuordenbare Nachweise, ein Trust Profile bildet einen strukturierten Vertrauenszustand ab und eine Trust Decision hält das von der vertrauenden Partei richtlinienbasiert ausgewertete Ergebnis fest. Die Ebenen der Berechtigungssteuerung ergänzen die exakte Aktionsbindung, begrenzte Mandate, Zulassung, Verbrauch und Ergebnisnachweise, ohne diese Objekte zu einem einzigen Anspruch zusammenzufassen.

---

Mandat einmal festlegen. Den Agenten arbeiten lassen.

Der Kunde definiert den Auftrag, die Grenzen, die Nachweisanforderungen, den Ablaufzeitpunkt und die Ausnahmeregeln. Lokaler Code darf diese Berechtigung einschränken, aber nicht erfinden oder erweitern. Gate bindet jede ausführbare Anfrage an das Mandat, reserviert die abgedeckte Berechtigung vor dem Eintritt beim Anbieter, erlaubt einen einzigen zugelassenen Anbieterversuch für diese Autorisierungsinstanz innerhalb der gemeinsamen dauerhaften Berechtigungsdomäne und eskaliert nur, wenn die Berechtigung fehlt, veraltet, ausgeschöpft oder zu eng gefasst ist.

Die gebündelten MCP-Beispiele führen ein Richtlinienprofil aus, das eine Genehmigung an der Kontrollgrenze verlangt. Sie generieren Demonstrations-Signaturschlüssel und rufen simulierte Tools auf. Das Zahlungsbeispiel bindet alle vier deklarierten wesentlichen Felder; die anderen Beispiele zeigen engere Ressourcenbindungen. Sie erfassen keine echte menschliche Entscheidung und kontaktieren keinen Anbieter:

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

Die ausführlichere Kompositionsdemo führt eine CAID-gebundene delegierte Zahlung über Gates echten Pfad für begrenzte Berechtigungen aus und verifiziert anschließend das signierte Ausführungszertifikat offline:

npm run demo:receipt-program

Sie enthält absichtlich weder Blockchain noch simulierte Zero-Knowledge-Behauptungen. Siehe die Architektur des Receipt-Programms für die Anforderungen an Produktionszustand und Vertrauen.

Beginnen Sie mit einer deklarierten folgenreichen MCP-Aktion. Installieren Sie die exakte lokale Laufzeit, erstellen Sie dann den Gate Starter und führen Sie die begrenzte Prüfung mit vier Fällen aus:

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

Die generierte lokale Prüfung verwendet ausdrücklich flüchtigen Demo-Zustand und belegt nur die angegebenen synthetischen Fälle: fehlend, exakte Übereinstimmung, Änderung, Wiederholung und nicht gescanntes Tool. Der geprüfte Befehl erstellt eine datenschutzbegrenzte Übergabe; er aktiviert Gate nicht. Für den Produktionseinsatz sind ein dauerhaftes Herkunftsregister, ein gemeinsamer atomarer Verbrauchsspeicher, festgelegte Schlüssel und der Wrapper auf jedem Pfad zur echten Anbieteranmeldung erforderlich. Siehe examples/mcp/ und /mcp.

Neue Aktionen stoppen, ohne vorzugeben, alte rückgängig zu machen

Gates Notfall-Berechtigungssperre blockiert neue Reservierungen und verhindert, dass ältere Reservierungen nach einer Änderung der Epoche der abgedeckten Kontrolldomäne eintreten. Hat der Eintritt beim Anbieter bereits stattgefunden, bleibt der Versuch verbraucht und muss abgestimmt werden. Die Wiederherstellung der Berechtigung lässt eine alte Reservierung nicht wieder aufleben.

Dafür sind vollständige Vermittlung und maßgeblicher gemeinsamer Zustand erforderlich. Die Sperre stoppt keine Berechnungen, macht keine Wirkung rückgängig und erreicht getrennte Domänen nicht sofort. Siehe die Implementierung und Grenzen der Kontrolldomäne.

In 30 Sekunden ausprobieren

# 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

Plattform-Passkey für eine Beispielzahlung ausprobieren → Signieren Sie eine beispielhafte Zahlung über 82.000 $, ändern Sie ihren Betrag und beobachten Sie, wie die Integritätsprüfung fehlschlägt. Ihr Authenticator verwendet möglicherweise Biometrie oder eine Geräte-PIN. Die Seite bietet außerdem eine separate Software-Simulation. Keiner der beiden Modi sendet eine Zahlung oder begründet eine Produktionsautorisierung.

Beliebigen Beleg in Ihrem Browser verifizieren — fügen Sie ihn ein; es wird nichts hochgeladen.

---

Funktionsweise — ein Berechtigungslebenszyklus

Selbst ausführen: node examples/crash-test.mjs — vollständig offline, kein API-Schlüssel.

  [ 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. Die Berechtigungsquelle definiert begrenzte Arbeit. Sie kann ein vom Kunden signiertes Betriebsprogramm, eine begrenzte Berechtigung, eine erforderliche menschliche Entscheidung, ein Quorum oder eine Zusammensetzung nativer Nachweise durch die vertrauende Partei sein.

Konkrete Arbeit. Gate bindet Methode, Ursprung, Aufrufer, Ziel, Vorkommen und jedes wesentliche Feld in das kanonische ausführbare Objekt ein. Eine Absicht, ein Prompt oder Tickettext ist nicht dieses Objekt.

Verifizieren, reservieren und eintreten. Native Artefakte bleiben nativ. Die vertrauende Partei legt Vertrauens- und Zuordnungsprofile fest, wertet die vollständigen Nachweisanforderungen aus, trifft die separate lokale Autorisierungsentscheidung und reserviert die abgedeckte Berechtigung, bevor der Adapter mit den Anbieteranmeldedaten beim Anbieter eintritt.

Aktuelle menschliche Berechtigung, wenn erforderlich. Eine Richtlinie kann eine an die exakte Aktion und den deterministischen Anzeige-Hash gebundene WebAuthn-/Passkey-Entscheidung verlangen. Dies verringert die Lücke zwischen „Was Sie gesehen haben“ und „Was Sie signiert haben“; es beweist weder Verständnis noch Weisheit, Rechtmäßigkeit oder Ergebnis. Für Enterprise-Deployments kann Gate zusätzlich eine unabhängig verifizierte Bestätigung des Authorization Servers verlangen, die an genau diesen menschlichen Nachweis, dieselbe exakte Aktion, den Identitätssnapshot, den der AS tatsächlich beobachtet hat, und den vorgesehenen Resource-Server-Schlüssel gebunden ist. Der Zeitpunkt des Snapshots und das maximale Alter, das die relying party zulässt, sind explizit: Ein frisches Token kann veraltete Verzeichnisdaten nicht aktuell machen. Der AS-Zweig ist ein Nachweis unter kundenseitig festgelegtem Vertrauen; er autorisiert niemals eigenständig, beweist keinen augenblicklichen Beschäftigungsstatus und macht den Agent-Orchestrator nicht zu einer Autorität.

Wahrheitsgemäßes Ergebnis. Zulassung ist keine Ausführung, und Ausführung ist keine Wirkung. Ein signierter Datensatz kann offline verifiziert werden; Nachweise des Providers und des Beobachters bleiben getrennt. Eine verlorene Antwort wird zu INDETERMINATE, einem Zustand, der abgeglichen werden muss – keine Erlaubnis für einen erneuten Versuch. Eine Abhilfe ist eine neue autorisierte Aktion und schreibt das alte Ergebnis niemals um.

---

Warum Entwickler es verwenden

Beginnen Sie damit, die Arbeit lokal zu erfassen, und schützen Sie dann eine deklarierte Aktionsoberfläche mit dem MCP-Server oder einem schlanken SDK-Wrapper. Der Scanner schlägt eine überprüfbare Übersicht vor; der Verantwortliche definiert das Mandat; Gate verwahrt die Provider-Anmeldedaten und setzt die exakte Aktion auf dem abgedeckten Pfad durch. Kein Scan beweist eine vollständige Vermittlung, und die Erkennung allein verleiht keine Befugnis.

# 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

Der Agent erhält die Fähigkeit, begrenzte Arbeit auszuführen, keine dauerhafte Anmeldeinformation, die er nach eigenem Ermessen umdeuten kann.

---

Warum Unternehmen es benötigen

Agent-Prozesse werden neu gestartet und Modelle ändern sich. Das Mandat des Kunden, der Verbrauchsstatus, der Widerruf, die Unsicherheit und der Arbeitsverlauf müssen außerhalb dieser Prozesse fortbestehen. EMILIA hält diesen dauerhaften Autorisierungszustand an der Kundengrenze und akzeptiert zugleich externe Nachweise über festgelegte Adapter.

Die verwaltete Gate- und Assurance-Ebene ergänzt den offenen Protokollstandard um Mandatsverwaltung, Integrationen, Nachweisverwaltung, erneute Durchführung, Support und Service-Level. Der Kunde behält die Kontrolle über Autorisierung, Vertrauensanker, Anmeldedaten, Richtlinien und portable Nachweise.

---

Der Standard

EMILIA Protocol ist offen und steht unter Apache-2.0. Die Standardisierungsarbeit wird als Portfolio einzelner Internet-Drafts veröffentlicht. Ein veröffentlichter Internet-Draft ist weder ein RFC noch ein angenommener Arbeitsgruppenbeitrag oder eine IETF-Empfehlung; für Revision und Status ist Datatracker maßgeblich.

IANA-Registrierungen

Zwei registrierte Namen bieten Implementierern eine gemeinsame Referenz für EMILIA-Formate:

• application/vnd.emilia.authorization-evidence-challenge+json wurde am 6. Oktober 2026 registriert. Der Name bezeichnet das unverpackte AE-CHALLENGE-v1 JSON-Objekt, das in der veröffentlichten Serialisierungsspezifikation definiert ist. HTTP-Ablehnungsantworten verwenden weiterhin application/problem+json.
• canactid: wurde am 5. Oktober 2026 vorläufig registriert. Der Name bezeichnet exakte typisierte Aktionen gemäß CAID-05. Die korrigierte CRI-Schemanummer lautet 1033.

Diese Registrierungen veröffentlichen die Namen und ihre Spezifikationen. Sie begründen weder eine IETF-Annahme noch eine Empfehlung, Zertifizierung oder Kundendeployment.

Eine Oberfläche an der Konsequenzgrenze

Das aktuelle veröffentlichte AEB-07, das am 25.09.2026 als individueller Internet-Draft veröffentlicht und nicht angenommen wurde, legt AEB als Kompositionspunkt nach einer nativen Entscheidung fest. OAuth, AuthZEN, COAZ, AP2 und lokale Systeme behalten die Zuständigkeit für ihre Anmeldedaten, Operationszuordnungen und Autorisierungsentscheidungen. AIMS (draft-ietf-wimse-aims) ist ein informatives Dokument der WIMSE-Arbeitsgruppe, das bestehende Standards wie WIMSE und OAuth profiliert; es stellt selbst weder Anmeldedaten noch Entscheidungen aus. AEB setzt die native Entscheidung an der geschützten Provider-Grenze durch: Bei Bedarf bindet es die endgültige Aktion, leitet pro Berechtigung eine native Replay-Identität ab, reserviert vor dem Eintritt beim Provider, verweigert einen zweiten Versuch für dieselbe Aktion, solange ein früherer Versuch läuft oder ungewiss ist, und hält ein ungewisses Ergebnis gesperrt, bis es authentifiziert abgeglichen wurde.

CAID-05 wird verwendet, wenn unabhängig codierte Darstellungen verglichen werden müssen. Neue Kennungen verwenden das vorläufig bei der IANA registrierte URI-Schema canactid:. Die Registrierung bedeutet weder IETF-Annahme noch Empfehlung, Zertifizierung oder dauerhaften Status. CAID ist keine obligatorische zweite Zuordnung, wenn der PEP, der die Konsequenz verantwortet, bereits eine aktuelle Entscheidung über die endgültige Operation ableitet und durchsetzt. Das Playground für exakte Aktionen ausprobieren oder den Migrationsleitfaden von CAID-04 zu CAID-05 lesen. AEC-06 wird verwendet, wenn die relying party mehrere Nachweiszweige verlangt. Autorisierungsbelege, Human Authorization Binding und Authority Introduction bleiben als Profile für Deployments verfügbar, die sie benötigen; sie sind keine Voraussetzung für jede AEB-Integration. Architecture-03 bleibt das Navigationsdokument.

Der Leitfaden zur Zulassung an der Konsequenzgrenze beschreibt die Implementierungsgrenze und die Fälle, in denen AEB nicht erforderlich ist. Das Profil für die direkte native Übergabe ist ein Implementierungsprofil des Repositorys, das zeigt, wie eine bestehende Genehmigung Gate ohne eine zusätzliche CAID- oder AEC-Ebene erreicht. AEB-07 spezifiziert, was eine solche Gateway-Übergabe bestätigt und wie die Grenze sie verifiziert, überlässt die Kodierung jedoch den Deployment-Pins; als informative Referenzkodierung verweist es auf einen festgelegten Snapshot dieses Profils. Die exakt eingereichten -07-Bytes und ihr Veröffentlichungsdatensatz sind in standards/staged/NEXT-AEB-07 aufbewahrt.

Das vollständige aktive Portfolio umfasst 26 Datatracker-Einträge: 21 allein verfasste Einträge und fünf gemeinsam verfasste Einträge, jeweils mit eigenem Geltungsbereich, Revisionsverlauf und dokumentiertem Wartungsstatus. Siehe den Standardleitfaden, das Portfolio und das maschinenlesbare Statusinventar.

IETF Internet-Drafts	Aktuelle lokale Snapshot-Pfade: Statusinventar · Inventar der veröffentlichten, allein verfassten Dokumente · maßgeblicher Live-Status: IETF Datatracker
Sprachübergreifende Verifizierer	JavaScript · Python · Go — alle drei stimmen nachweislich bei adversarialen Konformitätsvektoren überein, bei jedem Push (npm run conformance). Eine Konsistenzprüfung über die Ports eines Teams hinweg, keine unabhängigen Implementierungen aus dem Stand. Separat besteht eine extern verfasste Rust-Implementierung nach Spezifikation (Quellcode öffentlich) das festgelegte Paket mit 16 Testsuiten/164 Vektoren und die festgelegte Angriffskampagne mit 359 Fällen bei einem vom Evaluator kontrollierten Neuaufbau aus einem unveränderlichen Quellbaum. Die eingecheckten Konstruktionsnachweise sind weiterhin vom Implementierer signiert und nicht von Dritten bestätigt (signierte Erklärung); die strikte Clean-Room-Abnahme wartet auf das korrigierte, von Dritten bestätigte Manifest und den unabhängig festgelegten Attestierungsschlüssel.
Nachweise aus formalen Modellen	26 begrenzte TLA+-Sicherheitseigenschaften hielten in ihren konfigurierten Zustandsräumen; dies ist weder eine Implementierungsverfeinerung noch ein unbeschränkter Beweis · 35 Alloy-Fakten, 32 Assertions über vier Modelle · zwei zusammengesetzte symbolische Dolev-Yao-Modelle, die Challenge, CAID, zwei Genehmigungen, Aussteller- und Autoritätspins, Registry-Ansicht, Widerruf, Verbrauch, Ausführung und sechs dedizierte Anspruchsgrenzen abdecken. Zwanzig Tamarin-Lemmas sind verifiziert — 17 Verpflichtungen für alle Abläufe und 3 Zeugen für existierende Abläufe; acht absichtlich abgeschwächte Varianten erzeugen konkrete Angriffsspuren, wenn tragende Prüfungen entfernt werden (formal/tamarin/).
MCP-Distribution	npm-Paket @emilia-protocol/mcp-server · Die Veröffentlichung im offiziellen Registry wird separat in MCP-REGISTRY.md nachverfolgt; aus Einträgen in Aggregatoren wird keiner der beiden Status abgeleitet
Lizenz	Apache-2.0

Drei Referenz-Ports desselben Teams (JS / Python / Go) stimmen über alle 21 Testsuiten und 340 Vektoren hinweg überein. Separat besteht eine extern verfasste Rust-Implementierung, die aus einem festgelegten öffentlichen Quellbaum neu erstellt wurde, das festgelegte Clean-Room-Paket mit 16 Testsuiten/164 Vektoren und eine Angriffskampagne mit 359 Fällen; sie wird bei jeder Änderung in einer eigenen CI-Spur erneut ausgeführt. Die neueren AEC-Abnahme- und Vier-Ergebnis-Auflösungstestsuiten werden Rust nicht zugeschrieben. Das ist ein externer Interoperabilitätsnachweis, keine strikte Clean-Room-Konstruktionsabnahme; der aggregierte CI-Falldatensatz weist bis zur unabhängigen Attestierung die Zahl der strikten Abnahmen mit null aus. Siehe CONFORMANCE.md oder verifizieren Sie selbst einen Beleg unter emiliaprotocol.ai/verify.

---

Der Autorisierungsstapel

Ebene	Aufgabe
Mandat	Definiert Mission, Grenzen, Nachweise, Ablauf, Delegation und Ausnahmeregeln.
CAID / exakte Aktion	Vergleicht die wesentliche Bedeutung, wenn Autorisierung und Ausführung unabhängig codierte Darstellungen verwenden; autorisiert nicht.
AEC	Bewertet bei Bedarf, ob unabhängig verifizierte und abgeglichene Nachweise die Mehrfachanforderung der relying party erfüllen; autorisiert nicht.
AEB / Gate	Setzt die native oder lokale Autorisierungsentscheidung an der Konsequenzgrenze durch, reserviert die abgedeckte Berechtigung und kontrolliert den Eintritt beim Provider.
Ergebnisnachweise	Hält Aufruf, Provider-Antwort, beobachtete Wirkung und Unsicherheit getrennt.

---

Nachweise

Kennzahl	Wert
Automatisierte Testfälle	Mehr als 10.700 über mehr als 650 Dateien; alle plattformrelevanten Fälle müssen bestehen
TLA+-Sicherheitseigenschaften	26 begrenzte Invarianten hielten im konfigurierten Zustandsraum; kein Implementierungsverfeinerungs- oder unbeschränkter Beweis — siehe PROOF_STATUS.md
Relationale Alloy-Assertions	35 Fakten + 32 Assertions über vier Modelle — in CI verifiziert
Erfasste Red-Team-Fälle	86 — RED_TEAM_CASES.md
Sicherheitsstatus der Veröffentlichung	Sicherheitsprüfungen des Repositorys bestanden; alle Strix-Befunde zu den geprüften Änderungen wurden mit Regressionstests behoben und der jeweilige Review-Thread abgeschlossen
Konformität (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Sprachübergreifende Konformität	340 Vektoren · 21 Testsuiten: Belege · Gerätefreigaben · Vier-Ergebnis-Auflösung · Mehrparteien-Quorum · Widerruf · Outcome Binding (semantisch + echte Kryptografie) · Verknüpfung von Authority Document/Proof-Aussteller · Zeitattestierung · Trust-Receipt (x2 Profile) · Herkunft · Nachweisdatensatz · Kanonisierung · Grenze · AEC-Abnahme · Währung · Initiatorattestierung · Verbrauchsnachweis · Zeuge · Zeitstempelnachweis (RFC 3161). JS / Python / Go-Verifizierer stimmen überein (node conformance/run.mjs). Die externe Rust-Baseline umfasst weiterhin 164 Vektoren / 16 Testsuiten. Siehe CONFORMANCE.md.
p95 für Handshake-Erstellung	575 ms bei 50 VUs — PERFORMANCE_PROOF.md

Kryptografische Langlebigkeit (mit expliziten Deployment-Grenzen)

Nachweise, die noch Jahre später verifiziert werden sollen, müssen länger bestehen als die Algorithmen, mit denen sie signiert wurden. EP bietet dafür vier klar begrenzte Funktionen, jeweils mit einer exakten Grenze, die Teil der Aussage ist:

• Hybride Signaturen (EP-RECEIPT-HYBRID-v1). Ed25519 und ML-DSA-65 über dieselben kanonischen Bytes, wobei die erforderliche Algorithmusmenge in den signierten Bytes festgeschrieben ist, sodass das Entfernen eines Teils die verbleibende Signatur ungültig macht. Die Funktion ist bei der Bereitstellung optional; sobald ein genehmigter dualer Signierer registriert ist und die Richtlinie seinen PQ-Anteil zulässt, wird bei einer nicht festgelegten Gate-Haltung standardmäßig eine duale Ausstellung gewählt. Andernfalls bleibt es bei ausschließlich klassischen Signaturen, mit einem benannten Grund. v1- Verifizierer lehnen hybride Belege ordnungsgemäß ab, statt einen Anteil anzunehmen. Der externe Signierer-Vertrag und der AWS-KMS-Adapter sind implementiert, aber es wird weder ein aktiver AWS-Signaturaufruf noch ein Produktionsschlüssel, eine Verifizierung durch eine vertrauende Partei oder eine ML-DSA-FIPS-Validierung beansprucht. Siehe conformance/hybrid-receipts/ und lib/pq-custody-aws-kms.ts.
• SCITT-Profil für signierte Statements (EP-SCITT-STATEMENT-v1). Eine vollständige RFC-9943-Form eines signierten Statements für EP-Belege, einschließlich des geschützten CWT-Claims-Headers. Einschränkung: Kein Transparency Service hat ein EP-Statement angenommen; die externe Registrierung ist ein separater, kontrollierter Schritt und wurde nicht durchgeführt. Siehe EP-RECEIPT-SCITT-PROFILE.md.
• Erneute Attestierung (EP-EVIDENCE-REATTESTATION-v1). Unter einem alternden Algorithmus signierte Nachweise können unter einem aktuellen Algorithmus neu verankert werden, bevor der alte schwächer wird. Einschränkung: Die erneute Attestierung muss vor einer Kompromittierung erfolgen; nachträglich kann sie Nachweise nicht reparieren.
• FIPS-Bereitstellungsmodus (EP-FIPS-MODE-v1). Führt klassische Operationen über einen vom Betreiber bereitgestellten, nach FIPS 140-3 validierten Provider aus; der ML-DSA-Pfad ist durch eine ausdrückliche Bestätigung der nicht validierten Implementierung gesperrt. Einschränkung: Dies rechtfertigt die Aussage „FIPS-basierte Algorithmen mit einem Bereitstellungsmodus für validierte Provider“ und hängt vom Provider des Betreibers sowie der angegebenen Zertifikatsgrenze ab; es ist keine pauschale Konformitätsaussage, und nichts hiervon ist FIPS-validiert. Siehe FIPS-MODE.md.

Das stackweite Hybridprogramm (jede interne Signaturoberfläche) ist unter pq-hybrid-program.md beschrieben und noch nicht abgeschlossen; bis dahin wird keine pauschale Aussage über den gesamten Stack getroffen.

---

Zentrale Protokollobjekte

Objekt	Beschreibung
Authority-Programm / begrenzte Berechtigung	Ein befristetes Mandat mit explizitem Geltungsbereich, Budget oder Einheiten, Ablaufdatum, Delegierung und Verbrauchsregeln.
CAID	Ein kanonischer Bezeichner für eine einzelne materielle Aktion unter einem benannten Zuordnungsprofil; Übereinstimmung ist keine Autorisierung.
Nachweisanforderung und AEC-Ergebnis	Die festgelegte Regel der vertrauenden Partei und ihre Auswertung SATISFIED, UNSATISFIED oder INDETERMINATE.
AEB-Zulassungs- und Verwahrungsdatensatz	Der Datensatz auf der Ausführungsseite zu Autorisierung, Reservierung, Provider-Aufruf und Abgleichstatus.
Autorisierungs- und Ergebnisevidenz	Übertragbare native oder EP-Artefakte, die ihren exakten Aussteller, Geltungsbereich und Anspruchsrahmen beibehalten.

---

Schnellstart

1. Installiere die exakte lokale Guard-Laufzeit und führe dann npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify aus. Ersetze dabei sendWire durch genau ein deklariertes, folgenreiches Tool.
2. Prüfe die generierte Authority Map, das Aktionsmanifest, die materiellen Felder, die ausgewählte Grenze und die benannten blinden Flecken.
3. Führe den separaten Befehl --reviewed --crossing-profile <launch-profile> aus, um aus diesen unveränderten Bytes die nur für den Eigentümer zugängliche Übergabe und den unversiegelten Lab-Arbeitsbereich zu erstellen.
4. Installiere Gate auf dem Pfad, der die Provider-Anmeldedaten und den dauerhaften Verbrauchsstatus verwaltet.
5. Definiere das Betriebsmandat sowie alle Ausnahmeregeln für eine erneute menschliche Freigabe oder ein Quorum.
6. Führe die Fälle für Ablehnung, exakte Aktion, Replay, Timeout und Abgleich aus, bevor du die Durchsetzung aktivierst.

90-Sekunden-Demo · Schnellstart · Agenten-Walkthrough · IETF-Entwurf · Discord

---

Was EP ist – und was nicht

EMILIA ist eine Autorisierungsinfrastruktur für autonome Arbeit, kein Identitätssystem, keine Wallet, kein Reputationswert, kein Abwicklungsnetz und keine universelle Richtlinien-Engine.

• Ist: eine Kontrollebene für befristete Betriebsmandate, die Verifizierung exakter Aktionen, dauerhaften Zulassungsstatus, wahrheitsgemäßen Umgang mit Unsicherheit und übertragbare Nachweise auf abgedeckten Ausführungspfaden.
• Ist nicht: ein Ersatz für OAuth/OIDC, Workload-Identität oder Richtlinien-Engines. Diese bleiben native Eingaben gemäß den Festlegungen der vertrauenden Partei.
• Ist nicht: eine Vorgabe, dass ein Mensch jede Aktion genehmigen muss. Ein Mandat kann automatische Arbeit innerhalb festgelegter Grenzen erlauben und nur an deren Rand eine neue Autorisierung verlangen.
• Ist nicht: ein Beweis dafür, dass eine zugelassene Aktion erfolgreich ausgeführt wurde oder die beabsichtigte Wirkung erzielt hat.
• Ist nicht: proprietäre Protokollkontrolle. Der Kern steht unter Apache-2.0, und die Internet-Drafts sind individuelle Einreichungen, keine RFCs und keine Billigung durch die IETF.

Siehe CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutralitätsvereinbarung