StonewaveEN DEKonto erstellen

Open Source · Rust · Prototyp

Agent
Authority.

Vollmacht und Haftung für KI-Agenten

Ein Agent ist kein Rechtssubjekt. Er handelt immer im Namen eines Auftraggebers, unter einer kryptografisch signierten, begrenzten, widerrufbaren Vollmacht, die jeder Prüfer deterministisch kontrolliert, ohne LLM im Vertrauenspfad.

Auf GitHub ansehenLive-Demo ausprobieren
LivePrototyp, kein Standard. 41 Tests im Repository. Zuletzt bewegt am 18. Okt. 2026.

Was es ist

Beweisbar, nicht behauptet.

Das ist kein Versuch, A2A, MCP oder OAuth zu ersetzen. Es ist das Stück, das diese nicht abdecken: eine beweisbare Antwort auf „wer hat gehandelt, in wessen Auftrag, in welchen Grenzen, und wer haftet“. Ein anderer Agent, eine API, eine Bank, irgendwann eine Behörde: Jeder Prüfer kontrolliert dieselbe signierte Vollmacht auf dieselbe deterministische Weise.

01 · Vollmacht

Ein Auftraggeber signiert eine Vollmacht.

Eine natürliche oder juristische Person stellt einem Agenten eine signierte Vollmacht aus: welche Aktionen, welche Ressourcen, welche Gegenparteien, welche Zeitfenster, welche Ausgabengrenze. Von Haus aus begrenzt, jederzeit widerrufbar.

02 · Handeln

Der Agent signiert seine Anfrage selbst.

Jede Anfrage des Agenten ist selbst signiert und trägt eine Einmalzahl und den vorgesehenen Empfänger. Eine gültige signierte Anfrage für einen Prüfer lässt sich deshalb nie bei einem anderen wiederholen.

03 · Prüfen

Eine reine Funktion entscheidet. Kein Modell.

Signatur, zeitliche Gültigkeit, Widerruf, Verengung bei Unter-Vollmachten und Bereichsabgleich sind deterministische Prüfungen in aap-core (Rust). Nichts wird „interpretiert“.

04 · Beleg

Jede Entscheidung liefert eine signierte Quittung.

Angenommen oder abgelehnt: Der Prüfer erzeugt einen dauerhaften, unabhängig prüfbaren Beleg, was entschieden wurde und warum. Ein Prüfpfad, der nicht davon abhängt, dem Protokoll des Agenten zu glauben.

Zeigen statt behaupten

Sieh zu, wie es entscheidet.

Derselbe aap-core-Prüfer, zu WebAssembly kompiliert, läuft in dieser Seite. Stell eine Vollmacht aus, schick eine Anfrage, sieh, wie sie angenommen oder abgelehnt wird, spiel sie erneut ab, widerrufe sie, mit einer signierten Quittung für jede Entscheidung.

Im Vollbild öffnen ↗

Entwurfsentscheidungen

SPRACHE

Rust, nicht TypeScript

Ein Typestate-Muster macht ungeprüfte und geprüfte Vollmachten zu verschiedenen Typen. Code, der aus einem ungeprüften Token Rechte vergibt, lässt sich nicht übersetzen.

SIGNATUREN

Kompaktes JWS über Ed25519 und ECDSA P-256

P-256 gibt es, weil Secure Enclaves von Telefon und Laptop nur P-256-Schlüssel erzeugen können. Der Algorithmus im Kopf wird gegen den eigenen Schlüssel des Aufrufers geprüft, bevor die Prüfung läuft.

BEREICHSPRÜFUNG

Eine reine, deterministische Funktion

Sie nimmt strukturierte Eingaben, gibt ein Ja oder Nein zurück und berührt keinen äußeren Zustand: prüfbar, testbar, immun gegen Prompt-Injection.

WIDERRUF

Status-Abruf plus Ablaufdatum

Ein abrufbares Widerrufs-Flag plus ein hartes Ablaufdatum. Eine Standard-Statusliste ist die echte Langzeitantwort; lohnt sich erst, wenn das Konzept belegt ist.

KETTEN

Unter-Vollmacht nur, wenn erlaubt

Ein Teilbereich muss den übergeordneten verengen, nie erweitern. Das verhindert Rechteausweitung über Weitergabe.

SCHLÜSSEL

In v1 lokale Schlüssel, hinter einer Signier-Schnittstelle

Später gegen KMS oder HSM austauschbar, ohne eine Aufrufstelle anzufassen.

Fahrplan

  • Phase 0: Spezifikation Fertig
    Vollmacht-Schema, Bereichssprache, Prüfablauf, minimaler Nachrichtensatz.
  • Phase 1: Minimaler Prototyp Fertig
    Schlüsselpaare für Auftraggeber und Agent, Vollmacht ausstellen und signieren, ein Prüfer, eine lauffähige Demo.
  • Phase 2: Robustheit Offen
    Ketten von Unter-Vollmachten und Quittungen sind fertig. Ein KMS-gestützter Signierer und ein echter Registerdienst sind noch lokal oder im Speicher.
  • Phase 3: Öffnen Offen
    WASM-Anbindung und Browser-Demo sind fertig. DID/VC-Auflösung und Abbildung auf A2A, OpenID AuthZEN und GNAP sind noch offen.

Fragen

Ist das produktionsreif?

Nein. Es ist ein lauffähiger Prototyp mit Rust-Kern, 41 Tests im Repository und einer Browser-Demo, kein fertiger Standard. Der Fahrplan zeigt, was fertig und was offen ist.

Wie unterscheidet sich das von OAuth, MCP oder A2A?

Es ersetzt sie nicht. AAP ist der Teil, den sie nicht abdecken: eine beweisbare Antwort darauf, wer gehandelt hat, in wessen Auftrag, in welchen Grenzen und wer haftet.

Entscheidet je ein LLM, ob eine Aktion erlaubt ist?

Nein. Jede Entscheidung im Prüfablauf ist eine deterministische Funktion in aap-core, geschrieben in Rust. Kein Modell sitzt im Vertrauenspfad.