AI Agent Observability: Warum Audit Logs nicht genug sind

13 Minuten Lesezeit

Die Beobachtbarkeit von KI-Agenten wird zu einem Governance-Problem, wenn ein Unternehmensagent um 14:03 Uhr eine Rückerstattung ausstellt. Sechs Monate später fragt Finance, welche Richtlinie es erlaubt. Security fragt, ob das Mandat noch aktiv war. Legal fragt, was der Agent tatsächlich an den Zahlungsanbieter gesendet hat. Das Plattformteam verfügt über Audit-Logs, Traces, ein Modell-Transkript, ein Genehmigungsprotokoll und eine vorgelagerte Transaktions-ID.

Sie haben möglicherweise immer noch keine Antwort, die sie überprüfen können.

Logs sind ausgezeichnete Betriebsdaten. Sie helfen Ingenieuren beim Suchen, Aggregieren, Alarmieren und Debuggen. Sie sind normalerweise veränderlich, systemspezifisch und über Dienste verteilt. Eine Protokollzeile, die sagt: policy=allow bindet diese Entscheidung nicht an den genauen Antrag, die aktive Befugnis, die Genehmigung, den ausgeführten Betrieb und das beobachtete Ergebnis.

Ein Aktionsbeleg ist ein signierter, kanonischer Datensatz für eine geschützte Transaktion. Er ersetzt keine Protokolle oder Spuren. Er gibt der Transaktion ein tragbares Beweisobjekt, das ein anderer Verifizierer überprüfen kann, ohne der Anwendung zu vertrauen, die ihn anzeigt.

Der Unterschied wird wichtig, wenn Agenten Geld ausgeben, die Produktion ändern, sensible Daten freigeben oder über Unternehmensgrenzen hinweg handeln können.

AI Agent Observability beginnt mit Audit Logs

Logs sagen Ihnen, was eine Komponente zu einem Zeitpunkt gemeldet hat.

{
  "timestamp": "2026-08-10T14:03:18.119Z",
  "level": "info",
  "service": "refund-gateway",
  "requestId": "req_f2a7",
  "agentId": "agent:support:refund-4",
  "policyDecision": "allow",
  "upstreamStatus": 200
}

Diese Zeile hilft einem Betreiber, die Anforderung zu finden und einen Fehler zu korrelieren, sie sagt nicht, welches Richtlinienpaket die Entscheidung hervorgebracht hat, welche Anforderung bewertet wurde, ob sich die Ausführungsanforderung geändert hat, welches Mandat den Agenten eingeschränkt hat, welche Genehmigung beigefügt wurde oder welche vorgelagerte Antwort das System beobachtet hat.

Sie können diese Felder hinzufügen. Bald enthält der Protokolleintrag Nutzdatenverdauungen, Emittentenketten, Richtlinienreferenzen, Genehmigungskennungen und Signaturen. An diesem Punkt entwerfen Sie eine Quittung in einem Protokollformat, oft ohne Canonicalisation oder Verifizierungssemantik zu definieren.

Andere operative Werkzeuge haben die gleiche Grenze. Eine verteilte Trace erklärt den Call-Pfad und die Latenz. Ein SIEM korreliert Ereignisse und erkennt Muster. Ein reines Auditprotokoll bewahrt eine Abfolge administrativer Änderungen. Ein Modelltranskript zeigt, was der Agent betrachtet oder gesagt hat. Jeder bleibt nützlich. Keiner allein ist das Transaktionsnachweisobjekt.

Eine Quittung bindet den Sicherheitskontext der Transaktion

Eine nützliche Quittung verbindet die Fakten, die in einer Servicearchitektur tendenziell auseinander driften:

die verantwortliche Organisation und den Vertreter;
den zum Entscheidungszeitpunkt verwendeten Emittenten und aktuellen Vertrauens- oder Sicherungsstaat;
das Mandat und etwaige Delegationskette;
den kanonischen Transaktionsumschlag und Request Digest;
die Richtlinieversion und die strukturierte Entscheidung;
gegebenenfalls die menschliche Zulassung;
Input- oder Output-Transformationen;
der durchgeführte Vorgang und das beobachtete Ergebnis;
externe Anbieterreferenzen;
Zeitstempel, Nonce- und Idempotenzdaten;
Signatur-Metadaten.

Eine illustrative Quittung könnte so aussehen:

{
  "type": "ActionReceipt",
  "version": "example-1",
  "receiptId": "rcpt_01J8P27YFZ",
  "issuer": "org:example:gateway",
  "assurance": "unilateral",
  "subject": {
    "organisation": "org:example",
    "agent": "agent:support:refund-4",
    "passport": "passport_01J7...",
    "mandate": "mandate_01J8..."
  },
  "transaction": {
    "id": "txn_01J8P25K4R",
    "requestDigest": "sha256:44f8...",
    "idempotencyKey": "refund_charge_8721_v1",
    "action": "refund.create",
    "resource": "tenant/418/charge/8721"
  },
  "decision": {
    "result": "allow",
    "policyBundle": "refund-policy-2026-08-03",
    "requestDigest": "sha256:44f8...",
    "decisionDigest": "sha256:c9a1...",
    "approval": "apr_01J8P261MN"
  },
  "execution": {
    "requestDigest": "sha256:44f8...",
    "status": "accepted",
    "providerReference": "rf_294801",
    "responseDigest": "sha256:7b32..."
  },
  "issuedAt": "2026-08-10T14:03:18Z",
  "signature": {
    "algorithm": "Ed25519",
    "keyId": "key:gateway:2026-07",
    "audience": "oati-verifier:example",
    "createdAt": "2026-08-10T14:03:18Z",
    "expiresAt": "2026-08-10T14:08:18Z",
    "nonce": "01J8P27Z1K",
    "value": "base64url:MEUCIQ..."
  }
}

Dies ist eine erklärende Form, nicht das normative OATI-Schema. Der Design-Punkt ist die Bindung. Derselbe Request-Digest erscheint im Entscheidungs- und Ausführungskontext, so dass ein Verifizierer die Substitution erkennen kann. Die Quittung benennt die Richtlinie und die Genehmigung, anstatt sich auf eine nahe gelegene Protokollzeile zu verlassen. Das Assurance-Feld sagt, wer die Beweise unterschrieben hat.

Canonicalisation macht Signaturen portabel

Das Signieren von JSON-Rohtext ist unzuverlässig, da äquivalente Objekte mit unterschiedlicher Whitespace-, Property-Order- oder Zahlenformatierung serialisiert werden können.

Der Emittent sollte

Validieren des Objekts gegen ein versioniertes Schema;
Entfernen des Signaturfeldes aus der signierenden Nutzlast;
das verbleibende Objekt mit einem vorgegebenen Algorithmus kanonisieren;
Berechnen Sie alle referenzierten Digests mit benannten Algorithmen;
Signieren der kanonischen Bytes mit einem identifizierten Schlüssel;
Fügen Sie die Signaturmetadaten an, ohne signierte Felder zu ändern.

Verifizierung kehrt den Prozess um:

async function verifyReceipt(receipt: Receipt, trust: TrustResolver) {
  validateSchema(receipt);
  assert(receipt.version === SUPPORTED_RECEIPT_VERSION);
  assert(ALLOWED_ALGORITHMS.has(receipt.signature.algorithm));
  assert(receipt.signature.audience === EXPECTED_AUDIENCE);
  assert(receipt.signature.createdAt <= now());
  assert(now() < receipt.signature.expiresAt);

  const issuer = await trust.resolveIssuer(receipt.issuer);
  const key = await trust.resolveKey(receipt.signature.keyId);
  assert(key.issuer === issuer.id);
  assert(key.validFrom <= receipt.issuedAt);
  assert(receipt.issuedAt < key.validUntil);
  assert(await trust.isActive(receipt.issuer, receipt.issuedAt));
  assert(await trust.isActive(key.id, receipt.issuedAt));

  const payload = canonicalise(withoutSignature(receipt));
  assert(verifySignature(key.publicKey, payload, receipt.signature.value));
  assert(await replayStore.claim(receipt.signature.nonce));

  const currentIssuerStatus = await trust.currentStatus(receipt.issuer);
  const currentKeyStatus = await trust.currentStatus(key.id);

  return {
    validSignature: true,
    validAtIssuance: true,
    currentIssuerStatus,
    currentKeyStatus,
    assurance: receipt.assurance,
    transactionId: receipt.transaction.id,
    requestDigest: receipt.transaction.requestDigest,
  };
}

