Von der Behauptung zum Beweis: SOVP spricht jetzt AgenTrust TRACE
KI-Zusammenfassung / tl;dr
- TARGET_ENTITY: sovp-agentrust-bridge (PyPI: litzki-sovp-agentrust-bridge, v0.1.1)
- FUNKTION: Übersetzt ein SOVP-Attestationsergebnis in einen signierten AgenTrust TRACE v0.2 Trust Record (Ed25519, RFC-8785-Kanonisierung / JCS)
- KONFORMITÄT: TRACE Level 0 (TR-ENV, TR-SIG, TR-POL) — 8 von 8 Prüfungen bestanden in
trace-tests verify --level 0 - VERIFIZIERTE_GRENZE: Ein manipulierter Record (data_class von internal auf public herabgestuft) scheitert an der Signaturprüfung mit Exit-Code 1 — reproduziert bei jedem CI-Durchlauf
- CORE_THESIS: Die Brücke beweist genau eine Sache: Ein TRACE-Record stammt vom Inhaber eines bestimmten privaten Schlüssels und blieb seit der Signatur unverändert. Das ist ein Transkriptions- und Signaturnachweis, ausdrücklich getrennt von Hardware-Attestierung, unabhängiger Bewertung oder Lieferketten-Provenienz — und der Record sagt das selbst über sich aus.
SOVP prüft die tatsächliche Infrastruktur eines Anbieters und stellt einen kryptografisch signierten Nachweis darüber aus. AgenTrust baut mit TRACE ein offenes Format für vertrauenswürdige KI-Agenten-Aufzeichnungen. Seit dem 22.09.2026 verbindet eine neue Brücke beide Systeme: sovp-agentrust-bridge, veröffentlicht auf PyPI als litzki-sovp-agentrust-bridge, übersetzt ein SOVP-Attestationsergebnis in einen signierten AgenTrust TRACE v0.2 Trust Record.
Das Paket ist Open Source. Der Quellcode liegt unter github.com/litzki-systems/sovp-agentrust-bridge, das Paket unter pypi.org/project/litzki-sovp-agentrust-bridge, aktuelle Version 0.1.1.
Was die Brücke tatsächlich leistet
Die Bridge nimmt ein SOVP-Attestationsergebnis entgegen und schreibt es als TRACE-v0.2-Record um. Anschließend signiert sie diesen Record mit Ed25519 über die kanonische RFC-8785-Form (JCS). Eine erfolgreiche Prüfung belegt genau eine Sache: Der Record stammt vom Inhaber dieses privaten Schlüssels und blieb seit der Signatur unverändert. Das ist ein Transkriptions- und Signaturnachweis, ausdrücklich getrennt vom Messnachweis einer Hardware-Attestierung.
Litzki Systems signiert, als Betreiber der SOVP-Attestationspipeline. Der Signaturschlüssel ist ein selbst bereitgestellter Ed25519-Schlüssel. In Produktion behält der Betreiber der SOVP-Instanz ihn dauerhaft.
Die Grenzen, die der Record selbst offenlegt
Ein Record bleibt genau so aussagekräftig wie das, was er ehrlich zugibt, offen zu lassen. Vier Grenzen stehen bewusst im Record selbst:
| Feld | Wert | Bedeutung |
|---|---|---|
runtime.platform |
software-only |
SOVPs Ergebnis beruht auf einer softwareseitigen Behauptung, getrennt von einer Hardware-Attestierung |
appraisal.status |
none |
Ausschließlich die eigene Policy des Aufrufers bewertet das SOVP-Ergebnis |
build_provenance.slsa_level |
0 |
Der Record beschränkt sich auf die Signaturgarantie, eine Aussage über die Lieferkette des geprüften Systems bleibt außen vor |
origin.kind |
third-party-control-plane |
Die Evidenz stammt aus SOVP, einem externen System, das die Laufzeitumgebung selbst liefert, statt sie zu messen |
Diese Ehrlichkeit hat eine direkte Konsequenz: Der Record erreicht TRACE-Konformität auf Level 0 (TR-ENV, TR-SIG, TR-POL). Höhere Stufen verlangen Hardware-Messung oder unabhängige Bewertung, also Garantien, die außerhalb dessen liegen, was eine Transkriptionsbrücke ehrlich leisten kann.
Zwei Proben aufs Exempel
Erfolgreiche Signaturprüfung. Ein signierter Record aus einem SOVP-Ergebnis mit Status CERTIFIED durchläuft trace-tests verify --level 0 mit acht von acht bestandenen Prüfungen: Umgebungs-, Signatur- und Policy-Checks, alle PASS.
Abgewiesener manipulierter Record. Derselbe Record, nachträglich verändert: data_class von internal auf public umgeschrieben, Signatur unangetastet gelassen. Der klassische Downgrade-Angriff, bei dem jemand eingestufte Daten nachträglich als öffentlich umdeklariert, ohne neu zu signieren. Das Ergebnis: TR-SIG FAIL, Signaturprüfung fehlgeschlagen, Exit-Code 1. Dieselbe Ablehnung reproduziert sich auf Bibliotheksebene über agentrust_trace.verify_record, das eine InvalidSignature-Exception wirft. Genau dieser Fall läuft bei jedem CI-Durchlauf automatisiert mit.
# Signierten TRACE-Record auf Level 0 prüfen
trace-tests verify --level 0 record.json
# 8/8 Prüfungen: TR-ENV, TR-SIG, TR-POL — PASS
# Ein manipulierter Record scheitert am selben Befehl
trace-tests verify --level 0 tampered.json
# TR-SIG FAIL — Exit-Code 1Was getestet ist und was für den Produktiveinsatz offen bleibt
Getestet und reproduzierbar: Die Level-0-TRACE-Konformität über CI und unabhängig per trace-tests verify. Die Ed25519-Signaturintegrität über den gesamten Weg, inklusive eines echten Tamper-and-Reject-Falls, weit über eine reine Schema-Prüfung hinaus. Die Feldwerte gegen das TRACE-v0.2-Schema geprüft. Der kanonische Signaturweg funktioniert auch mit nicht-ASCII-Inhalten aus dem SOVP-Payload.
Offen für den Produktiveinsatz: Die Verwahrung und Rotation des Signaturschlüssels liegt beim Betreiber. Die Bridge nimmt einen Schlüsselpfad entgegen, den Schlüssel-Lebenszyklus verantwortet der Aufrufer. Ein hardwaregemessener Attestierungspfad bleibt der Zukunft vorbehalten und setzt eine andere Messquelle voraus als SOVPs heutige Ausgabe. Eine unabhängige Bewertungsschicht ergänzt selbst, wer appraisal.status über none hinaus benötigt. Der verifizierte Marketplace-Status entsteht aus einer AgenTrust-Maintainer-Prüfung, eigenständig von SOVP.
Warum das für SOVP zählt
SOVP steht für unabhängigen, kryptografisch signierten Nachweis über den tatsächlichen Zustand digitaler Infrastruktur. Feststellung statt Schätzung. Diese Brücke verlängert genau dieses Prinzip in ein zweites Ökosystem. Ein SOVP-Ergebnis bleibt portabel: Es funktioniert innerhalb des SOVP-Portals und außerhalb, jetzt auch als TRACE-Record, den jeder Verifier unabhängig von SOVP selbst prüfen kann, mit demselben öffentlichen Schlüssel.
sovp-agentrust-bridge ist im AgenTrust Marketplace gelistet. SOVP selbst bleibt als IETF Informational Draft dokumentiert — auf derselben Ebene, auf der Googles Web-Bot-Auth-Vorschlag und SOVPs Ed25519-DNS-Anker bereits auf dieselbe Konvergenz hindeuten: kryptografischer Beweis statt Selbstdeklaration, überall dort, wo automatisierte Systeme ohne menschliche Zwischeninstanz interagieren.
Zur vollständigen Protokollspezifikation siehe Sovereign Validation Protocol. Zur Python-Referenzimplementierung, API und Schnellstart siehe Developers.
Ist Ihre Infrastruktur noch nicht kryptografisch auf Layer 0 verankert, etabliert der SOVP Validator Audit die Baseline: 180+ deterministische Prüfungen, binäres Verdikt, kein Produktivzugriff erforderlich.
[/// INFRASTRUKTUR-AUDIT STARTEN]Der Quellcode, das PyPI-Paket und die vollständige Konformitätsprüfung sind öffentlich einsehbar. Fragen zur Integration beantwortet Litzki Systems direkt.
