EMILIA Protocol MCP Server

offiziell

Fordert die offline-verifizierbare Zustimmung einer namentlich genannten Person, bevor ein KI-Agent eine irreversible Aktion ausführt – Zahlungsfreigabe, Datensatzänderung, Bereitstellung. Zwei-Personen-Regel, Ed25519 Trust Receipts, IETF-entworfen, Apache-2.0.

GitHub

Dokumentation

EMILIA Protocol

Der Motor ohne Bremsen

Fünfzig Jahre lang beantwortete Softwaresicherheit eine Frage: Wer darf rein? Firewalls, OAuth und Passwörter – alles darauf ausgelegt, eine menschliche Identität an der Tür zu verifizieren.

Diese Ära endet. Die dominierenden Nutzer von Software sind keine Menschen mehr, sondern autonome KI-Agenten. Agenten loggen sich nicht nur ein – sie schreiben Code, rufen Werkzeuge auf und verändern die Realität im Handumdrehen. Jeder CISO weiß, dass ein einziger schlechter Prompt einen Agenten dazu bringen kann, eine Produktionsdatenbank zu löschen oder Geld auf das falsche Konto zu überweisen. Also blockieren sie die Bereitstellung – sie sitzen auf Milliarden an KI-Budget, das sie nicht ausgeben können, weil ihre Compliance-Teams eine Frage nicht beantworten können:

Wer hat diese Aktion genehmigt?

Die Krise unserer Generation ist nicht die Authentifizierung. Es ist die Autorisierung im Moment der Aktion: Wie beweist man, dass das, was ein Agent tun wird, genau das ist, was ein benannter Mensch autorisiert hat – bevor es ausgeführt wird?

EMILIA ist der Sicherheitsgurt für das agentische Zeitalter.

Entscheidungsprotokolle sind Zeugnisse. EMILIA erstellt Belege.

Kein Beleg, keine irreversible Aktion

Wenn ein Agent versucht, Geld zu bewegen, Code zu löschen, in Produktion bereitzustellen, Berechtigungen zu ändern oder regulierte Zustände zu verändern, ohne einen gültigen EMILIA-Beleg, verweigert das Werkzeug die Ausführung – und wenn es läuft, kann jeder überprüfen, wer genau was autorisiert hat, offline, ohne jemandem zu vertrauen.

Das ist das gesamte Protokoll. Der Entwickler-Keil ist ein Wrapper um ein irreversibles MCP-Werkzeug. Sehen Sie es kalt, vollständig offline, kein Schlüssel, kein Konto – jede Demo durchläuft die gesamte Schleife (verweigert → benannter Mensch signiert die exakte Aktion → Werkzeug läuft → gefälschter Beleg abgelehnt):

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

Wickeln Sie Ihren eigenen Werkzeug-Dispatcher in Produktion ein – siehe examples/mcp/ und /mcp:

import { withMcpGuard } from '@emilia-protocol/mcp-guard';
const guarded = withMcpGuard(handleTool, {
  annotations: { release_payment: { irreversible: true, action: 'payment.release' } },
}); // missing receipt → refused, never a silent pass

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

Echte Face-ID-Freigabe ausprobieren → Genehmigen Sie eine Überweisung über 82.000 $ mit Ihrem eigenen Passkey. Sehen Sie, wie VERIFIZIERT aussieht. Fälschen Sie den Beleg. Sehen Sie, wie es fehlschlägt.

Jeden Beleg in Ihrem Browser verifizieren – fügen Sie ihn ein, nichts wird hochgeladen.

Wie es funktioniert – vier Akte

EMILIA crash test — an autonomous agent tries to wire $82,000; the policy engine holds it, a named human signs off on their own device, the receipt verifies offline, and a forged copy fails.

Führen Sie es selbst aus: node examples/crash-test.mjs – vollständig offline, kein API-Schlüssel.

  [ INTENT ]          [ DECISION ]           [ CEREMONY ]           [ RECEIPT ]
  Agent calls a     Policy-bound, hash-    Named human signs     Signed, offline-
  tool via MCP   →  pinned: allow /     →  the EXACT action  →  verifiable proof.
                    allow-with-signoff /   on their own          Tamper it:
                    deny  (+observe        device (passkey).      fails by design.
                    mode: zero change      What they saw =
                    to production)         what they signed.

