AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

Die Arbeit stellt AEX vor, eine nicht-intrusive Erweiterung für JSON-basierte LLM-APIs, die durch signierte Attestierungsobjekte eine vertrauenswürdige Nachverfolgung der Beziehung zwischen Client-Anfragen und API-Antworten sowie die sichere Provenienz von Ausgaben ermöglicht, ohne die bestehende API-Semantik zu verändern.

Das Wesentliche

Stellen Sie sich vor, Sie bestellen ein komplexes Gericht in einem Restaurant, das Sie nicht selbst betreten können. Sie schicken Ihre Bestellung über einen Kellner (die API) in die Küche. Am Ende erhalten Sie das Essen zurück. Aber wie können Sie sicher sein, dass:

1. Der Koch wirklich das gekocht hat, was Sie bestellt haben?
2. Niemand unterwegs das Essen umgetauscht hat?
3. Der Kellner nicht einfach ein anderes Gericht aus der Speisekarte genommen und behauptet hat, es sei Ihr Essen?

Das ist genau das Problem, das mit Künstlicher Intelligenz (KI) und deren APIs (den Schnittstellen, über die wir KI-Modelle nutzen) passiert. Oft wissen wir nicht genau, ob die Antwort der KI wirklich von dem Modell stammt, das wir glauben, oder ob sie unterwegs manipuliert wurde.

Die Forscherin Yongjie Guan aus diesem Papier schlägt eine Lösung vor, die sie AEX nennt. Hier ist eine einfache Erklärung, wie das funktioniert, mit ein paar anschaulichen Vergleichen:

1. Das Problem: Der "Schatten-API"-Kellner

Stellen Sie sich vor, es gibt viele Kellner, die behaupten, sie würden für das berühmte Restaurant "OpenAI" arbeiten. Manche sind echte Angestellte, andere sind Betrüger, die nur so tun.

• Das Risiko: Sie bestellen "Pizza", aber der Kellner gibt Ihnen eine "Torte" und behauptet, das sei die Pizza. Oder er gibt Ihnen die Pizza, aber jemand hat unterwegs eine Mücke hineingeworfen.
• Bisherige Lösungen: Bisher versuchten Leute, die Pizza zu "schmecken" (Fingerabdruck-Tests), um zu erraten, wer sie gemacht hat. Das funktioniert aber nicht immer zuverlässig. Oder sie verlangen, dass der Koch seine Kochjacke (Hardware) vorzeigt. Das ist aber oft zu kompliziert für den normalen Gast.

2. Die Lösung: AEX – Der "Unverfälschte Siegel-Beleg"

AEX ist wie ein digitaler, versiegelter Beleg, den der Chef des Restaurants (der vertrauenswürdige KI-Anbieter) direkt auf Ihre Bestellung und Ihr Essen klebt.

Wie funktioniert das im Alltag?

• Der "Klebe-Beleg" (Attestation):
  Wenn Sie Ihre Bestellung (den "Request") absenden, fügt das System einen unsichtbaren, aber mathematisch unzerstörbaren Stempel hinzu. Wenn das Essen (die "Antwort") zurückkommt, ist auf dem Teller ein weiterer Stempel.

  • Die Magie: Der Stempel auf dem Teller beweist: "Dieses Essen wurde genau für diese Bestellung zubereitet." Wenn jemand unterwegs das Essen ändert (z. B. die Pizza in eine Torte verwandelt), passt der Stempel nicht mehr. Der Beleg wird ungültig.

• Die "Spezial-Kellner" (Vertrauenswürdige Zwischenhändler):
  Manchmal muss Ihre Bestellung auf dem Weg in die Küche angepasst werden (z. B. "Keine Nüsse!" hinzufügen). Oder das Essen wird auf dem Weg zurück umverpackt (z. B. aus einer Schale in eine Box).

  • Das AEX-System: Es erlaubt diesen Änderungen, aber nur, wenn sie offiziell genehmigt sind. Jeder Kellner, der etwas ändert, muss einen eigenen, unterschriebenen Zettel (einen "Quittungs-Beleg") hinterlassen.
  • Am Ende sehen Sie nicht nur, dass das Essen da ist, sondern auch eine Kette von Zetteln: "Chef hat Pizza gemacht -> Kellner A hat 'Keine Nüsse' hinzugefügt -> Kellner B hat es in die Box gepackt."
  • Wenn ein Kellner heimlich etwas ändert (z. B. die Pizza durch eine Torte ersetzt), fehlt der Zettel, und Sie wissen sofort: "Aha, hier wurde geschummelt!"

