AI Agent Audit Trails: Logs, Quittungen und Verifizierung

Aktualisiert am 27. September 2026: Ausführbare Referenzbeispiele und Kontrollkriterien hinzugefügt. Unabhängige Sicherheitsüberprüfung bleibt vor Veröffentlichung erforderlich.

15 Minuten lesen · Rezensiert 11. August 2026 · Sicherheitsexperte Überprüfung vor Veröffentlichung erforderlich

Ein AI-Agent-Audit-Trail ist ein dauerhafter Datensatz, der die verifizierte Identität und die delegierte Autorität eines Agenten mit der genauen Anforderung, der Richtlinienentscheidung, dem Ausführungsversuch und dem beobachteten Ergebnis verbindet. Betriebsprotokolle bleiben für das Debuggen und Überwachen notwendig. Signierte Aktionsquittungen fügen stabile Semantik, Integritätsschutz und tragbare Verifizierung hinzu. Ein vertretbarer Audit-Trail verwendet beides und gibt klar an, was jeder Datensatz beweisen kann.

Dieser Leitfaden richtet sich an Plattform-, Sicherheits- und Audit-Engineering-Teams, die Folgeaktionen der Agenten rekonstruieren müssen, ohne sich auf ein Modell-Transkript oder eine veränderliche Datenbank zu verlassen.

Was gehört in einen AI Agent Audit Trail?

Der Trail sollte diese Fragen beantworten, ohne das Modell zu bitten, sich nach der Veranstaltung zu erklären:

• Welcher Agent handelte und welche Organisation war verantwortlich?
• Welche delegierte Befugnis und Policy-Version wurde bewertet?
• Welche genaue Anfrage wurde genehmigt, abgelehnt oder zur Genehmigung geschickt?
• Welches geschützte System hat die Aktion erhalten?
• Was hat das System damals berichtet?
• Hat eine spätere Abrechnung, Erfüllung, Umkehr oder Abstimmung das Ergebnis verändert?
• Kann ein Prüfer veränderte oder fehlende Beweise erkennen?

Ein Chat-Transkript kann zeigen, wie der Agent seine Absicht beschrieben hat. Es stellt nicht die Anfrage fest, die den Zahlungsanbieter erreicht hat, das aktive Mandat oder den Richtliniencode, der ausgeführt wurde. agent_action=success ist noch schwächer, weil es mehrere Zustände zu einem Label zusammenbricht.

Protokolle, Traces, Quittungen und Ergebnisaufzeichnungen

Diese Aufzeichnungen dienen verschiedenen Betreibern und Aufbewahrungsbedürfnissen.

Das Logdatenmodell von OpenTelemetry bietet Felder wie Timestamp, ObservedTimestamp, TraceId, SpanId, Schweregrad und strukturierte Attribute: Diese Felder machen Protokolle portabel und korrelierbar. Das OpenTelemetry Logs Data Model Diese stärkere Rolle erfordert ausdrückliche Autoritäts-, Anforderungs- und Verifizierungssemantik.

Quittungen ersetzen keine Protokolle. Ein Ermittler kann eine Quittung verwenden, um die Transaktion, Richtlinie und externe Referenz zu identifizieren, und dann Tracs und Protokolle verwenden, um einen Timeout oder eine Wiederholung zu finden. Umgekehrt kann eine Trace-ID in der Quittung geschützte Beweise mit operativen Details verbinden, ohne sensible Nutzlasten in den tragbaren Datensatz zu kopieren.

Definieren von Beweisansprüchen, bevor Sie Felder definieren

Beginnen Sie mit der Auflistung, welche Ansprüche ein Verifier benötigt und welches System jeden einzelnen unterstützen kann.

Eine Unterschrift stellt die Integrität fest, die Unterschriftenzuordnung unter dem verifizierten Schlüssel und die Bescheinigung des Emittenten; sie beweist nicht, dass eine physische Lieferung stattgefunden hat, dass eine Antwort des Anbieters wahrheitsgemäß war oder dass es keine Umgehung der Durchsetzung gab; unilateral, counterparty_signed oder corroborated nur wenn ihre Prüfregeln festgelegt sind.