Akt I – Abfangen (MCP-nativ). Keine Umschreibungen. EMILIA hängt den Werkzeugaufruf an der Model-Context-Protocol-Grenze ein – in dem Moment, in dem ein Agent versucht, eine Datei zu löschen oder Kapital zu bewegen, wird die Aktion in der Luft abgefangen.

Akt II – Entscheidung (richtliniengebunden, deterministisch). Die Aktion wird gegen eine Hash-gebundene Richtlinie geprüft: allow, allow-with-signoff oder deny. Plus ein Beobachtungsmodus, der in der Produktion nichts ändert und meldet, was zurückgehalten worden wäre. Deterministisch, prüfbar – kein Black-Box-Risiko-Score.

Akt III – Die Zeremonie (gerätegebundene menschliche Freigabe). Wenn die Richtlinie einen Menschen erfordert, führt EMILIA eine WebAuthn / Passkey-Freigabe durch, die an die exakte Aktion gebunden ist – Face ID / Touch ID auf dem eigenen Gerät des Bedieners. Was der Mensch gesehen hat, ist das, was er signiert hat. Kein Skript kann es fälschen; keine autonome Schleife kann es überspringen.

Akt IV – Der Beleg (der Beweis). Das Ergebnis ist ein signierter Autorisierungsbeleg, den jeder offline, mit Open-Source-Code, ohne Backend, ohne Anbietervertrauen verifizieren kann. Manipulieren Sie ihn, und die Verifizierung schlägt konstruktionsbedingt fehl. Optional für öffentliche Zeitstempel verankern – der Kern benötigt keine Blockchain.

Warum Entwickler es nutzen

Sie wollen Agenten, die tatsächlich Dinge tun – aber Sie sind gelähmt durch außer Kontrolle geratene Schleifen, API-Überausgaben und versehentliche Datenzerstörung. EMILIA gibt Ihnen einen Plug-and-Play-MCP-Server + einen schlanken SDK-Wrapper. Wenden Sie einen Richtlinien-Hash an, und irreversible Werkzeugaufrufe erhalten eine kryptografisch gehärtete, NIST-AI-RMF-zugeordnete Genehmigungs- und Beweisschicht – ohne Genehmigungsworkflows oder Prüfinfrastruktur von Grund auf neu aufzubauen.

# 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

Ihr Agent kann seiner Leine nicht entlaufen.

Warum Unternehmen es brauchen

Jeder Plattformwechsel prägt eine neue Sicherheitsprimitive: Das Web bekam SSL, die Cloud bekam Okta / IAM, die Agentenökonomie braucht Vertrauen auf Aktionsebene. Unternehmen sitzen auf KI-Budgets, die Compliance nicht ausgeben lässt – EMILIA ist der Schlüssel, der sie freischaltet, indem es unvorhersehbare Agenten in prüfbereite Infrastruktur verwandelt, die Primitiv für Primitiv auf NIST AI RMF, EU AI Act und SOC 2 CC6/7-Kontrollen abbildet.

Die verwaltete Schicht (GovGuard / FinGuard) erweitert den offenen Standard um sektorspezifische Richtlinienpakete, Beobachtungsmodus-Piloten und prüfbereite Beweispakete – ohne dass eine Beschaffung für den Start erforderlich ist.

Der Standard

EMILIA ist ein offener Standard, kein Produktgraben. Der Kern steht unter Apache-2.0 und wird als IETF-Internet-Draft geführt.


IETF-Internet-Drafts	Veröffentlicht: authorization-receipts · quorum. Bereitgestellt in `standards/`: authorization-evidence-chain (EP-AEC, Komposition) · evidence-record (EP-EVIDENCE-RECORD, Langzeitaufbewahrung). Feldübersicht: Landschaftsüberblick.
Sprachübergreifende Verifizierer	JavaScript · Python · Go – alle drei erwiesenermaßen übereinstimmend bei adversariellen Konformitätsvektoren, bei jedem Push (`npm run conformance`). Das ist die IETF-Messlatte für einen echten Standard: mehrere unabhängige interoperable Implementierungen.
Formale Verifikation	26 TLA+-Sicherheitseigenschaften (0 Fehler) · 35 Alloy-Fakten, 22 Behauptungen – beide laufen in CI
MCP-Registries	Offizielle MCP-Registry · Glama (Grade A, Official Badge) · Smithery
Lizenz	Apache-2.0

