Access Transparency-Ereignisse mit dem Transparenzprotokoll verifizieren

Erfahre, wie du kryptografisch verifizierst, dass kein Access Transparency-Ereignis entfernt oder verändert wurde, nachdem es in das Transparenzprotokoll deiner Organisation übernommen wurde.

Wie das Transparenzprotokoll funktioniert

Ein „transparency log“ (Transparenzprotokoll) ist eine Technik, um einen Datensatz manipulationserkennbar zu machen. Einträge werden ausschließlich angehängt. Jedes Mal, wenn das Protokoll wächst, signiert sein Betreiber eine kurze Aussage, einen sogenannten „checkpoint“ (Prüfpunkt), die sich über einen Merkle-Tree-Hash auf alle bisherigen Einträge festlegt. Wer einen Checkpoint aufbewahrt, kann später einen Beweis verlangen, dass das aktuelle Protokoll noch alles enthält, was dieser Checkpoint abgedeckt hat – unverändert und in derselben Reihenfolge. Das Entfernen oder Umschreiben eines Eintrags kann daher einem Verifizierer, der einen Checkpoint aufbewahrt hat, der diesen Eintrag abdeckt, nicht verborgen bleiben. Certificate Transparency und die Go-Modul-Prüfsummendatenbank basieren auf derselben Technik. C2SP tlog-tiles ist eine offene Spezifikation, um ein solches Protokoll als signierte Checkpoints plus statische, cachebare Tiles aus Hashes und Einträgen bereitzustellen, sodass Clients die Hashes abrufen und jeden Beweis selbst berechnen können.

Wenn Access Transparency aktiviert ist, führt Anthropic ein Transparenzprotokoll für deine Organisation. Es ist ein nur erweiterbarer, kryptografisch signierter Datensatz von Access Transparency-Ereignissen (anthropic_access und cmek_preserve). Jedes solche Ereignis, das nach der Erstellung des Protokolls für deine Organisation aufgezeichnet wird, wird daran angehängt. Das Protokoll folgt dem C2SP-tlog-tiles-Format, sodass Tools, die für diesen Standard entwickelt wurden, seine Checkpoints, Tiles und Beweise verstehen.

• Ein Protokoll pro Organisation. Das Protokoll jeder Organisation hat einen festen Origin-String: axt.anthropic.com/<your organization UUID>. Der Origin ändert sich während der gesamten Lebensdauer der Organisation nie.
• Jedes neue Ereignis wird zu einem Leaf. Sobald ein Access Transparency-Ereignis in deinem Activity Feed erscheinen darf, wird es zuerst als „leaf“ (Blatt) an dein Protokoll angehängt und erst danach im Feed bereitgestellt. Ein Leaf ist eine deterministische Serialisierung der dokumentierten Felder des Ereignisses. Das Ereignis in deinem Feed trägt transparency_log_leaf_index, seine nullbasierte Position in deinem Protokoll.
• Checkpoints legen sich auf die gesamte Historie fest. Das Protokoll ist ein Merkle-Tree. Immer wenn es wächst, veröffentlicht Anthropic einen signierten Checkpoint: ein kurzes Textdokument, das den Origin des Protokolls, seine aktuelle Größe und den Root-Hash angibt, der sich auf jedes Leaf festlegt. Jeder Checkpoint trägt genau eine Signatur des Signaturschlüssels des Protokolls.
• Zwei Beweise folgen daraus. Ein „inclusion proof“ (Inklusionsbeweis) zeigt, dass ein bestimmtes Ereignis unter einem Checkpoint an seiner Position vorhanden ist. Ein „consistency proof“ (Konsistenzbeweis) zeigt, dass ein späterer Checkpoint eine nur angehängte Erweiterung eines früheren ist, den du gespeichert hast, sodass dazwischen nichts entfernt oder geändert wurde.
• Verifizierungsschlüssel werden in-band bereitgestellt. Der Endpunkt für Verifizierungsschlüssel gibt die öffentlichen Schlüssel zurück, die Checkpoints signieren. Bei einer geplanten Schlüsselrotation wird der neue Schlüssel zu dieser Liste hinzugefügt, bevor er mit dem Signieren beginnt, und frühere Schlüssel bleiben aufgeführt. Checkpoints, die du bereits besitzt, lassen sich daher weiterhin verifizieren.

Was das Transparenzprotokoll beweist

• Die Leaf-Felder eines Ereignisses, das du besitzt (aufgeführt unter Wie ein Ereignis zu einem Leaf wird), sind Byte für Byte das, was Anthropic in das Protokoll übernommen hat.
• Das Protokoll für deine Organisation wächst ausschließlich. Die Verifizierung gegen einen Checkpoint, den du besitzt, schlägt fehl, wenn ein in das Protokoll übernommenes Ereignis dort später gelöscht oder umgeschrieben wird. Sie schlägt auch fehl, wenn dir eine andere Historie bereitgestellt wird als die, die dir zuvor bereitgestellt wurde.
• Neue Einträge können nur angehängt werden. Ein Ereignis kann nicht in eine Historie eingefügt werden, die du bereits verifiziert hast.

Was es nicht beweist oder ändert

• Es beweist nicht, dass jeder Zugriff aufgezeichnet wurde oder dass ein aufgezeichnetes Ereignis den Zugriff korrekt beschreibt. Es beweist nur, dass sich das, was Anthropic in das Protokoll übernommen hat, seitdem nicht geändert hat.
• Es ändert nicht, was Access Transparency abdeckt oder wann Ereignisse eintreffen.
• Bereitgestellte Felder außerhalb des Leafs, wie workspace_uuid und jedes später hinzugefügte Feld, werden vom Beweis nicht abgedeckt.
• Ein Inklusionsbeweis gilt für ein Ereignis, das dir bereitgestellt wurde. Er beweist für sich allein nicht, dass der Feed jedes Leaf aufgeführt hat, das das Protokoll enthält. Die Entry-Bundles des Protokolls enthalten jedes Leaf, sodass du die vollständige Menge der übernommenen Ereignisse direkt lesen kannst, wenn du sie brauchst.
• Das Vorhandensein von transparency_log_leaf_index an einem Ereignis ist ein Verweis, kein Beweis. Verifiziere immer die Inklusion, bevor du ein Ereignis als im Protokoll übernommen behandelst.
• Der Schutz gegen eine umgeschriebene Historie ergibt sich aus den Checkpoints, die du aufbewahrst. Die Signatur eines Checkpoints durch einen Schlüssel, der unter Veröffentlichte Schlüssel-Fingerprints aufgeführt ist, beweist, dass er aus dem Protokoll von Anthropic stammt. Ein Konsistenzbeweis ab dem Checkpoint, den du beim letzten Mal gespeichert hast, beweist, dass die Historie, die du bereits beobachtet hast, nur gewachsen ist.