Erhalt einer anforderungsgebundenen Aktion

Die Quittung sollte die geschützte Transaktion binden und nicht eine menschliche Zusammenfassung, die danach geschrieben wurde.

type ActionReceipt = {
  version: 1;
  receiptId: string;
  transactionId: string;
  issuer: {
    organizationId: string;
    agentId?: string;
    verificationMethod: string;
  };
  authority: {
    passportDigest: string;
    mandateDigest: string;
    policyDigest: string;
    approvalDigest?: string;
  };
  request: {
    action: string;
    resource: string;
    destination: string;
    canonicalDigest: string;
    idempotencyKey: string;
  };
  decision: {
    result: 'allow' | 'deny' | 'approval_required';
    reasonCodes: string[];
    decidedAt: string;
  };
  execution?: {
    status:
      | 'not_attempted'
      | 'submitted'
      | 'accepted'
      | 'rejected'
      | 'uncertain';
    externalReference?: string;
    observedAt: string;
  };
  evidenceRefs: Array<{
    type: string;
    digest: string;
    uri?: string;
  }>;
  assurance: 'unilateral' | 'counterparty_signed' | 'corroborated';
  proof: {
    createdAt: string;
    signature: string;
  };
};

Dies ist ein illustratives Schema, nicht das wörtliche OATI-Empfangsschema. Der Request Digest sollte normalisierte Aktionsparameter, Ressource, Gegenpartei, Ziel, kommerzielle Bedingungen und jeden Kontext abdecken, der die Autorisierung ändert. Der Policy Digest identifiziert das bewertete Artefakt. Ein Approval Digest bindet eine menschliche Entscheidung an dieselbe kanonische Anfrage.

Zwei gültige JSON-Serialisierungen können sich in Schlüsselreihenfolge, Zahlen oder Unicode-Darstellung unterscheiden. RFC 8785 definiert das JSON Canonicalization Scheme für wiederholbares Hashing und Signieren. Veröffentlichen Sie sprachübergreifende Vorrichtungen für Ihr ausgewähltes Signaturprofil.

Vermeiden Sie Rohkartendaten, Anmeldeinformationen, private Aufforderungen und vollständige Kundendatensätze in tragbaren Quittungen. Verwenden Sie minimale Ansprüche, Digests und kontrollierte Beweisreferenzen. Integritätsschutz verringert nicht den Schaden der Offenlegung sensibler Daten.

Getrennte Autorisierung von Ausführung und Ergebnis

1 success Ein Feld kann keine verteilte Transaktion beschreiben. Eine Richtlinie kann eine Anfrage zulassen, das Gateway kann sie versenden und der Anbieter kann nach der Annahme eine Zeit aussetzen. Später kann die Transaktion abgewickelt oder rückgängig gemacht werden.

PROPOSED
  -> DENIED | APPROVAL_REQUIRED | AUTHORIZED
AUTHORIZED
  -> NOT_DISPATCHED | SUBMITTED
SUBMITTED
  -> ACCEPTED | REJECTED | UNCERTAIN
ACCEPTED
  -> SETTLED | FAILED | RETURNED | REVERSED

Wenn eine Antwort des Anbieters verloren geht, sollte die erste Quittung sagen: uncertainEin Abgleicher kann später einen Abrechnungsdatensatz unter Verwendung derselben Transaktion und externer Referenzen anhängen.

Das Universal Commerce Protocol behandelt eine Auftragsantwort als Momentaufnahme des aktuellen Zustands und verwendet Events plus Retrieval, um den Auftragszustand fortzusetzen. UCP Order Spezifikation unterstützt die gleiche operative Trennung: Geschützte Transaktionsnachweise und ein sich ändernder Handelsstaat benötigen stabile Verbindungen, nicht ein eingefrorenes Statuslabel.

