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.2.0; beschrieben: 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) — bei Veröffentlichung 8 von 8 Prüfungen bestanden (agentrust-trace-tests 0.5.1); mit 0.6.2: 15 Prüfungen, 12 bestanden, 3 übersprungen, Gruppen TR-ENV, TR-SIG, TR-POL, TR-APR
- 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/agentrust-io/integrations · litzki-systems-sovp, das Paket unter pypi.org/project/litzki-sovp-agentrust-bridge, zum Zeitpunkt dieses Beitrags Version 0.1.1, aktuell 0.2.0 (11.10.2026).
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 --record … --level 0 mit acht von acht bestandenen Prüfungen: Umgebungs-, Signatur- und Policy-Checks, alle PASS. Das ist der Stand bei Veröffentlichung mit agentrust-trace-tests 0.5.1. Version 0.6.2 der Prüfsuite bringt eine vierte Gruppe TR-APR für die Bewertung und zählt 15 Prüfungen: 12 bestanden, 3 übersprungen, 0 fehlgeschlagen.
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 --record record.json --level 0
# PASS — TR-ENV, TR-SIG, TR-POL, TR-APR (0.6.2: 15 Prüfungen, 12 bestanden, 3 übersprungen)
# Ein manipulierter Record scheitert am selben Befehl
trace-tests verify --record tampered.json --level 0
# TR-SIG FAIL — Exit-Code 1Einschränkung (29.10.2026): trace-tests verify --level 0 prüft die Signatur gegen den Schlüssel, den der Record selbst in cnf.jwk mitführt. Ein Record, den jemand mit einem fremden Schlüssel signiert, besteht diese Prüfung ebenfalls. Dass der Record vom erwarteten Absender stammt, zeigt erst die Prüfung gegen den vertrauten öffentlichen Schlüssel über agentrust_trace.verify_record. Records gelten 24 Stunden ab iat als frisch.
Was 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.
Was offen bleibt
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. Erteilt haben ihn die AgenTrust-Maintainer am 23.09.2026 nach eigener Reproduktion gegen 0.1.1 (PR #220).
Wo die Brücke steht
Die Brücke steht im öffentlichen AgenTrust-Marketplace, als einer von 57 Einträgen (Stand 29.10.2026). Im selben Katalog stehen die TRACE-Anbindungen, die das AgenTrust-Projekt für Claude Code, OpenAI Agents SDK, Google ADK und LangChain pflegt, und die Integrationen aus Microsofts Agent Governance Toolkit. Ein Eintrag beschreibt eine technische Integration, keine Empfehlung oder Partnerschaft.
Unabhängige Reproduktion von Version 0.2.0
Nachtrag (29.10.2026): Der folgende Wortlaut ist mit AgenTrust abgestimmt und steht hier unverändert im englischen Original.
The AgenTrust maintainers independently reproduced the SOVP to TRACE bridge (litzki-sovp-agentrust-bridge 0.2.0) on 12 October 2026 against agentrust-trace 0.11.0 and agentrust-trace-tests 0.6.2. The emitted record passed TRACE conformance at Level 0 (15 checks: 12 passed, 3 skipped, 0 failed) with a verified Ed25519 signature. The three skipped checks cover two optional fields and the affirming appraisal requirement, which applies from Level 1. The digest that points from the record to the SOVP verdict document matched an independent recomputation, and changing that digest in the signed record made signature verification fail. The reproduction covers Level 0 record conformance and signature integrity only. It makes no statement about the SOVP assessment, deployment security or agent behavior, and it establishes no partnership or endorsement.
Prüfprotokoll (Verification record): github.com/agentrust-io/integrations/pull/295#pullrequestreview-5494622603
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.
Wo das Paket gelistet ist
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.
Der nächste Schritt
Ist Ihre Infrastruktur noch nicht kryptografisch auf Layer 0 verankert, etabliert ein vollständiger SOVP-Scan die Baseline: 180+ deterministische Prüfungen, dreiwertiges Urteil, kein Produktivzugriff erforderlich. SOVP ist seit Oktober 2026 kein eigenes Produkt mehr. Die Prüfungen des Scanners nehme ich künftig in meine SEO-Berichte auf, als Grundlage für Maßnahmen: nach einem Beratungsgespräch, auf Ihren Wunsch oder auf meine Empfehlung.
Der Quellcode, das PyPI-Paket und die vollständige Konformitätsprüfung sind öffentlich einsehbar. Fragen zur Integration beantwortet Litzki Systems direkt.