Bevor du beginnst

Du benötigst:

• Einen Compliance Access Key mit dem Scope read:compliance_activities, also denselben Schlüssel und Scope, die du für den Activity Feed verwendest. Ein Schlüssel einer übergeordneten Organisation kann das Protokoll jeder registrierten untergeordneten Organisation lesen, indem er die untergeordnete Organisation bei jeder Anfrage angibt.
• Die UUID deiner Organisation. Du findest sie in der Claude Console unter Settings > Organization. Es ist derselbe Wert, den der Activity Feed als organization_uuid bereitstellt, aber entnimm ihn der Console. Dieser Wert macht einen Checkpoint zu deinem, daher darf er nicht aus der API stammen, die du verifizierst. Du leitest daraus den Origin deines Protokolls als axt.anthropic.com/<organization UUID> ab. Leite diesen String selbst ab. Lies ihn nicht aus einer API-Antwort.
• Einen dauerhaften Speicherort für den letzten Checkpoint, den du verifiziert hast. Dieser gespeicherte Checkpoint macht aus „das Protokoll ist heute konsistent“ die Aussage „das Protokoll ist konsistent, seit du es beobachtest“.

Zeitlicher Ablauf

• Ereignisse: Access Transparency-Ereignisse erscheinen innerhalb von zwei Werktagen nach dem Zugriff in deinem Activity Feed. Ein Ereignis gelangt erst in das Protokoll, wenn es berechtigt ist, bereitgestellt zu werden, sodass das Protokoll ein Ereignis nie vorzeitig offenlegt. Da das Protokoll geschrieben wird, bevor der Feed das Ereignis bereitstellt, kann ein Eintrag kurzzeitig im Protokoll erscheinen, bevor sein Ereignis in deinem Feed erscheint. Diese Lücke ist keine Unstimmigkeit.
• Checkpoints: Ein neuer Checkpoint wird veröffentlicht, wann immer dein Protokoll wächst.
• Inklusionsbeweise: Ein Beweis für ein neu bereitgestelltes Ereignis ist verfügbar, sobald ein Checkpoint veröffentlicht ist, der die Position des Ereignisses abdeckt, normalerweise sehr kurz nachdem das Ereignis erscheint. Wenn du ihn früher anforderst, erhältst du ein 404 und versuchst es nach einer kurzen Verzögerung erneut.
• Verifizierungsrhythmus: Führe deine Verifizierung mindestens täglich aus. Stündlich ist angemessen.
• Abmeldung: Wenn deine Organisation Access Transparency nicht mehr verwendet, wird nichts gelöscht. Dein Protokoll bleibt über dieselben Endpunkte lesbar. Wenn Access Transparency später erneut aktiviert wird, wird dasselbe Protokoll fortgeführt.

Aufbewahrung und Löschung

• Transparenzprotokoll: Anthropic löscht keine Einträge aus deinem Protokoll, und das Protokoll hat kein Ablaufdatum. Es bleibt erhalten, wenn deine Organisation Access Transparency nicht mehr verwendet, und auch nachdem deine Organisation gelöscht wurde, denn das Entfernen von Einträgen ist genau die Änderung, die das Protokoll erkennen soll. Entry-Bundles enthalten die Leaf-Felder jedes Ereignisses, sodass diese Felder so lange aufbewahrt werden wie das Protokoll.
• Activity Feed: Access Transparency-Ereignisse im Activity Feed folgen der Aufbewahrungsdauer des Feeds. Aktivitäten werden 6 Jahre lang aufbewahrt. Siehe Den Activity Feed abfragen.
• Keine Löschung durch dich: Die Endpunkte des Transparenzprotokolls sind schreibgeschützt. Es gibt keine Möglichkeit, einen Eintrag zu löschen oder zu ändern.

Endpunkte des Transparenzprotokolls

Sechs schreibgeschützte Endpunkte werden unter https://api.anthropic.com/v1/compliance/transparency_log/ bereitgestellt:

Checkpoints, Tiles und Entry-Bundles folgen exakt dem C2SP-tlog-tiles-Wire-Format. Die beiden Beweis-Endpunkte dienen der Bequemlichkeit: Jeder Beweis lässt sich auch aus Tiles berechnen, sodass du der Ausgabe eines Beweis-Endpunkts nie vertrauen musst. Du verifizierst die zurückgegebenen Hashes gegen einen signierten Checkpoint.

Authentifizierung und Scoping

Sende deinen Compliance Access Key im Header x-api-key sowie den Header anthropic-version, wie bei jeder Compliance-API-Anfrage (siehe Versionierung). Die Compliance API muss für deine Organisation aktiviert sein.

Es gibt keine separate Berechtigung für das Transparenzprotokoll. Jeder Schlüssel, der den Activity Feed deiner Organisation lesen kann, für deine Organisation oder ihre übergeordnete Organisation, kann dein gesamtes Protokoll lesen, einschließlich der Ereignisfelder in seinen Entry-Bundles.

Jede Anfrage liest genau das Protokoll einer Organisation:

• Ein Schlüssel auf Organisationsebene liest das Protokoll seiner eigenen Organisation. Der Query-Parameter organization_id ist optional. Falls vorhanden, muss er die eigene Organisation des Schlüssels angeben.
• Ein Schlüssel auf Ebene der übergeordneten Organisation muss organization_id übergeben und damit eine untergeordnete Organisation angeben.
• organization_id akzeptiert die getaggte ID org_... oder die Organisations-UUID.

Ein 404 bedeutet, dass es kein Protokoll gibt, das dieser Schlüssel lesen kann. Eine Organisation außerhalb des Scopes des Schlüssels, eine nicht existierende Organisation und eine Organisation, deren Protokoll noch nicht erstellt wurde, sind absichtlich nicht voneinander zu unterscheiden. Das Protokoll einer Organisation, die Access Transparency inzwischen nicht mehr verwendet, fällt nicht unter diesen Fall: Es wird weiterhin bereitgestellt.

Fehler

Fehler verwenden auf jedem Endpunkt, einschließlich der Text- und Binär-Endpunkte, den standardmäßigen JSON-Fehler-Envelope der Compliance API. Siehe Fehler für den Envelope und die gemeinsamen Fehlertypen.

Caching

Antworten sind nur durch den anfragenden Client cachebar. Cache-Control enthält immer private, und Antworten tragen Vary: x-api-key. Setze keinen gemeinsam genutzten Cache vor diese Endpunkte. Vollständige Tiles und vollständige Entry-Bundles ändern sich nie und werden mit Cache-Control: private, max-age=604800, immutable bereitgestellt. Alles andere, einschließlich Checkpoints, Beweisen, Schlüsseln, partiellen Tiles und Fehlern, wird mit Cache-Control: private, no-store bereitgestellt.