Offline-Überprüfungsverfahren

Ein unabhängiger Prüfer sollte eine deterministische Sequenz ausführen und Teilergebnisse anstelle einer einzigen grünen Überprüfung zurückgeben.

type VerificationFinding = {
  check: string;
  result: 'pass' | 'fail' | 'unknown';
  detail: string;
};

type VerificationReport = {
  receiptId: string;
  integrity: 'valid' | 'invalid' | 'unknown';
  findings: VerificationFinding[];
  unresolvedEvidence: string[];
};

Die Prüfstelle sollte

1. Validieren Sie die Quittung mit ihrer deklarierten Schemaversion.
2. Lösen Sie den Emittenten, die Vertrauenskette und den Verifizierungsschlüssel.
3. Überprüfen Sie die Schlüsselvalidität, Rotation und Kompromisspolitik zum Empfangszeitpunkt.
4. Stellen Sie die kanonische Signatur-Nutzlast wieder her und überprüfen Sie die Signatur.
5. Beheben Sie den Pass- und Mandatsstatus, einschließlich Widerruf.
6. Berechnen Sie den Retained Request Digest.
7. Neubewertung der Mandatsbeschränkungen und der aufgezeichneten Policy-Version.
8. Überprüfen Sie eine genaue Genehmigung gegen den gleichen Request Digest.
9. Passen Sie den Idempotenzschlüssel und den externen Verweis auf den maßgeblichen Datensatz an.
10. Befolgen Sie Korrekturen, Umkehrungen und Abstimmungsaufzeichnungen.

Eine gültige Top-Level-Signatur mit einem fehlenden Request-Artefakt erzeugt eine unknown verbindliches Ergebnis. Es sollte nicht stillschweigend zu einer vollständig verifizierten Transaktion werden. Ebenso beweist ein gültiges Anbieterereignis nicht, dass der Agent Autorität hatte, es sei denn, der Prüfer kann es mit der früheren Entscheidung verbinden.

Entgegennahme- und Protokollkorrelationsmuster

Verwenden Sie stabile Identifikatoren für den Empfang, die Trace und den Geschäftsdatensatz, während Sie die sensible Duplizierung einschränken.

{
  "transaction_id": "txn:buyer:8841",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "receipt_id": "receipt:buyer:01K2",
  "idempotency_key": "payment:buyer:INV-8841:v1",
  "external_reference": "provider:pi_3Q...",
  "request_digest": "sha256:6e4f..."
}

Die Transaktions-ID gehört zum Enterprise-Workflow. Die Trace-ID verbindet Telemetrie. Der idempotency-Schlüssel steuert Retries. Die externe Referenz verbindet sich mit dem Provider. Der Digest bindet die exakte Anfrage. Die Wiederverwendung einer Kennung für jeden Zweck erzeugt Mehrdeutigkeit, wenn ein Workflow retries, Branchs oder reconciles.

Aufbewahrungs- und Zugriffsrichtlinien sollten vor Ort sein. Genügend signiertes Material aufbewahren, um historische Entscheidungen nach einer gewöhnlichen Schlüsseldrehung zu überprüfen, während sensible Nutzlasten in einem kontrollierten Beweisdienst mit einem engeren Zugriff und einem dokumentierten Löschplan gespeichert werden. Aufzeichnen, wer ein Beweispaket abgerufen hat und für welchen Fall. Wenn Rechtsstreitigkeiten, Datenschutz-Löschung und Prüfungsaufbewahrungsanforderungen kollidieren, leiten Sie den Fall an den rechenschaftspflichtigen Datenträger, anstatt den Quittungsdienst improvisieren zu lassen. Ein Digest kann zeigen, dass ein zurückgehaltenes Artefakt mit der ursprünglichen Referenz übereinstimmt. Es kann nicht wiederherstellen Inhalt, der gelöscht wurde, oder beweisen, welcher unzugängliche Inhalt einmal gesagt wurde.

Ausfall- und Wiederherstellungsfälle

