🤖 AI

Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation

Dieser Beitrag stellt eine zertifizierte Reinheitsarchitektur vor, die die Governance kognitiver Workflows stärkt, indem sie Laufzeitkonventionen durch strukturelle Grenzen ersetzt, und zwar durch eingeschränkte WebAssembly-Kompilierung, kryptografische Reinheitszertifikate und Remote-Attestierung, wodurch die Eliminierung adversarialer Umgehungen mathematisch nachgewiesen wird, während gleichzeitig ein vernachlässigbarer Laufzeit-Overhead gewährleistet bleibt.

Ursprüngliche Autoren: Alan L. McCann

Veröffentlicht 2026-05-06

📖 5 Min. Lesezeit🧠 Tiefgang

CC0 1.0

Ursprüngliche Autoren: Alan L. McCann

Originalarbeit unter CC0 1.0 der Gemeinfreiheit gewidmet (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie führen eine Hochrisiko-Küche, in der ein Team von Köchen (KI-Agenten) komplexe Mahlzeiten (kognitive Workflows) für VIP-Gäste zubereitet. Die Regeln sind streng: Die Köche dürfen das Menü planen und aufschreiben, welche Zutaten sie benötigen, ihnen ist jedoch strengstens untersagt, tatsächlich den Herd zu berühren, den Kühlschrank zu öffnen oder den Lieferfahrer anzurufen. Nur der Küchenchef (die „Governance-Pipeline") darf diese Aktionen ausführen.

Lange Zeit verließ sich die Küche auf eine einfache Regel: „Vertrauen Sie den Köchen, dass sie die Regeln einhalten." Die Küchenmanager würden die Kochbücher der Köche (statische Analyse) prüfen, um festzustellen, ob sie verbotene Anweisungen niedergeschrieben hatten. Wenn das Rezept sauber aussah, durfte der Koch arbeiten.

Das Problem: Die „Zauberkunst"-Lücke
Der Artikel erklärt, dass dieses „Vertrauen auf das Rezept"-System einen fatalen Fehler aufweist. Ein entschlossener, hinterhältiger Koch könnte Zauberkunststücke anwenden, um die Regeln zu umgehen, ohne sie im Kochbuch aufzuschreiben. Auf der spezifischen Küchenplattform, die sie verwenden (genannt BEAM/Erlang), könnte ein Koch Folgendes tun:

Sich als jemand anderes ausgeben: Eine Funktion kurz vor dem Aufruf über ihren Namen aufrufen und so verschleiern, dass sie ein gefährliches Tool aufrufen.
Neue Regeln im laufenden Betrieb schreiben: Während des Kochens einen neuen Befehl eingeben und damit effektiv ihr eigenes Rezept mitten in der Mahlzeit umschreiben.
Einen Leibwächter einstellen: Ein geheimes, vorab geschriebenes Tool (ein „NIF") laden, das alles tun kann, einschließlich des Öffnens des Kühlschranks.
Einen Boten schicken: Eine separate Person außerhalb der Küche spawnen, um Zutaten zu holen.
Das Kochbuch austauschen: Während des Kochens ein völlig anderes, gefährliches Kochbuch laden.

Da diese Tricks während der Arbeit des Kochs stattfinden, kann ein Blick auf das Kochbuch im Vorhinein (statische Analyse) sie nicht aufdecken. Es ist, als würde man versuchen, einen Zauberer zu stoppen, indem man ihm vor der Show die Taschen durchsucht; er könnte eine versteckte Karte haben, die er später zieht.

Die Lösung: Die „zertifizierte Reinheit"-Küche
Dieser Artikel schlägt ein radikales neues Küchendesign vor, das diese Zauberkunststücke physisch unmöglich macht, nicht nur gegen die Regeln.

1. Die neue Küche (WebAssembly-Sandbox)
Anstatt die Köche in der offenen Küche arbeiten zu lassen, arbeiten sie nun in einer transparenten, versiegelten Glasbox.

Keine Zauberkunststücke: In dieser Box existieren die Werkzeuge zum „Verstecken", „Umschreiben" oder „Einstellen von Leibwächtern" einfach nicht. Die Box ist so gebaut, dass der einzige Weg heraus durch eine einzige, verschlossene Tür führt.
Die Whitelist: Die Box verfügt nur über eine spezifische Liste von Werkzeugen, die sie verwenden kann (wie ein Taschenrechner, ein Notizblock und ein „Antragsformular"). Sie kann den Herd oder den Kühlschrank nicht berühren. Wenn ein Werkzeug nicht auf der Liste steht, hat die Box buchstäblich keinen Griff dafür.

2. Der Ausweis (Reinheitszertifikat)
Bevor ein Koch die Küche betritt, muss er einen speziellen Ausweis erhalten.

Der Beweis: Eine vertrauenswürdige Stelle prüft den Code des Kochs (das „Binary") und stellt sicher, dass er nur die erlaubten Werkzeuge verwendet.
Das Siegel: Sie versiegeln den Ausweis mit einem kryptografischen Siegel (wie einem Wachssiegel). Dieses Siegel beweist, dass diese spezifische Version des Codes des Kochs sauber ist.
Die Manipulationssicherheit: Wenn der Koch versucht, seinen Code auch nur geringfügig zu ändern (um ein geheimes Tool hinzuzufügen), bricht das Siegel. Der Ausweis wird ungültig. Man kann einen sauberen Ausweis von Koch A nicht nehmen und einem modifizierten Koch B geben.

3. Der Sicherheitsbeamte (Runtime-Gate)
Wenn ein Koch an der Küchentür eintrifft, prüft ein Sicherheitsbeamter den Ausweis.

Die Prüfung: Der Beamte verifiziert das Siegel, prüft, ob der Code mit dem Ausweis übereinstimmt, und bestätigt, dass die aufgeführten Werkzeuge noch auf der „erlaubten" Liste stehen.
Das Ergebnis: Wenn der Ausweis gültig ist, betritt der Koch die Küche. Wenn nicht, wird er sofort abgewiesen. Dies geschieht jedes einzelne Mal, bevor der Koch mit dem Kochen beginnt.

4. Der Küchenübergreifende Reisepass (Remote Attestation)
Was ist, wenn Koch A in Küche A arbeitet, aber Koch B aus Küche B einstellen muss?

Koch B bringt einen „Reisepass" (ein Attestationsprotokoll) mit, der beweist, dass er von seinem eigenen Küchen-Sicherheitsbeamten geprüft wurde und dass seine Küche denselben strengen Regeln folgt.
Küche A kann diesen Reisepass lesen und Koch B vertrauen, ohne den Quellcode von Koch B sehen oder einen Vertrag unterzeichnen zu müssen. Es ist ein maschinenlesbarer Vertrauensnachweis.

Warum dies wichtig ist (Die Ergebnisse)
Der Artikel beweist mathematisch, dass dieses System funktioniert:

Keine Lücken: Da die „Zauberkunststücke" (Umgehungsklassen) strukturell in der neuen Küche fehlen, kann ein hinterhältiger Koch sie buchstäblich nicht ausführen. Es ist nicht so, dass sie erwischt werden; es ist so, dass sie nicht geschehen können.
Schnell: Die Prüfung des Ausweises dauert weniger als ein Wimpernschlag (etwa 40 Mikrosekunden). Die zusätzliche Zeit, die es zum Zubereiten einer Mahlzeit hinzufügt, beträgt weniger als 0,4 % der Zeit, die es dauert, auf einen Lieferwagen zu warten.
Vertrauenslos: Sie müssen dem Koch, dem Küchenmanager oder der anderen Küche nicht vertrauen. Sie müssen nur der Mathematik hinter dem Siegel und dem Design der Glasbox vertrauen.

Zusammenfassung
Der Artikel verlagert die Governance von einem Schild „Bitte nicht stehlen" (das darauf angewiesen ist, dass Menschen Regeln befolgen) zu einer Wand „Sie können physisch nicht stehlen" (die auf der Struktur des Gebäudes beruht). Er verwandelt ein Versprechen in eine mathematische Garantie und stellt sicher, dass KI-Agenten planen und denken können, aber niemals heimlich außerhalb der Regeln handeln können.

Technisches Fazit: Zertifizierte Reinheit für kognitive Workflow-Executor

1. Das Problem: Die Reinheitslücke in kognitiven Workflows

Kognitive Workflow-Systeme (die KI-Inferenz, Werkzeugnutzung und Schlussfolgerungen orchestrieren) operieren zunehmend in hochriskanten Domänen. Vorherige Arbeiten (McCann [2026e]) etablierten eine dreischichtige Governance-Architektur, die Governance-Vollständigkeit, Provenienz-Vollständigkeit und die Unmöglichkeit ungeregelter Effekte garantiert. Diese Sicherheitstheoreme beruhten jedoch auf einer kritischen Prämisse: der Reinen-Modul-Einschränkung, die verlangt, dass Executor-Module keine I/O-Effekte ausführen dürfen und nur deklarative Direktiven zurückgeben können.

In der vorherigen Implementierung wurde diese Einschränkung durch statische Analyse des Modul-Importgraphen auf der BEAM-Virtual Machine (Erlang/OTP) durchgesetzt. Obwohl dies stärker war als eine konventionsbasierte Governance, ist dieser Mechanismus gegen adversarische Umgehungen unzureichend. Die dynamischen Features der BEAM erlauben fünf distincte Klassen von Umgehungen, die eine statische Analyse nicht zuverlässig verhindern kann:

Dynamische Dispatch: Verwendung von :erlang.apply/3 zum Aufruf beliebiger Funktionen ohne statische Imports.
Code-Evaluation: Verwendung von Code.eval_string/1 zur Ausführung beliebigen Codes zur Laufzeit.
Native Implemented Functions (NIFs): Laden von Shared Libraries mit uneingeschränktem Systemzugriff.
Ports: Starten externer Prozesse via :erlang.open_port/2.
Dynamisches Modul-Laden: Laden beliebigen Bytecodes zur Laufzeit via :code.load_binary/3.

Aufgrund des Riceschen Theorems kann keine statische Analyse die nicht-triviale semantische Eigenschaft „keine I/O-Effekte" für alle möglichen Programme entscheiden. Eine sounde Überapproximation würde die meisten legitimen, idiomatischen Elixir-Code ablehnen. Dies erzeugt eine Reinheitslücke: Das formale Modell geht von Reinheit aus, doch der Durchsetzungsmechanismus (statische Analyse) kann sie strukturell gegen einen entschlossenen Angreifer nicht garantieren.

2. Methodik: Von der Erkennung zur strukturellen Verhinderung

Dieser Artikel schlägt eine Architektur zertifizierter Reinheit vor, die die reine Modul-Einschränkung von einer durch Analyse durchgesetzten Konvention in eine strukturelle Fähigkeitsgrenze umwandelt, die durch die Ausführungsumgebung erzwungen wird. Die Methodik stützt sich auf vier Kernmechanismen:

A. Eingeschränktes Kompilierungsziel (WebAssembly)

Executors werden auf ein eingeschränktes WebAssembly (WASM)-Ziel kompiliert. Das WASM-Fähigkeitsmodell wird genutzt, um alle fünf BEAM-Umgebungsklassen strukturell zu eliminieren:

Keine dynamische Dispatch: WASM verfügt über keine Anweisungen, um Funktionsaufrufe über Laufzeit-Zeichenketten- oder Atom-Namen aufzulösen; Aufrufe sind auf statische Indizes in einer Funktionstabelle beschränkt.
Keine Code-Evaluation: WASM führt vorkompilierten Bytecode aus; es gibt keinen Mechanismus, um zur Laufzeit neuen Code zu generieren oder zu laden.
Keine NIFs/Ports: WASM-Module laufen in einer sandgeboxten VM ohne Zugriff auf Host-Dateisysteme, Shared Libraries oder Prozessstart.
Kein dynamisches Laden: Die Modul-Instanziierung wird vollständig vom Host kontrolliert; Module können keine anderen Module laden.

B. Die Host-Funktions-Whitelist ( $W$ )

Das WASM-Modul kann nur Funktionen aufrufen, die explizit in seinem Import-Abschnitt deklariert sind. Diese Imports sind auf eine endliche, enumerierte Whitelist ( $W$ ) beschränkt:

$W_{data}$ : Reine Datenoperationen (Speicherverwaltung, Zeichenkettenmanipulation, Arithmetik, JSON-Serialisierung, Kontext-Lesen).
$W_{dir}$ : Direktiv-Konstruktoren (Funktionen, die Datenstrukturen aufbauen, die beabsichtigte Effekte repräsentieren, z. B. directive_http_request, diese aber nicht ausführen).
Ausschluss: WASI (WebAssembly System Interface)-Imports, die Effektfähigkeiten gewähren, sind explizit ausgeschlossen.

C. Reinheitszertifikate

Ein Reinheitszertifikat ist ein kryptografisches Beweisartefakt, das einen Executor-Binary an seine Reinheitsklassifizierung bindet.

Struktur: Enthält den SHA-256-Hash des Executor-Binaries, den Hash des Reinheitsbeweises (Importliste + Klassifizierung) und eine Ed25519-Signatur über diesen Hashes.
Integrität: Aufgrund der Kollisionsresistenz von SHA-256 und der Unfälschbarkeit von Ed25519 kann ein Zertifikat nicht auf ein modifiziertes Artefakt übertragen werden.

D. Laufzeit-Verifizierungs-Gate

Bevor ein Executor in die Governance-Pipeline eintritt, führt ein Verifizierungs-Gate Folgendes durch:

Signatur-Verifizierung: Validierung der Ed25519-Signatur.
Artefakt-Bindung: Bestätigung, dass der Binary-Hash mit dem Zertifikat übereinstimmt.
Unabhängige Beweis-Ableitung: Parsen des Import-Abschnitts des WASM-Binaries de novo und Verifizierung, dass er mit dem behaupteten Reinheitsbeweis gegen die aktuelle Whitelist übereinstimmt.
Klassifizierungs-Validierung: Sicherstellung, dass alle Imports als rein klassifiziert sind.

Nur Executors, die dieses Gate passieren, werden instanziiert. Dieses Gate fungiert als strukturelle Vorbedingung und stellt sicher, dass kein Executor ohne ein gültiges Reinheitszertifikat ausgeführt werden kann.

3. Hauptbeiträge

Formales Bedrohungsmodell: Eine rigorose Charakterisierung der fünf BEAM-Umgebungsklassen und der theoretischen Grenzen der statischen Analyse (Ricesches Theorem) in diesem Kontext.
Strukturelle Reinheit durch Konstruktion: Ein Beweis (Theorem 4.5), dass die Kompilierung auf das eingeschränkte WASM-Ziel die reine Modul-Einschränkung durch Konstruktion erfüllt, unabhängig vom Code-Inhalt des Executors.
Eliminierung von Umgehungen: Formale Beweise (Theorem 5.5), dass jede der fünf BEAM-Umgebungsklassen in der eingeschränkten WASM-Umgebung strukturell unmöglich ist.
Kryptografische Attestierung: Ein Schema für Reinheitszertifikate und Remote-Attestierungs-Records, das eine portable, organisationsübergreifende Verifizierung der Executor-Reinheit ohne Zugriff auf den Quellcode ermöglicht.
Definition der Trusted Computing Base (TCB): Eine explizite Definition der fünf Komponenten, die für die Garantie erforderlich sind (WASM-Laufzeit, Host-Funktionen, Whitelist, Verifizierungs-Gate, Direktiv-Interpreter), wodurch die Vertrauensfläche von unbeschränktem Executor-Code auf eine begrenzte, überprüfbare Menge reduziert wird.
Staffelte Vertrauensstufen: Eine Implementierungsarchitektur, die drei Stufen unterstützt (Verifizierte Reinheit, Statische Analyse, Experimentell), um eine schrittweise Adoption zu ermöglichen.

4. Ergebnisse und Evaluation

Die Architektur wurde an vier implementierten Executoren (Rust-basiert, kompiliert zu WASM) evaluiert, die auf einem Apple M-Serie-Prozessor mit dem Wasmtime-JIT-Backend liefen.

Verifizierungs-Latenz: Das Verifizierungs-Gate benötigt 39–42 µs (Median) für Produktions-Executors. Mit hash-basiertem Caching nähert sich die amortisierte Kosten für wiederholte Aufrufe Null an.
Laufzeit-Overhead: Der vollständige Planzyklus (Instanziierung, Ausführung, Deserialisierung) wird in 256–398 µs abgeschlossen. Dies stellt einen Overhead von <0,4% bei einer 100 ms HTTP-Anfrage und <0,05% bei einem typischen 800 ms LLM-Aufruf dar.
Determinismus: Über 40 wiederholte Aufrufe mit identischen Eingaben wurden keine Abweichungen beobachtet, was die deterministische Natur der WASM-Ausführungsumgebung bestätigt.
Zertifikatsgröße: Zertifikate sind kompakt (~1,3 KB) und liegen gut innerhalb der Bandbreitenbudgets.
Korrektheit: Alle Executors erzeugten die erwarteten Direktiv-Formate, und das System lieferte über alle Durchläufe hinweg byte-identische Ausgaben.

5. Bedeutung und Behauptungen

Der Artikel behauptet einen fundamentalen Wandel im erkenntnistheoretischen Status von Governance-Garantien:

Von der Erkennung zur Verhinderung: Frühere Ansätze verließen sich darauf, bekannte Umgangsmuster durch statische Analyse zu erkennen. Diese Architektur verhindert Umgehungen, indem sie effekteerzeugende Fähigkeiten strukturell abwesend macht.
Stärkung bestehender Theoreme: Die Sicherheitstheoreme aus McCann [2026e] (Governance-Vollständigkeit, Provenienz-Vollständigkeit, Keine ungeregelten Effekte) bleiben formal identisch. Ihre grundlegende Prämisse wird jedoch nun mechanisch entladen, anstatt angenommen zu werden. Die Garantie beruht nun auf den mathematischen Eigenschaften des WASM-Fähigkeitsmodells und kryptografischer Primitive (SHA-256, Ed25519) statt auf den Grenzen eines statischen Analyzers.
Portabler Trust: Durch die Umwandlung lokaler Reinheitsbeweise in portable Attestierungs-Records ermöglicht die Architektur eine organisationsübergreifende Governance-Komposition, sodass Organisation A die Reinheit der Executors von Organisation B kryptografisch verifizieren kann, ohne den Quellcode zu prüfen.

Der Artikel weist ausdrücklich darauf hin, dass dies kein mechanisierter Beweis im Sinne von Rocq oder Lean ist (was für die zugrundeliegende Governance-Logik in Begleitpapieren vorbehalten ist), sondern eine strukturelle Garantie, die zur Laufzeit verifiziert wird. Der Beitrag ist die Reduktion der Vertrauensfläche von „alle Executor-Code" auf eine kleine, explizit definierte Trusted Computing Base.