Den neuesten Checkpoint lesen

GET /v1/compliance/transparency_log/checkpoint

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/transparency_log/checkpoint" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

Die Antwort ist text/plain: eine C2SP-Signed Note. Die Zeilen des Bodys sind der Origin, die Baumgröße in Dezimaldarstellung und der Base64-Root-Hash. Es folgt eine Leerzeile, dann die Signaturzeile, die mit einem Geviertstrich (U+2014) beginnt, den Origin nennt und mit einem Base64-Wert endet. Die Werte hier dienen der Veranschaulichung:

axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b
1207
C6C4HzGRqDNlbu54LWCvpDX0NcB5DRTmLcjM4u5vWUI=

— axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b q83vATBFAiEAvL8m…(base64)…

• Die ersten vier Bytes des dekodierten Signaturwerts sind der key_hash des Signaturschlüssels, der dir sagt, mit welchem Eintrag in der Menge der Verifizierungsschlüssel du verifizieren musst. Die restlichen Bytes sind eine ASN.1-DER-ECDSA-P-256-Signatur über den SHA-256 des Note-Bodys: jedes Byte vor der Leerzeile, einschließlich des abschließenden Zeilenumbruchs des Bodys.
• Ein Checkpoint kann nach dem Root-Hash zusätzliche Zeilen enthalten. Ignoriere Zeilen, die du nicht verstehst. Sie sind von der Signatur abgedeckt.
• Ignoriere eine Signaturzeile, deren Name nicht dein Origin ist oder deren Schlüssel-Hash du nicht besitzt.
• Cache niemals einen Checkpoint. Ein veralteter Checkpoint verbirgt die aktuelle Größe des Protokolls, sodass neu bereitgestellte Ereignisse als nicht abgedeckt erscheinen.

Die Verifizierungsschlüssel lesen

GET /v1/compliance/transparency_log/keys

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/transparency_log/keys" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

{
  "type": "transparency_log_keys",
  "origin": "axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b",
  "log_keys": [
    {
      "verifier_key": "axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b+<key_hash>+<base64 key>",
      "key_hash": "<8 lowercase hex digits>",
      "fingerprint": "<64 lowercase hex digits>",
      "algorithm": "ecdsa_p256_sha256",
      "public_key": "<base64 DER SubjectPublicKeyInfo>"
    }
  ]
}

Der key_hash deckt nur die Schlüsselbytes ab: Er besteht aus den ersten vier Bytes des SHA-256 über die DER-SubjectPublicKeyInfo, was der Regel entspricht, die die ECDSA-Note-Verifier-Kodierung verwendet. Er ist nicht die namensabhängige Schlüssel-ID, die das grundlegende Signed-Note-Format für Ed25519-Schlüssel definiert, und ändert sich daher nicht mit dem Origin. Eine gültige Signatur durch einen Schlüssel, der unter Veröffentlichte Schlüssel-Fingerprints aufgeführt ist, beweist, dass der Checkpoint vom Transparenzprotokoll-Dienst von Anthropic stammt. Die Origin-Zeile innerhalb des signierten Checkpoints ist das, was ihn an deine Organisation bindet. Deshalb vergleichst du diese Zeile mit dem Origin, den du selbst ableitest.

Schlüssel können rotieren:

• Eine Rotation ist ein Umstieg. Ab einem bestimmten Checkpoint werden neue Checkpoints mit dem neuen Schlüssel signiert.
• Bei einer geplanten Rotation erscheint der neue Schlüssel in log_keys, bevor er irgendetwas signiert, und frühere Schlüssel bleiben aufgeführt. Ein Checkpoint, den du vor der Rotation gespeichert hast, lässt sich daher weiterhin verifizieren.
• Ein Verifizierer kann die Schlüsselmenge bei jedem Lauf abrufen oder lokal vorhalten. Ein Verifizierer, der sie lokal vorhält, liest diesen Endpunkt erneut, wenn er auf eine Signatur trifft, deren key_hash er nicht besitzt.

Veröffentlichte Schlüssel-Fingerprints

Anthropic veröffentlicht hier, außerhalb der API, den Fingerprint jedes Schlüssels, der Checkpoints signiert. So kannst du einen lokal vorgehaltenen Schlüssel mit einer Quelle abgleichen, die der Bereitstellungspfad nicht verändern kann. Der Schlüssel, den du besitzt, kann aus einer früheren GET /keys-Antwort stammen oder aus Tools, die den Schlüssel fest hinterlegen.

Eine geplante Rotation wird auf dieser Seite mindestens 30 Tage angekündigt, bevor der neue Schlüssel seinen ersten Checkpoint signiert. Während dieser Ankündigungsfrist ist der neue Schlüssel in log_keys und in dieser Tabelle mit seinem Umstellungsdatum aufgeführt. Eingestellte Schlüssel bleiben mit ihren Dienstzeiträumen aufgeführt. Ein Schlüssel, der nicht in dieser Tabelle erscheint, ist nicht legitim, unabhängig davon, was GET /keys zurückgibt. Behandle einen Checkpoint, der sich unter keinem aufgeführten Schlüssel verifizieren lässt, als Verifizierungsfehler und melde ihn deinem Anthropic-Ansprechpartner oder dem Anthropic-Support.

axt-verify enthält in jedem Release den aktuellen Schlüssel und liest nie einen Schlüssel aus der API. Jedes Release enthält genau einen Schlüssel. Am Umstellungsdatum beginnt Anthropic, mit dem neuen Schlüssel zu signieren, und veröffentlicht das axt-verify-Release, das ihn enthält. Am selben Datum stellt Anthropic den neuesten Checkpoint jeder Organisation unter dem neuen Schlüssel neu aus, selbst für ein Protokoll, das nicht gewachsen ist. Aktualisiere am Umstellungsdatum. Das Ausführen des alten Releases nach der Umstellung schlägt mit Exit-Status 1 fehl, ebenso das Ausführen des neuen Releases davor. Beide Fehler verschwinden, sobald du das passende Release ausführst. Bei einem Verifizierer, den du selbst pflegst, muss der neue Fingerprint mit seinem Umstellungsdatum vor diesem Datum hinzugefügt werden.

Einen Inklusionsbeweis abrufen

GET /v1/compliance/transparency_log/inclusion?leaf_index={index}

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/transparency_log/inclusion" \
  --data-urlencode "leaf_index=41" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