Wichtige Kompromisse verdienen eine explizite Regel. Die Rotation ist Routine und sollte die historische Verifizierung beibehalten. Kompromisse können die Ablehnung von Datensätzen nach einer bekannten Zeit oder die Herabstufung der Zuverlässigkeit erfordern, wenn das Kompromissfenster unsicher ist. Diese Regel gehört in die Verifizierungsrichtlinie und nicht in eine ereignisspezifische Tabelle.

Eine reproduzierbare Prüfschiene

Bauen Sie ein komplettes Gehäusepaket und verwenden Sie es in Release-Tests:

fixture/
  passport.json
  mandate.json
  request.json
  policy.bundle
  approval.json
  receipt.json
  provider-response.json
  reconciliation.json
  expected-verification-report.json

Führen Sie diese Mutationen unabhängig voneinander aus:

• einen Antragsbetrag nach Genehmigung ändern;
• das Mandat eine Sekunde vor der Ausführung zu widerrufen;
• JSON vor der Überprüfung neu ordnen und reserialisieren;
• die Antwort des Anbieters zu entfernen;
• Drehen des Empfangsschlüssels;
• die Übermittlung mit demselben Idempotenzschlüssel duplizieren;
• einen gültigen Beleg für die falsche Transaktion vorlegen;
• fügen Sie ein widersprüchliches Abstimmungsergebnis hinzu.

Der erwartete Bericht sollte die fehlgeschlagene Prüfung identifizieren und alle noch bestandenen Prüfungen beibehalten. true oder false, weil Produktionsuntersuchungen in der Regel unvollständige Beweise und nicht völlig ungültige Pakete enthalten.

Download und Verifizierung eines synthetischen Evidenz-Bundles

Die Agent Control Lab 1.0.0 umfasst evidence.json, einem öffentlichen Demonstrationsschlüssel, verify.mjs Extrahieren Sie es und führen Sie die folgenden Befehle mit Node.js 20 oder höher aus:

node verify.mjs evidence.json demo-public-key.pem
node --test lab.test.mjs

Der Prüfer überprüft eine Ed25519-Signatur über die genauen Nutzdatenbytes und validiert den kleinen Referenzdatensatz. Die Vorrichtung zeichnet eine synthetische Autorisierungsentscheidung, ein akzeptiertes Ergebnis, eine vorgelagerte Referenz und einen Request-Digest auf. synthetic: trueDas Profil ist intelliger-lab-exact-bytes-v1Es handelt sich nicht um einen OATI-Beleg, eine JCS-Implementierung oder einen Kundenbeweisexport.

Die Test-Suite überprüft die ursprüngliche Nutzlast, ändert ein Nutzlastbyte, während die Signatur beibehalten wird, und versucht einen nicht verwandten Verifizierungsschlüssel. Sowohl veränderte Daten als auch falsche Schlüssel müssen einen Signaturfehler auslösen. Es überprüft auch die herunterladbare Vorrichtung selbst. Der Befehlszeilenverifikator verlässt sich bei Ablehnung ungleich Null, so dass er in einer lokalen Überprüfung verwendet werden kann, ohne dass ein Mensch eine erfolgsorientierte Logzeile interpretieren muss.

Der gebündelte Schlüssel ist ein Demonstrations-Vertrauensanker, der mit der Vorrichtung geliefert wird. In der Produktion erhalten Sie autorisierte Verifizierungsschlüssel durch einen separat vertrauenswürdigen Prozess. Die Annahme eines von einem Angreifer gelieferten Ersatzschlüssels besiegt die Prämisse des Tests. Es wird kein privater Schlüssel verteilt. Die Tests erzeugen ephemere Signaturschlüssel im Speicher für ihre eigenen Manipulationsexperimente.

Diese Stichprobe beweist nicht die Beibehaltung, Vollständigkeit, Nichtabstreitbarkeit in einem rechtlichen Rahmen oder die erfolgreiche Ausführung in einem externen System. Request-gebundene Autorisierung mit dem Enterprise Evidenzvorbereitung Workflow um zu sehen, wo die Beweise vorgelegt werden. Guide Library enthält die umgebende Steuerungsarchitektur.