Dies ist immer noch eine Architekturskizze und kein Ersatz für den OATI-Verifikator. Eine vollständige Implementierung muss die ausgewählten Proof-Profil-, Schema-, Audience-, Time-, Algorithmus-, Nonce-, Replay-, Trust-Chain- und Widerrufsregeln anwenden. Die Verifizierungsrichtlinie muss angeben, ob der Status zum Ausstellungszeitpunkt, zum Verifizierungszeitpunkt oder zu beiden Zeitpunkten überprüft wird. Diese Fragen erfüllen unterschiedliche Anforderungen. Ein Auditor muss möglicherweise wissen, dass der Schlüssel zum Zeitpunkt der Ausstellung des Belegs gültig war und ob er seitdem kompromittiert wurde.

Das implementierte Entwicklerprofil von OATI verwendet die RFC 8785 JSON-Kanonikalisierung und unterstützt Verifizierungsprofile von Ed25519 und ES256. Die umfassendere Lektion gilt unabhängig vom Format: Wenn unabhängige Implementierungen die signierten Bytes nicht wiederherstellen können, ist die Quittung nicht portabel.

Binden, was autorisiert wurde, was ausgeführt wurde

Der wichtigste Vergleich ist zwischen der kanonischen Transaktion, die von der Policy ausgewertet wurde, und der Upstream-Anfrage.

Manchmal sollten sie den gleichen Digest haben. Manchmal transformiert das Gateway absichtlich die Anforderung. Es kann ein verbotenes Feld entfernen, einen Ressourcenalias auflösen oder einen kurzlebigen Berechtigungsnachweis einfügen. In diesem Fall sollte die Quittung sowohl den vorgeschlagenen als auch den ausgeführten Anforderungsverdau sowie einen strukturierten Transformationsrekord aufzeichnen.

{
  "transformation": {
    "policy": "minimise-refund-request-v3",
    "inputDigest": "sha256:02a9...",
    "outputDigest": "sha256:44f8...",
    "operations": [
      { "op": "remove", "path": "/customer/internalRiskNotes" },
      { "op": "replace", "path": "/tenant", "valueDigest": "sha256:8ac0..." }
    ]
  }
}

Vermeiden Sie es, sensiblen Klartext in die Quittung zu legen, nur um sie in sich geschlossen zu machen. Digests, verschlüsselte Anhänge und geregelte Beweisreferenzen können die Bindung wahren, während Nutzdaten in der Kundenumgebung aufbewahrt werden. Ein Verifizierer kann die Integrität bestätigen, ohne jedes Quellfeld zu erhalten.

Wenn eine Transformation die Geschäftsbedeutung ändert, erhalten Sie eine neue politische Entscheidung und Genehmigung der transformierten Transaktion.

Geben Sie an, was die Quittung nicht beweist

Eine gültige Signatur beweist, dass der Inhaber eines Signaturschlüssels die kanonische Quittung unterschrieben hat. Die Vertrauensauflösung kann diesen Schlüssel mit einem Emittenten und Status verbinden. Die gebundenen Digests können zeigen, dass sich die referenzierten Beweise nicht geändert haben.

Die Quittung beweist nicht automatisch:

dass eine externe Datenquelle die Wahrheit sagte;
dass ein Lieferant einen Auftrag erfüllt hat;
dass eine Zahlung abgewickelt wurde, weil eine API zurückgegeben wurde accepted;
ob die Argumentation eines Modells korrekt war;
dass ein menschlicher Genehmiger den gesamten Kontext verstanden hat;
dass kein Verkehr den Durchsetzungspfad umgangen hat;
Das Signiersystem selbst war kompromisslos.

Dies sind separate Behauptungen mit separaten Beweisen.

Beispielsweise kann eine Quittung die Transaktionsreferenz eines Zahlungsanbieters und die vom Gateway beobachtete Antwort binden. Eine Abgleichung bestimmt später, ob die Zahlung abgewickelt, fehlgeschlagen oder rückgängig gemacht wurde. Ein verknüpftes Ergebnisereignis anfügen oder ein neues Statusnachweisobjekt ausgeben. Die ursprüngliche Quittung sollte nicht an die spätere Realität angepasst werden.

Ebenso beweist eine Orakelsignatur, welches Orakel eine Reserve-Anweisung geliefert hat.

Einseitige Beweise sind nützlich und begrenzt