{
  "type": "transparency_log_inclusion_proof",
  "leaf_index": 41,
  "hashes": [
    "mUdyOWMp0zXIq0CDMvSYDUSBl9yAvnTZzdm51RwWpUM=",
    "yR6tDHkAhKvdQSLqQATVjXOo4GM3FDyiKF2XCKTtMUI=",
    "..."
  ],
  "checkpoint": "axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b\n42\nCsRlS31ITFHrX9GR5XjyPw8n0MkfrB8Yh2UDHl3Lr3E=\n\n— axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b q83vATBEAiB0…(base64)…\n"
}

Es gibt keine Suche nach Aktivitäts-ID. Du besitzt immer den Index, weil er mit dem Ereignis eintrifft, und du prüfst den Beweis gegen die Ereignisbytes, die du aus dem Feed abgerufen hast.

Ein 404 bedeutet, dass der neueste veröffentlichte Checkpoint die angegebene Position nicht abdeckt:

• Für einen Index, den du von einem bereitgestellten Ereignis abgelesen hast, ist dies vorübergehend. Ein abdeckender Checkpoint wird in Kürze veröffentlicht, versuche es also nach einer kurzen Verzögerung erneut.
• Dasselbe 404 beantwortet jede andere nicht abgedeckte Position, etwa einen Index, den der Feed nie bereitgestellt hat. Für eine solche Position gibt es keine Zusage, dass jemals ein abdeckender Checkpoint veröffentlicht wird. Die Antwort sagt nicht, welcher Fall vorliegt.

Ein leaf_index, der fehlt oder keine nicht-negative Ganzzahl ist, gibt 400 zurück.

Einen Konsistenzbeweis abrufen

GET /v1/compliance/transparency_log/consistency?from={size}

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/transparency_log/consistency" \
  --data-urlencode "from=1180" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

{
  "type": "transparency_log_consistency_proof",
  "hashes": [
    "dGw0aPzu2N0pdc4C5ZAvNIbkXF7J6F9ZQLkPpV6v8Vg=",
    "9PSWm1T9RUmhjF6z6YQzB9CW6E2m2n3mK0aVgqf5Qm0=",
    "..."
  ],
  "checkpoint": "axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b\n1207\nC6C4HzGRqDNlbu54LWCvpDX0NcB5DRTmLcjM4u5vWUI=\n\n— axt.anthropic.com/25f6429a-3293-49bf-afed-cb312911554b q83vATBFAiEAvL8m…(base64)…\n"
}

• Der Beweis reicht immer bis zum neuesten veröffentlichten Checkpoint. Diese API stellt nie historische Checkpoints bereit: Du bewahrst diejenigen auf, die dir bereitgestellt werden.
• Ein from, das der Baumgröße des neuesten Checkpoints entspricht, gibt den leeren Beweis zurück.
• Ein gespeicherter Checkpoint mit Baumgröße 0 benötigt keinen Konsistenzbeweis, da jedes Protokoll das leere Protokoll erweitert. Übernimm in diesem Fall direkt den neuesten Checkpoint.
• Ein from kleiner als 1 oder größer als die Baumgröße des neuesten Checkpoints gibt 400 zurück.
• Wenn das Protokoll nicht mehr beweisen kann, dass es einen Checkpoint erweitert, den es einmal für dich signiert hat, behandle das als Verifizierungsfehler, nicht als Nutzungsfehler.

Ein Hash-Tile lesen

GET /v1/compliance/transparency_log/tile/{level}/{index}

Gibt application/octet-stream zurück: aneinandergereihte 32-Byte-SHA-256-Hashes gemäß tlog-tiles. Die Tile-Adressierung folgt exakt tlog-tiles, einschließlich der Pfadgrammatik für {level} und {index}, der Indexform x001/234 für große Bäume und des Suffixes .p/{width} für partielle Tiles. Hash-Tiles sind die Einheit, aus der tlog-tiles-Clients Beweise selbst berechnen.

• Vollständige Tiles sind unveränderlich und werden mit Cache-Control: private, max-age=604800, immutable bereitgestellt.
• Partielle Tiles werden ersetzt, während der Baum wächst, und werden mit Cache-Control: private, no-store bereitgestellt. Sobald ein Tile voll ist, kann eine Anfrage nach seiner früheren partiellen Form 404 zurückgeben, obwohl das vollständige Tile existiert. Der Rückgriff vom partiellen auf das vollständige Tile ist Aufgabe des Clients, wie tlog-tiles es vorgibt, und Standard-Clients tun dies bereits.
• Ein fehlerhaftes level, ein fehlerhafter index oder eine fehlerhafte Breite eines partiellen Tiles gibt 400 zurück. Eine Tile-Position jenseits der aktuellen Baumgröße gibt 404 zurück.

Ein Entry-Bundle lesen

GET /v1/compliance/transparency_log/tile/entries/{index}

Gibt application/octet-stream zurück: aufeinanderfolgende Leaf-Einträge, jeweils mit ihrer Big-Endian-uint16-Länge als Präfix, gemäß tlog-tiles. Entry-Bundles enthalten Ereignis-Klartext: die kanonischen Bytes jedes Access Transparency-Ereignisses. Deshalb erfordert die gesamte Oberfläche den Scope des Activity Feeds. Adressierung, partielle Form, Caching und Fehler sind identisch mit denen der Hash-Tiles.

Das Feld transparency_log_leaf_index an Activity-Feed-Ereignissen

anthropic_access- und cmek_preserve-Ereignisse auf GET /v1/compliance/activities tragen transparency_log_leaf_index, eine Ganzzahl, wann immer das Ereignis ein Leaf hat. Andere Aktivitätstypen tragen es nie.

• Der Schlüssel fehlt, statt null zu sein, wenn das Ereignis kein Leaf hat. Ein robuster Verifizierer behandelt einen fehlenden Schlüssel und einen null-Wert gleich.
• Ein Ereignis wird nur in zwei Fällen ohne transparency_log_leaf_index bereitgestellt. Der erste ist, solange deine Organisation nicht für Access Transparency registriert ist, also vor der Registrierung oder zwischen einer Abmeldung und einer erneuten Registrierung. Der zweite ist, wenn das Ereignis aufgezeichnet wurde, bevor das Protokoll deiner Organisation erstellt wurde. Für eine Organisation, die vor der Einführung des Transparenzprotokolls registriert wurde, umfasst das ihre frühere Historie. Sobald dein Protokoll existiert und solange du registriert bist, wird jedes Ereignis an das Protokoll angehängt, bevor der Feed es bereitstellt. Wenn ein Fehler verhindert, dass der Feed den Index erfährt, verzögert der Feed das Ereignis, statt es ohne Index bereitzustellen. Das Ereignis geht nicht verloren: Es ist bereits im Protokoll und erscheint im Feed, einschließlich Index, sobald der Fehler behoben ist. Ein Ereignis ohne Index ist nicht zu erwarten, wenn es nach der Erstellung deines Protokolls datiert ist und in einen Zeitraum fällt, in dem du registriert warst.
• Ein vorhandener Index ist ein Verweis, kein Beweis. Verifiziere die Inklusion, bevor du das Ereignis als im Protokoll übernommen behandelst. Die Anomalie, die eine Eskalation wert ist, ist ein vorhandener Index, dessen Inklusionsbeweis auch lange nach dem Zeitpunkt, zu dem ein abdeckender Checkpoint hätte veröffentlicht werden sollen, noch nicht abgerufen werden kann.
• Der Index wird zugewiesen, wenn das Ereignis an das Protokoll angehängt wird, und gehört nicht zu den Feldern, aus denen das Leaf besteht.