• Der "Live-Stream" (Streaming):
  Oft kommt die Antwort der KI nicht als ein ganzer Teller, sondern als einzelne Bissen, die nacheinander ankommen (wie ein Video-Stream).

  • Das Problem: Wie weiß man, ob der Stream mitten drin abgehackt wurde oder ob jemand einen Bissen eingefügt hat?
  • Die AEX-Lösung: Es gibt zwei Modi:
    1. Der direkte Stream: Jeder Bissen wird sofort mit einem Siegel versehen. Sie können sofort sehen: "Ja, der erste Bissen ist echt, der zweite auch..."
    2. Der umgepackte Stream: Wenn das Essen unterwegs umgepackt wurde (z. B. aus einem Stream in ein ganzes Gericht verwandelt), gibt es keine "Bissen-Siegel" mehr. Stattdessen erhalten Sie am Ende einen Gesamt-Beleg, der beweist: "Dieses ganze Gericht wurde aus dem ursprünglichen Stream zusammengesetzt, und hier ist die Kette der Umverpacker."

3. Was AEX NICHT tut (Die Grenzen)

Es ist wichtig zu verstehen, was dieser "Beleg" nicht beweist:

• Er beweist nicht, dass die Pizza schmeckt (die KI-Antwort ist nicht unbedingt "wahr" oder "faktisch korrekt").
• Er beweist nicht, dass der Koch keine geheimen Zutaten (versteckte Prompts) benutzt hat.
• Er beweist nur: Dieses Essen wurde von diesem Koch für diese Bestellung zubereitet und niemand hat es unterwegs manipuliert.

Zusammenfassung in einem Satz

AEX ist wie ein unfälschbares, digitales Siegel, das auf Ihre KI-Bestellung geklebt wird. Es garantiert, dass das, was Sie am Ende erhalten, genau das ist, was Sie bestellt haben – und wenn jemand unterwegs etwas geändert hat (auch von vertrauenswürdigen Helfern), dann ist das genau dokumentiert. Wenn jemand heimlich schummelt, platzt das Siegel, und Sie werden es sofort merken.

Das Ziel ist es, das Vertrauen in die KI-Infrastruktur wiederherzustellen, ohne dass man die ganze Küche (die KI-Modelle) umbauen muss. Es ist ein "Aufkleber für die Wahrheit" an der Tür des Restaurants.

Technische Zusammenfassung

1. Problemstellung

Große Sprachmodelle (LLMs) werden zunehmend über Remote-APIs abgerufen, wodurch die Vertrauensgrenze von der lokalen Ausführung zur API-Schnittstelle verschoben wird. Aktuelle Untersuchungen von „Shadow-APIs" (inoffizielle Endpunkte, die offizielle APIs imitieren) zeigen, dass diese oft von der behaupteten Funktionalität abweichen oder die Integrität der Ausgabe nicht garantieren.

Bestehende Ansätze zur Verifizierung haben folgende Mängel:

• Fingerabdruck-Tests und statistische Analysen: Sind oft unvollständig und können Verhaltensänderungen trotz identischer Modell-Identität nicht erkennen.
• Verifizierbare Inferenz und TEEs (Trusted Execution Environments): Sind entweder zu invasiv, erfordern Einblick in das Modell-Interne oder beantworten andere Fragen (z. B. „Welches Modell läuft?" statt „Ist diese spezifische Antwort auf diese spezifische Anfrage zurückzuführen?").

Es fehlt eine nicht-invasive, online verifizierbare Methode, die direkt an der API-Schnittstelle nachweist, dass eine spezifische Client-Anfrage mit einer bestimmten Antwort (oder einem Stream) verknüpft ist, ohne die bestehende API-Semantik zu verändern.

2. Methodik: AEX (Attestation Extension)

AEX ist ein Protokoll-Extension, das auf JSON-basierten LLM-APIs aufsetzt. Es fügt eine signierte, oberste Ebene (attestation) zu den JSON-Antworten hinzu, ohne den eigentlichen Geschäftsinhalt (Business Payload) zu verändern.

Kernmechanismen:

• Canonicalisierung: AEX verwendet das JSON Canonicalization Scheme (JCS), um eine deterministische Byte-Repräsentation für Hash-Berechnungen zu gewährleisten, unabhängig von Formatierungsunterschieden (Leerzeichen, Feldreihenfolge).
• Kryptografische Commitments:
  • Request Commitment: Ein Hash der Client-Anfrage (oder einer selektierten Projektion).
  • Output Commitment: Ein Hash der vollständigen Antwort oder einer authentifizierten Stream-Sequenz.
• Request-Binding-Modi: Der Client kann wählen, wie streng die Anfrage gebunden wird:
  • full: Ganze Anfrage.
  • top_level_exclude: Bestimmte Felder (z. B. Trace-IDs) werden ignoriert.
  • top_level_include: Nur bestimmte Felder werden gebunden; fehlende Felder werden explizit attestiert (Schutz gegen schleichende Injection durch Middleware).
• Streaming-Integrität:
  • AEX verwendet eine Hash-Kette (Chunk Hash Chain) für Streams. Jeder JSON-Chunk wird gehasht und mit dem vorherigen verknüpft.
  • Zwei Beweis-Modi:
    1. Source-Stream Prefix Mode: Verifiziert Präfixe eines unveränderten Quell-Streams (Checkpoint-Attestation).
    2. Complete-Output Lineage Mode: Wenn der Output durch vertrauenswürdige Intermediaries umgewandelt, gepuffert oder neu formatiert wurde, wird keine Präfix-Verifizierung angeboten. Stattdessen wird eine signierte Kette von Transformationen (output_transforms) bereitgestellt, die vom Quell-Output zum finalen Output führt.