Drei unabhängige Implementierungen, die erwiesenermaßen übereinstimmen – siehe CONFORMANCE.md oder verifizieren Sie einen Beleg selbst unter emiliaprotocol.ai/verify.

Der EP-Stack

Eye observes. Handshake verifies. Signoff owns. Commit seals.

Schicht	Was sie tut
EP Eye	Beobachtet und klassifiziert Agentenverhalten (OBSERVE → SHADOW → ENFORCE)
EP Handshake	Kryptografische Zustimmungszeremonie mit 7-Eigenschaften-Bindung
EP Signoff	Benannte menschliche Eigentümerschaft – WebAuthn / Passkey Klasse A, gerätegebunden; Mehrparteien-Quorum (M-von-N / geordnet – die Zwei-Personen-Regel) für Aktionen mit höchstem Risiko
EP Commit	Atomarer, unveränderlicher Aktionsabschluss mit Merkle-verketteten Belegen

Beweispunkte

Metrik	Wert
Automatisierte Tests	4.220 über 173 Dateien
TLA+-Sicherheitseigenschaften	26 verifiziert (T1–T26), 0 Fehler – siehe PROOF_STATUS.md
Alloy-relationale Behauptungen	35 Fakten + 22 Behauptungen über zwei Modelle – in CI verifiziert
Katalogisierte Red-Team-Fälle	85 – RED_TEAM_CASES.md
Behobene Sicherheitsfunde	31
Konformität (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
Sprachübergreifende Konformität	8 Suiten – Belege · Gerätefreigaben · Mehrparteien-Quorum · Widerruf · Zeitbestätigung · Vertrauensbeleg · Provenienz · Beweisdatensatz – JS / Python / Go-Verifizierer stimmen überein (`node conformance/run.mjs`)
Handshake-Erstellung p95	575 ms bei 50 VUs – PERFORMANCE_PROOF.md

EP-Kernobjekte

EP standardisiert drei interoperable Objekte, die jede konforme Implementierung erzeugen und verifizieren kann:

Objekt	Was es ist
Trust Receipt	Ein portabler, signierter Datensatz eines Autorisierungsereignisses – was passiert ist
Trust Profile	Eine standardisierte Zusammenfassung des beobachtbaren Vertrauenszustands – was bekannt ist
Trust Decision	Ein richtlinienbewertetes Ergebnis mit Gründen und Einspruchsweg – was jetzt zu tun ist

EP-Erweiterungen (Handshake, Signoff, Commit, Delegation) fügen stärkere Durchsetzung hinzu, wo Systeme die Ausführung einschränken müssen. Die Produktschichten (GovGuard / FinGuard) sind darauf aufgebaut – nicht das Protokoll selbst.

Schnellstart in fünf Aufrufen

Richtlinie erstellen
Handshake initiieren
Beweise vorlegen
Verifizieren
Freigabe und Konsum

90-Sekunden-Demo · Schnellstart · Agent-Walkthrough · IETF-Draft · Discord

Was EP ist – und was nicht

EP ist Autorisierung im Moment der Aktion, kein Identitätssystem, keine Wallet, kein Reputations-Score.

Ist: ein Vertrauensstandard zur Bindung von Akteursidentität, Autorität, Richtlinie und exaktem Aktionskontext vor der Ausführung
Ist nicht: ein Ersatz für OAuth / OIDC (diese beantworten wer bist du – EP beantwortet wer hat diese exakte Aktion genehmigt)
Ist nicht: ein proprietäres Produkt (der Kern ist Apache-2.0 und IETF-geführt)
Ist nicht: eine Blockchain (der Beleg ist der Held; optionale öffentliche Zeitstempelung ist eine Fußnote)

Siehe CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md