Wie ein Ereignis zu einem Leaf wird

Ein Leaf-Eintrag ist das Schema-Versionsbyte 0x01, gefolgt von kanonischem JSON aus 11 Feldern. Das JSON folgt RFC 8785 (JSON Canonicalization Scheme), und die Felder werden exakt so aus dem Ereignis übernommen, wie der Activity Feed es bereitstellt:

• id, type, created_at, accessed_at, organization_id, organization_uuid, workspace_id, accessor_department und reason_code
• actor, mit seinen verschachtelten Feldern type und email_address
• resource_details, mit seinen verschachtelten Feldern type, id und parent

Die Regeln:

• Bereitgestellte Felder außerhalb dieser Menge, wie workspace_uuid und transparency_log_leaf_index selbst, werden ignoriert.
• Ein dokumentiertes Feld, das im bereitgestellten Ereignis fehlt, geht als null in das Leaf ein. Ein leerer String unterscheidet sich von null.
• actor und resource_details sind Objekte mit genau ihren dokumentierten Schlüsseln, wenn das bereitgestellte Ereignis sie enthält. Unter Version 0x01 sind actor.email_address und resource_details.parent immer null. Wenn das bereitgestellte Ereignis eines dieser Objekte weglässt oder als null bereitstellt, ist der gesamte Wert im Leaf null, nicht ein Objekt aus null-Feldern. Viele Zugriffsereignisse enthalten kein resource_details.
• String-Werte, einschließlich beider Zeitstempel und reason_code, werden Byte für Byte so übernommen, wie sie bereitgestellt werden. Wenn du einen Zeitstempel aus einer anderen Darstellung neu ableitest, reproduziere die bereitgestellte Darstellung exakt:
  • RFC 3339 UTC mit dem Suffix Z.
  • created_at hat keine Nachkommastellen, wenn seine Mikrosekunden null sind, und andernfalls genau sechs.
  • accessed_at hat null, drei, sechs oder neun Nachkommastellen, die kürzeste Form, die seine Nanosekunden exakt erhält.
• Kanonisches JSON bedeutet sortierte Objektschlüssel, keine bedeutungslosen Leerzeichen und minimales String-Escaping. Im Leaf kommen nirgends Zahlen vor.
• Der Leaf-Hash ist SHA-256(0x00 || entry) gemäß RFC 6962. Innere Knoten werden als SHA-256(0x01 || left || right) gehasht.
• Ein Verifizierer lehnt ein unbekanntes Versionsbyte ab sowie ein 0x01-Leaf, dessen type keiner der beiden Access Transparency-Typen ist. Neue Ereignistypen oder Regeländerungen werden unter einem neuen Versionsbyte ausgeliefert. Bestehende Leaves werden nie neu gehasht.

Zum Beispiel wird dieses Zugriffsereignis, wie der Activity Feed es bereitstellt:

{
  "id": "activity_01GPXmAhizavrUuoXNn3tzeA",
  "type": "anthropic_access",
  "created_at": "2025-07-08T18:40:00Z",
  "accessed_at": "2025-07-08T18:39:58Z",
  "organization_id": "org_015gtSHLz269eTwgrH8NX5yk",
  "organization_uuid": "25f6429a-3293-49bf-afed-cb312911554b",
  "workspace_id": "wrkspc_01PaGUP2rbg1XDh7Z9W1CEpd",
  "workspace_uuid": "b6ce2143-1083-d4a7-247c-17530f55a076",
  "accessor_department": "Trust & Safety",
  "reason_code": "safety_review",
  "actor": { "type": "anthropic_actor", "email_address": null },
  "resource_details": { "type": "message", "id": "msg_01HXAMPLE12345678" },
  "transparency_log_leaf_index": 17
}

zu diesem kanonischen JSON. Es hat genau die 11 dokumentierten Schlüssel, sortiert, in einer Zeile. workspace_uuid und transparency_log_leaf_index fallen weg, und resource_details.parent, das im bereitgestellten Ereignis fehlt, geht als null ein:

{"accessed_at":"2025-07-08T18:39:58Z","accessor_department":"Trust & Safety","actor":{"email_address":null,"type":"anthropic_actor"},"created_at":"2025-07-08T18:40:00Z","id":"activity_01GPXmAhizavrUuoXNn3tzeA","organization_id":"org_015gtSHLz269eTwgrH8NX5yk","organization_uuid":"25f6429a-3293-49bf-afed-cb312911554b","reason_code":"safety_review","resource_details":{"id":"msg_01HXAMPLE12345678","parent":null,"type":"message"},"type":"anthropic_access","workspace_id":"wrkspc_01PaGUP2rbg1XDh7Z9W1CEpd"}

Der Leaf-Eintrag ist das Byte 0x01, gefolgt von diesen UTF-8-Bytes. Sein Leaf-Hash, SHA-256(0x00 || entry), ist in Base64 6ro7vTcFq+sYDZiiGvZaFetUIoMSLig3DGDrCKK1HFU=. Verwende dieses Beispiel als Testvektor für deinen eigenen Kanonisierungscode.

Dein Protokoll verifizieren

Die Verifizierung läuft auf deiner eigenen Infrastruktur. Alles, was die API zurückgibt, ist nicht vertrauenswürdig, bis es gegen zwei Dinge verifiziert ist, die du selbst besitzt. Das erste ist der Origin, den du aus deiner Organisations-UUID ableitest. Das zweite ist der Checkpoint, den du bei deinem letzten Lauf gespeichert hast. Ein vollständiger Verifizierungslauf führt der Reihe nach Folgendes aus:

1. Rufe die Menge der Verifizierungsschlüssel ab. Berechne den Fingerprint jedes Schlüssels selbst als SHA-256 seines Base64-dekodierten public_key. Behalte nur die Schlüssel, deren Fingerprint unter Veröffentlichte Schlüssel-Fingerprints erscheint, zusammen mit dem dortigen Status jedes Schlüssels. Verifiziere einen neu abgerufenen Checkpoint nur unter einem Schlüssel, den diese Tabelle zu diesem Datum als aktuell aufführt. Akzeptiere einen eingestellten Schlüssel nur für einen Checkpoint, den du vor seinem Einstellungsdatum gespeichert hast.
2. Ermittle den neuesten Checkpoint. Rufe ihn beim ersten Lauf vom Checkpoint-Endpunkt ab. Fordere bei jedem späteren Lauf einen Konsistenzbeweis ab der gespeicherten Baumgröße an. Die Antwort enthält den neuesten Checkpoint zusammen mit dem Beweis.
3. Prüfe zuerst die Origin-Zeile des Checkpoints. Vergleiche seine erste Zeile Byte für Byte mit dem Origin, den du abgeleitet hast. Lehne jeden Checkpoint mit abweichendem Origin ab, bevor du irgendetwas anderes tust.
4. Verifiziere die Signatur des Checkpoints. Finde die Signaturzeile, die nach deinem Origin benannt ist und deren erste vier dekodierte Bytes dem key_hash eines aktuell gültigen Schlüssels entsprechen, den du behalten hast. Verifiziere die restlichen Bytes als ECDSA-P-256-Signatur über den SHA-256 des Note-Bodys mit dem public_key dieses Schlüssels. Wenn keine Signaturzeile zu einem solchen Schlüssel passt oder die Signatur sich nicht verifizieren lässt, lehne den Checkpoint ab.
5. Beweise, dass nur angehängt wurde. Wenn die neue Baumgröße kleiner ist als die gespeicherte, schlägt die Verifizierung fehl. Wenn sie gleich ist, müssen die Root-Hashes übereinstimmen. Wenn sie größer ist, verifiziere den RFC-9162-Konsistenzbeweis von deiner gespeicherten Größe und deinem gespeicherten Root-Hash zur neuen Größe und zum neuen Root-Hash.
6. Beweise, dass jedes Ereignis enthalten ist. Lies jedes Access Transparency-Ereignis, das der Activity Feed bereitstellt. Baue für jedes neue Ereignis sein Leaf neu auf, hashe es und rufe seinen Inklusionsbeweis ab. Gehe den Audit-Pfad von deinem Leaf-Hash am Index des Ereignisses aufwärts bis zum Root-Hash des Checkpoints. Eine Abweichung bedeutet, dass das Ereignis, das dir bereitgestellt wurde, nicht das Ereignis ist, das das Protokoll übernommen hat. Die Beweis-Antwort kann einen anderen Checkpoint enthalten als den, den du besitzt. Verknüpfe ihn mit einem Konsistenzbeweis mit deiner Historie, bevor du irgendetwas gegen ihn verifizierst.
7. Prüfe erneut, was du zuvor gesehen hast. Wann immer du ein Ereignis erneut liest, muss es mit demselben Index und denselben Leaf-Bytes bereitgestellt werden wie bei seiner Verifizierung. Kein Ereignis darf den Index verlieren, den es hatte, und solange du registriert bist, darf kein Ereignis neu ohne Index erscheinen. Die Ereignisse, die bei deinem ersten Lauf ohne Index bereitgestellt wurden, sind deine Historie vor dem Protokoll. Ein Lauf, der nur aktuelle Ereignisse erneut liest, prüft nur diese erneut. Um ältere erneut zu prüfen, verifiziere die Kopien, die du aufbewahrt hast (Schritt 8), erneut.
8. Speichere den Checkpoint, den du verifiziert hast, und einen Datensatz jedes Ereignisses, das du verifiziert hast. Sie sind dein Nachweis und dein Ausgangspunkt für den nächsten Lauf.

Mit axt-verify verifizieren

axt-verify ist der Open-Source-Verifizierer von Anthropic für dieses Protokoll. Es ist eine einzelne Go-Binärdatei, die du auf deiner eigenen Infrastruktur ausführst. In jedes Release ist genau ein Protokoll-Signaturschlüssel aus Veröffentlichte Schlüssel-Fingerprints eingebaut, sodass es die API nie fragt, welchem Schlüssel es vertrauen soll. Wenn Anthropic den Schlüssel rotiert, aktualisierst du am Umstellungsdatum auf das Release, das den neuen Schlüssel enthält. axt-verify leitet deinen Origin aus der Organisations-UUID ab, die du mit --org übergibst, also der UUID, die du unter Bevor du beginnst aus der Console entnommen hast. Es lehnt jeden Checkpoint mit abweichender Origin-Zeile ab.

Installiere es mit Go 1.26 oder neuer. Es liest deinen Compliance Access Key aus der Umgebungsvariable ANTHROPIC_COMPLIANCE_ACCESS_KEY, nie aus einem Flag oder einer Datei. Der Befehl run ist derjenige, den du planen solltest:

go install github.com/anthropics/axt-verify/cmd/axt-verify@latest

export ANTHROPIC_COMPLIANCE_ACCESS_KEY="<your Compliance Access Key>"
axt-verify --org 25f6429a-3293-49bf-afed-cb312911554b \
  --state /var/lib/axt-verify/25f6429a-3293-49bf-afed-cb312911554b.state \
  run

Jeder run ruft den neuesten Checkpoint ab und verifiziert seine Signatur und Origin-Zeile. Dann beweist er, dass das Protokoll eine nur angehängte Erweiterung des Checkpoints ist, den der vorherige Lauf gespeichert hat. Als Nächstes blättert er durch die Access Transparency-Ereignisse in deinem Activity Feed. Er beginnt sieben Tage (nach created_at) vor dem neuesten Ereignis, das der vorherige Lauf gelesen hat, sodass verspätet oder in falscher Reihenfolge aufgeführte Ereignisse trotzdem erfasst werden. Er baut das Leaf jedes Ereignisses neu auf, verifiziert einen Inklusionsbeweis dafür und vergleicht jedes Ereignis, das er zuvor verifiziert hat, mit dem, was er damals aufgezeichnet hat. Schließlich speichert er den neuen Checkpoint und seinen Fortschritt in der --state-Datei, von der der nächste Lauf ausgeht. Führe ihn mindestens täglich aus. Stündlich ist angemessen. Führe mit einem Schlüssel einer übergeordneten Organisation eine Instanz pro untergeordneter Organisation aus, jeweils mit eigenem --org und eigener --state-Datei. Die UUID jeder untergeordneten Organisation stammt ebenfalls aus der Claude Console, nicht aus den Compliance-API-Antworten, die du verifizierst. Du findest sie auf der Seite Settings > Organization der untergeordneten Organisation oder in der Liste der Organisationen deiner übergeordneten Organisation in der Console. axt-verify checkpoint führt nur die Schritte für Checkpoint und Nur-Anhängen aus. axt-verify events FILE verifiziert Ereignisse, die du bereits besitzt, etwa die Stichprobe eines Prüfers oder deinen eigenen Export. Es beweist, dass jedes Ereignis in der Datei unter dem aktuellen Checkpoint noch im Protokoll übernommen ist. Es liest weder den Feed noch berührt es die State-Datei.