• Vertrauenswürdige Transformationen:
  • Request-Transforms: Signierte Belege (receipts) dokumentieren, wie Middleware die Anfrage sicher verändert hat (z. B. Prompt-Redaktion).
  • Output-Transforms: Signierte Belege dokumentieren, wie der Output verändert wurde (z. B. von Stream zu Objekt), wobei die output_mode (stream vs. non_stream) explizit in der Kette verfolgt wird.

3. Schlüsselbeiträge

1. Problemformulierung: Identifizierung der Dringlichkeit für eine API-grenzüberschreitende Verifizierung aufgrund von Shadow-API-Risiken.
2. Protokoll-Design (AEX): Eine nicht-invasive Erweiterung für JSON-APIs, die Request- und Output-Commitments, explizite Bindungsmodi und lineage-aware Metadaten einführt.
3. Spezifische Mechanismen:
   • Dual-Anker-Streaming-Hash-Kette.
   • Explizite Request-Transform-Ketten für vertrauenswürdige Intermediaries.
   • Ein Modell für Source-Output- und Output-Transform-Belege.
4. Sicherheits- und Privatsphärenanalyse: Detaillierte Betrachtung von Bedrohungsmodellen, Replay-Angriffen (via Nonces) und der Abgrenzung zu TEEs.
5. Referenz-Implementierung: Ein TypeScript-Prototyp mit einem Testbed (Gateway/Proxy/Provider), der Konformitätstests und Mikro-Benchmarks durchführt.

4. Ergebnisse und Evaluation

• Prototyp: Ein funktionsfähiger TypeScript-Prototyp wurde entwickelt, der OpenAI-kompatible Chat-Completions-APIs simuliert.
• Validierung:
  • 29 Unit-Tests, 25 Integrationstests und 6 Browser-End-to-End-Tests wurden erfolgreich durchgeführt.
  • Getestet wurden Szenarien wie Request-Binding, Transform-Ketten, Streaming-Checkpoints und Lineage-Verifizierung.
• Performance (Mikro-Benchmarks):
  • Die Overhead-Zeiten sind minimal. In einem nicht-streaming Szenario betrug die Gateway-Verifizierungszeit im Median 0,495 ms.
  • Bei komplexeren Szenarien (z. B. mit Transform-Ketten und Lineage) stieg die Verifizierungszeit auf ca. 1,5 ms an.
  • Die Latenz wird primär durch künstliche Verzögerungen im Simulator (für Streaming-Szenarien) dominiert, nicht durch die kryptografischen Operationen.
• Ergebnis: Das Protokoll ist implementierbar, ohne die API-Semantik zu brechen, und fügt nur einen vernachlässigbaren Overhead hinzu.

5. Bedeutung und Limitationen

Bedeutung:
AEX füllt eine kritische Lücke in der LLM-Sicherheit. Es bietet eine transaktionsbasierte Verifizierung, die unabhängig von der Modell-Identität (Fingerabdruck) oder der Hardware-Umgebung (TEE) funktioniert. Es ermöglicht es Clients und Audits, genau zu sehen:

• Ob die Antwort auf die gesendete Anfrage zurückgeht.
• Ob vertrauenswürdige Middleware die Anfrage oder Antwort verändert hat (und wie).
• Ob ein Stream manipuliert, abgeschnitten oder neu formatiert wurde.

Limitationen:

• Kein Beweis für Wahrheit: AEX beweist nicht, dass die Antwort faktisch korrekt ist oder dass keine versteckten Prompts existieren.
• Vertrauenswurzel: Das System ist nur so sicher wie der Aussteller (Issuer). Wenn der Issuer böswillig ist oder der Verifizierer den falschen Issuer vertraut, ist die Attestation wertlos.
• Keine Präfix-zu-Präfix-Transformation: In Version 1 kann ein verifizierter Präfix eines Quell-Streams nicht direkt in einen verifizierten Präfix eines transformierten Outputs umgewandelt werden; bei Transformationen muss auf die vollständige Output-Lineage gewartet werden.
• Lokale Messungen: Die Performance-Daten stammen aus einer lokalen Simulationsumgebung und nicht aus einer WAN-Produktionsumgebung.

Fazit:
AEX ist ein pragmatischer, deploybarer Ansatz, der die Integrität und Nachverfolgbarkeit (Provenance) von LLM-APIs sicherstellt, ohne die bestehenden Infrastrukturen grundlegend zu verändern. Es ist als komplementäre Schicht zu TEEs und Modell-Fingerabdrücken konzipiert, um die spezifische Lücke der „Request-to-Response"-Bindung an der API-Grenze zu schließen.