Wenn ein Unternehmen das Gateway betreibt, ist der Empfang einseitig. Dies ist üblich und praktisch. Ein API-Anbieter kann nachweisen, was sein eigenes System autorisiert und freigegeben hat, auch wenn der Kundenvertreter niemals ein OATI-Objekt signiert. Ein kaufendes Unternehmen kann nachweisen, was sein Gateway genehmigt und an einen Lieferanten gesendet hat, auch wenn dieser Anbieter eine unveränderte API verwendet.

Die Quittung sollte das Sicherheitsniveau und die Unterzeichner offenlegen:

{
  "assurance": {
    "level": "unilateral",
    "signers": ["org:buyer:gateway"],
    "counterpartySignature": null
  }
}

Nennen Sie dies nicht "gegenseitig verifiziert" oder "bilateraler Beweis". Es ist immer noch nützlich für interne Kontrollen, Audit-Rekonstruktion und Konfliktvorbereitung.

Ein vorgelegter Reisepass verbessert die Überprüfung von Agenten und Eigentümern. Ein unterzeichnetes Mandat bietet eine tragbare Befugnis, die dem Vertrauen des Emittenten unterliegt. Eine Gegenzeichnung des Ergebnisses schafft bilaterale Beweise für die Tatsachen, die der Geschäftspartner tatsächlich unterzeichnet hat.

Die Gegenzeichnung validiert nicht jedes Feld implizit. Definieren Sie die gegensignierende Nutzlast. Ein Lieferant darf nur die Bestellkennung und den Annahmestatus unterschreiben, während der Käufer den vollständigen lokalen Entscheidungskontext unterschreibt.

Behalten Sie Quittungen und Protokolle verbunden

Quittungen funktionieren am besten als Rückgrat eines Beweisgraphen, nicht als isolierte Datei.

Verwenden Sie eine Transaktionskennung für Gateway, Policy Engine, Genehmigungsworkflow, Credential Broker, Connector, Ledger und Quittung. Setzen Sie die Quittungskennung und den Transaktionsverdau in Protokolle und Trace-Attribute. Halten Sie die rohe Telemetrie unter normalen Aufbewahrungs- und Zugriffskontrollen. Speichern Sie die Quittung und die wesentlichen Beweisreferenzen entsprechend den rechtlichen und operativen Anforderungen der Transaktion.