Aus diesem Zeitfenster ergibt sich eine Einschränkung: run liest nur die Ereignisse der letzten sieben Tage erneut, prüft also kürzlich bereitgestellte Ereignisse erneut (Schritt 7), nicht deine gesamte Historie. Bewahre die Ereignisse auf, die du exportierst (siehe Ein eigenes Checkpoint-Archiv führen). axt-verify events FILE beweist zu jedem späteren Zeitpunkt, dass diese Kopien noch im Protokoll übernommen sind, liest den Feed aber nicht erneut. Um ein älteres Ereignis zu erkennen, das aus dem Feed entfernt oder dort umgeschrieben wurde, exportiere diesen Bereich erneut aus dem Activity Feed und vergleiche ihn mit den Kopien, die du aufbewahrt hast. Du kannst auch den erneuten Export selbst mit axt-verify events FILE verifizieren. Die siebentägige Überlappung ist länger als die Zustellzeit des Feeds von zwei Werktagen, sodass ein verspätet eintreffendes Ereignis trotzdem in das Fenster eines späteren Laufs fällt. Mit --overlap kannst du die Dauer bei Bedarf ändern.

Wenn du stattdessen eine eigene Implementierung benötigst, folge der vorstehenden Checkliste mit einer tlog-tiles-Bibliothek, die ECDSA-Note-Schlüssel unterstützt.

Das Ergebnis interpretieren

axt-verify gibt deinen Origin, die Baumgröße und den Root-Hash des verifizierten Checkpoints, die Baumgröße, bei der die Append-only-Prüfung begonnen hat, sowie die Anzahl der Ereignisse je Ergebnis aus. Übergib --json, um denselben Bericht als ein JSON-Objekt pro Zeile zu erhalten. Jedes Ereignis hat eines von vier Ergebnissen:

• Verified: Das aus dem bereitgestellten Ereignis rekonstruierte Leaf ist am Index des Ereignisses im signierten Protokoll übernommen.
• Pending: Der Index des Ereignisses liegt jenseits des zuletzt veröffentlichten Checkpoints. Das ist für kurze Zeit nach dem Erscheinen eines Ereignisses normal. In run merkt sich axt-verify das Ereignis, verifiziert es bei einem späteren Lauf, sobald ein Checkpoint es abdeckt, und lässt es fehlschlagen, wenn das länger als 24 Stunden dauert. events FILE hat keinen späteren Lauf, um es zu klären, daher wartet es bis zu einer Minute darauf, dass ein abdeckender Checkpoint veröffentlicht wird. Kommt keiner, meldet es das Ereignis als noch nicht abgedeckt und endet mit dem Exit-Status 3. Führe es später erneut aus. Wenn events FILE dasselbe Ereignis bei zwei Läufen im Abstand von mindestens einem Tag als noch nicht abgedeckt meldet, behandle es als Verifizierungsfehler und eskaliere wie bei Exit-Status 1.
• Not logged: Das Ereignis wurde ohne Index bereitgestellt. Ein Ereignis wird nur dann ohne transparency_log_leaf_index bereitgestellt, solange deine Organisation nicht für Access Transparency registriert ist, oder wenn es aufgezeichnet wurde, bevor das Protokoll deiner Organisation erstellt wurde (siehe Das Feld transparency_log_leaf_index an Activity-Feed-Ereignissen). axt-verify meldet solche Ereignisse als nicht protokolliert und lässt den Lauf ihretwegen nicht fehlschlagen. Ein Ereignis ohne Index ist nicht zu erwarten, wenn es nach der Erstellung deines Protokolls datiert ist und in einen Zeitraum fällt, in dem du registriert warst. Prüfe die Liste der nicht protokollierten Ereignisse in der Zusammenfassung des Laufs oder in der --json-Ausgabe, statt dich allein auf den Exit-Status zu verlassen.
• Failed: siehe Exit-Status 1.

Der Exit-Status teilt deinem Scheduler mit, was passiert ist:

• 0: Nichts ist fehlgeschlagen. Nicht protokollierte Ereignisse werden gemeldet, nicht als fehlgeschlagen gewertet, und dasselbe gilt für ausstehende Ereignisse in run.