Was aktuelle Zahlungsprotokolle beitragen

AP2 definiert Checkout- und Zahlungsmandate mit entsprechenden Quittungen, erfordert eine rollenspezifische Validierung in deterministischem Code und verknüpft Quittungen mit den für eine Transaktion verwendeten Mandaten. Im Streitabschnitt wird beschrieben, wie die Mandats- und Quittungspaare verifiziert werden können, während die operative Speicherung und der Abruf außerhalb der aktuellen Spezifikation liegen. Die AP2-Spezifikation ist nützlich, weil es sowohl das Protokollobjekt als auch die Betriebslücke freilegt.

Ein Schema kann keine Aufbewahrungsfristen wählen, historische Schlüssel bewahren, eine Zahlungsumkehr abgleichen, den Mieterzugriff erzwingen oder Beweise für einen Auditor verpacken. Teams benötigen diese Dienste auch dann, wenn jeder Teilnehmer sich auf das Drahtformat einigt.

Aktueller Intelliger und OATI Grenze

Die öffentliche Entwicklervorschau von OATI implementiert Receipt-Schemata, Builder, RFC 8785/JCS-Kanonisierung, Ed25519- und ES256-Profile, Verifizierung, Beispiele, Middleware und gemeinsam genutzte Konformitätsvorrichtungen. Der eingesetzte vertikale Kontrollebenen-Slice sendet einen Ausstellungsbeleg für eine Anmeldezeremonie aus. Dieser Ausstellungsnachweis ist getrennt von einer später geschützten Geschäftstransaktion.

Dauerhafte bilaterale Beweise, Aufbewahrung, Export von Auditpaketen und Streitbeilegungs-Workflows bleiben unvollständig. Eine unabhängige Kryptographie- und Protokollüberprüfung ist ebenfalls offen. Eine Sandbox-Transaktion demonstriert den Entwicklervertrag, während eine vollständige Zwei-Unternehmen-Produktionsstreitigkeit ein Release-Gate bleibt. Die Ziel-Intelliger-Ergebnis-Ledger- und Cross-Merchant-Ergebnisüberprüfung sind Blaupausenkomponenten, keine bereitgestellten Dienste.

Sicherheitsüberprüfungshinweis: Ein Experte muss Aufbewahrung, Zugangskontrolle, kryptographischen Lebenszyklus, Sicherheitsetiketten, Datenschutz- und Streitbeilegungsverfahren für den Einsatz überprüfen. Dieser Artikel wurde am 11. August 2026 anhand des dokumentierten Entwickler-Vorschau-Status von OATI überprüft. Er zertifiziert kein bestimmtes Beweissystem.

Verwenden des Auditmodells

Verwenden Sie das unterstützende Audit-Engineering-Cluster für Implementierungs- und Betriebsdetails:

• Was für AI Agent Aktivität zu protokollieren
• AI Agent Audit Trail Architektur
• AI Agent Audit Trail Compliance Evidenz
• AI Agent Audit Trail Retention und Datenschutz
• Offline-Überprüfung der Eingänge von KI-Agenten
• Rekonstruktion von AI Agent Incident

Der breitere AI Agent Authorization Guide erklärt, wie Autorität vor der Ausführung gebunden ist. Blockchain Proofs, Logs und AktionsquittungenÜberprüfen Sie die Engineering Tradeoffs in Aktionseingänge im Vergleich zu Anwendungsprotokollen und folgen Sie dem vollständigen Flow in eine überprüfbare MCP-Transaktion. Die OATI Empfangsdokumentation und öffentliche Prüfstelle den relevanten Entwicklerpfad bereitzustellen.

Um das Befestigungspaket und den strukturierten Verifizierungsbericht an Ihren Stapel anzupassen, Öffnen Sie das öffentliche OATI-Repository.