Offline-Überprüfung von AI Agent Receipts
Überprüfen Sie die Quittungen von KI-Agenten, ohne der Herstellerdatenbank zu vertrauen, indem Sie Schemata, kanonische Nutzlast, Ausstellerschlüssel, Signaturen, Bindungs- und Beweislimits überprüfen.
Die Offline-Verifizierung eines KI-Agenten-Belegs überprüft einen tragbaren Datensatz, ohne die Live-Transaktionsdatenbank des Herstellers aufzurufen. Der Verifizierer validiert Schema, kanonische Nutzlast, Vertrauen des Emittenten, Schlüsselstatus, Unterschrift und verbindliche Anforderung. Externe Fakten wie Abwicklung oder Lieferung bleiben nur so stark wie die genannten Beweisquellen.
AI Agent Audit Trails Der nachfolgende Prüfervertrag ist absichtlich enger gefasst: Was kann von einem tragbaren Paket aus überprüft werden, und was muss unbekannt bleiben.
Rückmeldungen, nicht ein grünes Abzeichen
type Finding = {
check: string;
result: 'pass' | 'fail' | 'unknown';
detail: string;
};
type VerificationReport = {
receiptId: string;
integrity: 'valid' | 'invalid' | 'unknown';
findings: Finding[];
unresolvedEvidence: string[];
};
Ein unbekannter oder nicht verfügbarer historischer Schlüssel ist unknownEine schlechte Signatur ist invalidEine gültige Unterschrift macht ungelöste Ergebnisbeweise nicht zu einem Pass.
Verifizieren in einer festen Reihenfolge
- Parse unter strengen Größen- und Rekursionsgrenzen.
- Validieren Sie die deklarierte Schemaversion.
- Lösen Sie den Emittenten und erlauben Sie die Verifizierungsmethode im Rahmen einer Vertrauensrichtlinie.
- Überprüfen Sie den Schlüsselstatus zum Empfangszeitpunkt, einschließlich Rotations- und Kompromissregeln.
- Erstellen Sie die kanonische Signatur Payload.
- Überprüfen Sie die Unterschrift.
- Berechnen Sie die Anforderung, die Autorität, die Richtlinie und die Genehmigung, wenn Quellobjekte bereitgestellt werden.
- Fehlende externe Beweise gesondert melden.
RFC 8785 definiert die JSON-Kanonisierung, die für wiederholbares Hashing geeignet ist, wenn sie innerhalb eines vollständigen Profils verwendet wird.
Manipulationsvorrichtungen veröffentlichen
| Befestigung | Erwartetes Ergebnis |
|---|---|
| unbearbeiteter bekannter Empfang | Unterschriftenpass |
| Geänderter Betrag | Signatur Fail oder Request Digest Fail |
| unbekannter Emittent | Unbekanntes Vertrauensergebnis |
| Schlüssel nach Ereignis widerrufen | Ergebnis folgt erklärter historischer Richtlinie |
| fehlender Vergleichsnachweis | Integrität kann passieren, Ergebnis bleibt unbekannt |
| Nicht unterstützte Schemaversion | explizites nicht unterstütztes Ergebnis |
Sprachübergreifende Vorrichtungen sind wichtig, da Unterschiede bei Anzahl, Unicode und Schlüsselbestellung ansonsten korrekte Implementierungen stören können.
Vertrauenspolitik explizit machen
Die Signaturverifizierung beantwortet eine mathematische Frage. Vertrauen erfordert mehr: welche Emittenten akzeptiert werden, welche Algorithmen und Schlüsselgrößen erlaubt sind, wie historische Kompromisse gehandhabt werden und ob ein Verifizierer Metadaten aus dem Netzwerk abrufen kann. Vertrauensmaterial für die Offline-Nutzung verpacken oder anheften, anstatt stillschweigend eine Fernsuche durchzuführen.
Die Prüfstelle sollte die Verwechslung von Algorithmen, doppelte JSON-Schlüssel, unbegrenzte Verschachtelung, unbekannte kritische Felder und eine Quittung, deren deklarierter Emittent nicht mit der Prüfmethode übereinstimmt, ablehnen.
Ein einziges grünes "verifiziertes" Abzeichen verbirgt diese Unterscheidung und lädt die Leser ein, auf die Wahrheit des Ereignisses zu schließen.
Versionshalterungen mit Schema und Signaturprofil: Behalten Sie frühere Gerätesätze bei, damit die Schlüsselrotation oder ein Bibliotheksupdate die historische Verifizierung nicht unbemerkt unterbrechen kann.
Verwendung der Prüfpfadarchitektur für die Ausgabe und Blockchain Proof versus Quittung für Assurance Borders. OATI Public Lookup und Eingangsdokumentation Entwickler-Vorschau-Verifizierungspfade freilegen.
Die öffentliche Konformitätsarbeit von OATI läuft nicht auf eine abgeschlossene unabhängige kryptographische Überprüfung oder den Nachweis hinaus, dass ein Einsatz keine Umgehung der Durchsetzung aufweist.
Überprüfungsentscheidungen der Prüfstelle
Bei der strengen Offline-Überprüfung sollten Metadaten, Schlüssel, Schemata und Widerrufsnachweise für den verpackten oder vorab vertrauenswürdigen Emittenten verwendet werden. Ein netzwerkfähiger Modus kann Referenzen auflösen, ändert jedoch das Bedrohungs- und Reproduzierbarkeitsmodell.
Historische Schlüsselpolitik braucht effektive Rotations- und Kompromisszeiten. Ein ausgeschiedener Schlüssel kann normalerweise für frühere Quittungen akzeptabel bleiben. Ein Kompromiss kann einen Zeitraum entsprechend der Richtlinie ungültig machen oder herabstufen. Der Prüfer muss angeben, welche Regel er angewendet hat, anstatt jeden derzeit widerrufenen Schlüssel gleich zu behandeln.
Canonicalization erzeugt wiederholbare Bytes unter einem ausgewählten Profil. Es validiert keine Schemata, Geschäftsbedeutung oder Quellwahrheit. Parse unter strengen Größen- und Tiefengrenzen, lehne doppelte Schlüssel ab, validiere Typen und Grenzen und dann canonicalize. Halten Sie sprachübergreifende Vorrichtungen für Zahlen, Unicode und Feldbearbeitung.
Kritische Erweiterungen definieren. Ein unbekanntes kritisches Feld sollte nicht unterstützt oder ungültig sein, kein teilweises grünes Ergebnis. Nichtkritische signierte Felder entsprechend dem Profil beibehalten. Niemals ein unbekanntes Feld verwerfen und eine andere Nutzlast als die des Emittenten überprüfen.
Ein QR-Code kann eine Quittung oder einen Digest-and-Retrieval-Bezug tragen. Er ist keine unabhängige Überprüfung, wenn er nur die aktuelle Website des Emittenten öffnet. Der Prüfer benötigt weiterhin die Nutzlast, das Vertrauensmaterial, das Signaturprofil und den Quellennachweis. Bieten Sie ein tragbares Paket für Untersuchungen an, die nicht von der Verfügbarkeit des Emittenten abhängen können.
Prüfen Sie valide, veränderte, mehrdeutige und Ressourcenerschöpfungsvorrichtungen über Implementierungen hinweg, vergleichen Sie strukturierte Ergebnisse anstelle von einem booleschen, Fuzz-Parser und erhalten Sie eine unabhängige kryptografische Überprüfung für ein Produktionsprofil, zeigen Sie Sicherheit pro Anspruch: Integrität kann passieren, während Autorität oder Ergebnis unbekannt bleiben.
Eigene Identität des Prüfers verpacken. Implementierungsname und -version, Fixture oder Policy Bundle, Verifizierungszeit und ob der Netzwerkzugang erlaubt war. Zwei Tools können unterschiedliche Ergebnisse liefern, weil das eine einen Emittenten oder ein Schema kennt, das andere nicht. Ohne diesen Kontext kann ein späterer Prüfer einen Umweltunterschied als kryptographische Meinungsverschiedenheit behandeln.
Schutz des Verifizierungsberichts davor, zu einem stärkeren Anspruch zu werden als die Quittung; wenn kein Nachweis des Anbieters vorliegt, sagen Sie, dass das Ergebnis auch bei der Unterschrift ungelöst ist und fordern Sie einen verbindlichen Pass an; wenn historische Widerrufsdaten unvollständig sind, bewahren Sie unknownDas disziplinierte Ergebnis ist manchmal weniger befriedigend als ein grünes Abzeichen, aber es ist nützlicher während eines Audits oder Streits.
Geben Sie den Betreibern einen maschinenlesbaren Bericht und eine klare Erklärung der fehlgeschlagenen Überprüfungen. Die Erklärung sollte aus stabilen Verifier-Codes stammen, nicht aus einem Modell, das zur Interpretation willkürlicher kryptographischer Fehler aufgefordert wird. Halten Sie den Rohbefund, das betroffene Feld und die Vertrauensrichtlinie zur Verfügung, damit eine andere Implementierung das Ergebnis reproduzieren kann.
Verifier-Ergebnisse und Vertrauensrichtlinien entwickeln sich, auch wenn die signierte Eingabe dies nicht tut. Behalten Sie beide Versionen, damit ein alter Bericht interpretiert werden kann, ohne ihn nach den heutigen Regeln erneut auszuführen.