Transaction ID
  |-- gateway logs
  |-- distributed trace
  |-- policy decision record
  |-- approval record
  |-- credential issuance reference
  |-- provider operation reference
  |-- action receipt
  `-- later outcome and reconciliation events

Geben Sie nicht bei jedem Protokollereignis die vollständige Quittung an, wodurch Duplikationen, Datensicherheit und inkonsistente Kopien entstehen.

Design für Streitigkeiten, bevor sie passieren

Ein Streitpaket sollte es einem Ermittler ermöglichen, einen festen Satz von Fragen zu beantworten:

Wer hat den Agenten betrieben, nach welchem Emittenten und Sicherungsniveau?
Welche Befugnis war aktiv und welche Zwänge galten?
Welche genaue Transaktion hat das Gateway ausgewertet?
Welche Policy-Version hat die Entscheidung zurückgegeben?
War menschliche Zustimmung erforderlich, und was verdaut hat es abgedeckt?
Welche Anfrage erreichte das externe System?
Welche Reaktion hat das Gateway beobachtet?
Welches spätere Ergebnis wurde in Einklang gebracht?
Wurden relevante Aufzeichnungen des Emittenten, Schlüssels, Passports oder Mandats widerrufen?
Kann ein unabhängiger Prüfer die Digest- und Signaturprüfungen reproduzieren?

Das Beweispaket kann signierte Objekte, Schemaversionen, Vertrauensaufzeichnungen, Richtlinienartefakte, Genehmigungsaufzeichnungen und ausgewählte Nutzlastnachweise enthalten. Verwenden Sie Referenzen und Digests, um das Kopieren sensibler Inhalte standardmäßig zu vermeiden.

Die Online-Auflösung kann den aktuellen Widerrufsstatus hinzufügen, aber ein zentrales Dashboard sollte nicht die einzige Möglichkeit sein, die Beweise zu interpretieren.

Fehlerfälle zum Testen

Ein Log und Quittung widersprechen

Behandeln Sie die unterzeichnete Quittung als Nachweis dafür, was der Quittungsaussteller bescheinigt hat, nicht die automatische Wahrheit; vergleichen Sie Digests, Serviceuhren, Anfrage-IDs und Unterschriftszeit; bewahren Sie beide Aufzeichnungen für die Untersuchung auf; regenerieren Sie die Quittung nicht stillschweigend.

Der Signaturschlüssel wird später widerrufen

Die Überprüfung sollte sowohl die historische Gültigkeit als auch den aktuellen Status angeben. Ein späterer Kompromiss kann das Vertrauen verändern, ohne die Bytes zu ändern.

Das Policy Bundle kann nicht abgerufen werden

Ein Richtlinien-Kennzeichen allein kann für eine langanhaltende Streitigkeit unzureichend sein. Das unterzeichnete Richtlinienpaket oder das behördliche Beweismaterial behalten, vorbehaltlich der Kontrolle des geistigen Eigentums und der Privatsphäre.

Die externe API geht aus

Ausstellung einer Quittung mit einem unknown oder pending Ausführungszustand statt Fehlerraten; Abgleich mit dem Provider-Referenz- oder Idempotenzschlüssel; Verknüpfung der späteren Beobachtung mit der ursprünglichen Transaktion.

Zwei Quittungen existieren für eine Transaktion

Wenn verschiedene Parteien ihre eigenen Quittungen ausstellen, identifizieren Sie jeden Emittenten und binden Sie sie durch den gemeinsamen Transaktionsverdau, anstatt so zu tun, als würde einer den anderen überschreiben.

Sensible Daten sickern durch Beweise

Quittungen sollten nur Felder enthalten, die für die Verifizierung erforderlich sind: Verwendung von Digests, selektive Offenlegung, verschlüsselte Anhänge oder lokale Beweisreferenzen für Nutzlasten; Testquittungen und Verweigerungsaufzeichnungen für zufällige geheime, sofortige und persönliche Datenerfassung.

Checkliste der Durchführung

Definieren Sie die Ansprüche und das Sicherheitsvokabular der Quittung, bevor Sie Felder auswählen.
Verwenden Sie ein versioniertes Schema und eine deterministische Canonicalisation.
Bindende Organisation, Agent, Befugnis, Transaktion, Entscheidung, Genehmigung und Ausführung.
Nennen Sie jeden Digest- und Signaturalgorithmus.
Vergleichen Sie die autorisierte Anfrage mit der ausgeführten Anfrage.
Verfolgen Sie Transformationen explizit.
Bewahren Sie Geheimnisse und unnötige Nutzdaten aus der Quittung heraus.
Geben Sie den Emittenten, die Schlüsselkennung, den Zeitpunkt der Unterzeichnung und die Statusreferenzen an.
Machen Sie einseitige und gegengezeichnete Beweise sichtbar anders.
Bewahren Sie Idempotenz, Nonce und Wiederholungsinformationen.
Modell ausstehende, unbekannte, abgewickelte, gescheiterte und umgekehrte Ergebnisse separat.
Verknüpfen Sie Quittungen mit Protokollen und Traces durch stabile Identifikatoren.
Bewahren Sie die Richtlinien und Genehmigungsnachweise auf, die für eine spätere Überprüfung erforderlich sind.
Erstellen Sie einen Offline-Verifier und veröffentlichen Sie Konformitätsvektoren.
Testen Sie Substitution, Wiederholung, Widerruf, Schlüsselrotation und Teilfehler.

Aktuelle Grenze von OATI

Die Öffentlichkeit OATI-Empfang Ein Framework implementiert Schemata, Builder, Canonicalisation, Signaturen, Verifizierung, Beispiele und Konformitätsflüsse. Entwickler können heute Quittungen generieren und unabhängig verifizieren. Das implementierte kryptographische Profil bleibt eine Entwicklervorschau, bis eine unabhängige Protokoll- und Implementierungsüberprüfung abgeschlossen ist.

Dauerhafte bilaterale Unterzeichnung, langfristige Beweisaufbewahrung, Export von Auditpaketen und Streitbeilegungsworkflows sind zielgerichtete kommerzielle Fähigkeiten und keine vollständigen Produktionsmerkmale. Das macht die Unterscheidung in diesem Artikel eher praktisch als akademisch. Eine unterzeichnete Quittung kann bereits die Integrität und Portabilität von Transaktionsnachweisen verbessern, aber Produktionsnachweisoperationen erfordern Aufbewahrung, wichtige Governance, Abgleich, Datenschutzkontrollen und getestete Wiederherstellung um das Objekt herum.

Führen Sie durchsuchbare Protokolle für Operationen und eine unterzeichnete Quittung für den Transaktionsanspruch.