• 1: Ein Verifizierungsfehler. Dies ist ein Sicherheitsbefund, kein vorübergehender Fehler. Bewahre die State-Datei und die Ausgabe auf und melde es deinem Anthropic-Ansprechpartner oder dem Anthropic-Support. Die Ursachen sind:

  • Ein Checkpoint mit dem falschen Origin oder eine Signatur, die sich mit dem in dein axt-verify-Release eingebauten Schlüssel nicht verifizieren lässt. Vergleiche den key_hash in der Signaturzeile des fehlschlagenden Checkpoints mit Veröffentlichte Schlüssel-Fingerprints. Ist dort ein Schlüssel mit einem Umstellungsdatum aufgeführt, für das du noch nicht aktualisiert hast, brauchst du das passende Release. Ein dort nicht aufgeführter Schlüssel ist ein Sicherheitsbefund, unabhängig davon, welches Release du verwendest. Bei diesem Fehler gibt axt-verify den Schlüssel-Hash jeder Signatur auf dem bereitgestellten Checkpoint sowie den Schlüssel-Hash des Schlüssels aus, dem es vertraut, jeweils als acht Hex-Ziffern. Diese Ausgabe reicht für den Vergleich aus.
  • Ein Checkpoint, der keine wohlgeformte Signed Note ist, zum Beispiel einer, dessen Root-Hash nicht 32 Bytes lang ist.
  • Ein Protokoll, das geschrumpft ist oder nicht nachweisen kann, dass es den von dir gespeicherten Checkpoint erweitert. Die Ausgabe enthält dann beide Checkpoints und den Beweis, sodass der Nachweis für sich allein steht.
  • Zwei signierte Checkpoints für dieselbe Baumgröße mit unterschiedlichen Root-Hashes. Die Ausgabe enthält beide Checkpoints.
  • Eine mit --from übergebene Checkpoint-Datei, deren Signatur sich mit dem in dein axt-verify-Release eingebauten Schlüssel nicht verifizieren lässt, oder eine --from- oder --from-trusted-Datei, deren Origin nicht deiner ist. Für ein Archiv, das vor einer Schlüsselrotation signiert wurde, siehe Ein eigenes Checkpoint-Archiv führen.
  • Ein Inklusionsbeweis, der den signierten Root-Hash für das dir bereitgestellte Ereignis nicht reproduziert.
  • Ein Ereignis innerhalb des Zeitfensters des Laufs, das anders bereitgestellt wurde, als ein früherer Lauf es aufgezeichnet hat: andere Leaf-Bytes, ein anderer Index oder kein Index, wo es einen hatte.
  • Ein Ereignis, das 24 Stunden, nachdem der Lauf es zum ersten Mal gesehen hat, immer noch aussteht.
  • Ein verweigerter Inklusionsbeweis (400, 401 oder 403) für ein Ereignis, das dir der Feed bereitgestellt hat.
  • Ein Inklusionsbeweis, der für einen anderen leaf_index als den angeforderten zurückgegeben wurde.
  • In events FILE ein Ereignis an einem Index, den der neueste Checkpoint bereits zu Beginn der Prüfung abdeckte, für das vor Ablauf der Wartezeit kein Inklusionsbeweis bereitgestellt wird.
  • Ein Ereignis, dessen organization_uuid nicht die Organisations-UUID ist, die du mit --org übergeben hast. Wenn eine übergeordnete Organisation events FILE auf einen Export anwendet, der mehrere untergeordnete Organisationen umfasst, schlägt jedes Ereignis der anderen Organisationen auf diese Weise fehl. Teile den Export daher zuerst nach Organisation auf und verifiziere jeden Teil mit seinem eigenen --org.
  • Dieselbe Aktivitäts-id an zwei verschiedenen Indizes oder zweimal am selben Index mit unterschiedlichem Inhalt, innerhalb eines Laufs oder einer events FILE-Eingabe.
  • Ein Ereignis, dessen Leaf nicht rekonstruiert werden kann: zum Beispiel ein dokumentiertes Feld, das kein String ist, ein Feldname, der zweimal vorkommt, oder ein type, der fehlt oder eine unbekannte Variante eines Access Transparency-Typs ist. events FILE überspringt Zeilen anderer Aktivitätstypen und lässt sie nicht fehlschlagen.

• 2: Ein Nutzungs- oder Konfigurationsfehler. Die Ursachen sind:

  • Ein fehlendes oder fehlerhaftes Flag.
  • Kein ANTHROPIC_COMPLIANCE_ACCESS_KEY.
  • Ein Schlüssel, den die API ablehnt (401 oder 403), bevor irgendein Checkpoint verifiziert wurde.
  • Eine State-Datei, die nicht gelesen werden kann oder zu einem anderen Origin gehört.

• 3: Der Lauf konnte nicht abgeschlossen werden. In run wird das bereits Verifizierte in der State-Datei gespeichert. Führe ihn erneut aus. Die Ursachen sind:

  • Ein Ereignis in events FILE, dessen Index innerhalb der Wartezeit von keinem veröffentlichten Checkpoint abgedeckt wurde. Für ein solches Ereignis gibt das Ergebnis Pending an, wann du mit dem erneuten Ausführen aufhören und eskalieren solltest.
  • Netzwerkfehler, Ratenlimits oder Serverfehler, die länger als die Wiederholungsversuche andauerten.
  • Eine unerwartete Antwort.
  • Eine State- oder --save-Datei, die nicht geschrieben werden konnte.

  Ein Exit-Status 3 mit 404-Antworten ist zu erwarten, bis Anthropic ein erstes Access Transparency-Ereignis für deine Organisation aufgezeichnet hat, da jeder Endpunkt des Transparenzprotokolls 404 zurückgibt, bis dieses Ereignis das Protokoll erstellt. Eskaliere, wenn die Endpunkte des Transparenzprotokolls mehr als ein paar Tage, nachdem dein Activity Feed erstmals ein Access Transparency-Ereignis anzeigt, immer noch 404 zurückgeben, unabhängig davon, ob dieses Ereignis einen transparency_log_leaf_index enthält. Diese Kombination ist nicht zu erwarten. Sobald ein Lauf erfolgreich war, eskaliere einen anhaltenden Exit-Status 3.

Ein eigenes Checkpoint-Archiv führen

Der stärkste Nachweis, den du besitzen kannst, ist deine eigene Aufzeichnung dessen, was das Protokoll an einem bestimmten Tag aussagte. axt-verify --save FILE schreibt den von einem Lauf verifizierten Checkpoint wortgetreu, und --from FILE bei einem späteren Lauf zwingt das Protokoll nachzuweisen, dass es diesen Checkpoint weiterhin erweitert. Archiviere einen gespeicherten Checkpoint in einem Speicher, den du kontrollierst, zum Beispiel täglich. Monate später muss ein Konsistenzbeweis ausgehend von der Baumgröße dieses archivierten Checkpoints immer noch zu dem Checkpoint führen, den das Protokoll bereitstellt, sonst schlägt die Verifizierung fehl. Frühere Schlüssel bleiben nach einer geplanten Rotation in der Menge der Verifizierungsschlüssel aufgeführt, sodass ein archivierter Checkpoint weiterhin verifiziert werden kann. Wenn bei axt-verify der Schlüssel, der einen archivierten Checkpoint signiert hat, inzwischen herausrotiert wurde, übergib dieses Archiv mit --from-trusted statt mit --from. Bewahre auch die Ereignisse auf. Die Access Transparency-Ereignisse, die du aus dem Feed exportierst, sind gültige Eingaben für axt-verify events FILE, das zu jedem späteren Zeitpunkt nachweist, dass diese Kopien unter dem aktuellen Checkpoint weiterhin im Protokoll übernommen sind. Da events FILE den Feed nicht erneut liest, ist dein aufbewahrter Export auch die Referenz, mit der du einen späteren erneuten Export desselben Bereichs vergleichst.

Häufig gestellte Fragen

Verwandte Ressourcen

• Access Transparency
• Den Activity Feed abfragen
• Überblick über die Compliance API
• Fehler
• axt-verify, der Open-Source-Verifizierer von Anthropic für das Transparenzprotokoll
• C2SP tlog-tiles und C2SP signed note, die Wire-Formate für Tiles, Entry-Bundles und Checkpoints
• RFC 9162, die Algorithmen für Merkle-Tree, Inklusionsbeweis und Konsistenzbeweis
• RFC 8785, das für Leaves verwendete JSON Canonicalization Scheme