使用透明度日誌驗證 Access Transparency 事件

了解如何以密碼學方式驗證，沒有任何 Access Transparency 事件在提交至您組織的透明度日誌後遭到移除或竄改。

透明度日誌的運作方式

「Transparency log」（透明度日誌）是一種讓紀錄具備竄改可察覺性的技術。條目只會被附加。每當日誌增長時，其營運者會簽署一份簡短的聲明，稱為「checkpoint」（檢查點），透過 Merkle 樹雜湊對目前為止的所有條目做出承諾。任何保留檢查點的人，之後都可以要求證明目前的日誌仍然包含該檢查點所涵蓋的所有內容，且未經變更、順序相同。因此，對於保留了涵蓋某條目之檢查點的驗證者而言，移除或改寫該條目不可能不被察覺。Certificate Transparency 與 Go 模組校驗和資料庫都建立在相同的技術之上。C2SP tlog-tiles 是一份開放規格，用於以已簽署的檢查點加上靜態、可快取的雜湊與條目圖塊（tile）來提供此類日誌，讓用戶端可以擷取雜湊並自行計算每一個證明。

啟用 Access Transparency 後，Anthropic 會為您的組織維護一份透明度日誌。它是 Access Transparency 事件（anthropic_access 與 cmek_preserve）的僅附加、經密碼學簽署的紀錄。日誌建立後為您的組織記錄的每一個此類事件都會附加到其中。該日誌遵循 C2SP tlog-tiles 格式，因此為該標準打造的工具能夠理解其檢查點、圖塊與證明。

• 每個組織一份日誌。 每個組織的日誌都有固定的 origin 字串：axt.anthropic.com/<your organization UUID>。在組織的整個生命週期中，origin 永遠不會改變。
• 每個新事件都會成為一個葉節點。 當 Access Transparency 事件符合出現在您 Activity Feed 上的條件時，它會先以葉節點（leaf）的形式附加到您的日誌，之後才會在摘要中提供。葉節點是事件已記載欄位的確定性序列化結果。您摘要中的事件帶有 transparency_log_leaf_index，即它在您日誌中從零起算的位置。
• 檢查點對整個歷史做出承諾。 日誌是一棵 Merkle 樹。每當它增長時，Anthropic 都會發布一個已簽署的檢查點：一份簡短的文字文件，說明日誌的 origin、目前大小，以及對每個葉節點做出承諾的根雜湊。每個檢查點都恰好帶有一個來自日誌簽署金鑰的簽章。
• 隨之而來的兩種證明。 「Inclusion proof」（包含證明）顯示特定事件在某檢查點下存在於其位置。「Consistency proof」（一致性證明）顯示較新的檢查點是您所保存之較早檢查點的僅附加延伸，因此兩者之間沒有任何內容被移除或變更。
• 驗證金鑰以頻內方式提供。 驗證者金鑰端點會回傳簽署檢查點的公開金鑰。在計畫性的金鑰輪替中，新金鑰會在開始簽署之前加入該清單，而較早的金鑰仍會保留在清單中。因此，您已持有的檢查點仍可持續通過驗證。

透明度日誌能證明什麼

• 您所持有事件的葉節點欄位（列於事件如何成為葉節點）逐位元組與 Anthropic 提交至日誌的內容相同。
• 您組織的日誌只會增長。如果已提交至日誌的事件之後在日誌中被刪除或改寫，針對您所持有檢查點的驗證就會失敗。如果提供給您的歷史與先前提供給您的不同，驗證也會失敗。
• 新條目只能被附加。事件無法被插入您已驗證過的歷史中。

它無法證明或改變什麼

• 它無法證明每一次存取都有被記錄，也無法證明已記錄的事件準確描述了該次存取。它只能證明 Anthropic 提交至日誌的內容自那之後未曾變更。
• 它不會改變 Access Transparency 涵蓋的範圍或事件送達的時間。
• 葉節點以外的已提供欄位，例如 workspace_uuid 以及之後新增的任何欄位，不在證明的涵蓋範圍內。
• 包含證明是針對提供給您的事件。它本身無法證明摘要列出了日誌所持有的每一個葉節點。日誌的條目套件包含每一個葉節點，因此在需要時，您可以直接讀取完整的已提交事件集合。
• 事件上出現 transparency_log_leaf_index 只是一個指標，而非證明。在將事件視為已提交至日誌之前，請務必驗證其包含性。
• 防範歷史遭改寫的保護來自您所保留的檢查點。檢查點由已發布的金鑰指紋中所列金鑰簽署，證明它來自 Anthropic 的日誌。從您上次保存的檢查點出發的一致性證明，則證明您已觀察到的歷史只有增長。

開始之前

您需要：

• 具有 read:compliance_activities 範圍的 Compliance Access Key，與您用於 Activity Feed 的金鑰與範圍相同。父組織金鑰可以在每個請求中指定子組織，以讀取每個已註冊子組織的日誌。
• 您組織的 UUID。請在 Claude Console 的 Settings > Organization 中找到它。它與 Activity Feed 以 organization_uuid 提供的值相同，但請從 Console 取得。這個值是讓檢查點屬於您的關鍵，因此它不得來自您正在驗證的 API。您可以從它推導出日誌的 origin：axt.anthropic.com/<organization UUID>。請自行推導此字串，不要從 API 回應中讀取。
• 一個可持久保存您上次驗證之檢查點的地方。這個已保存的檢查點，能將「日誌今天是一致的」轉變為「自您開始監看以來，日誌一直是一致的」。

時間

• 事件： Access Transparency 事件會在存取發生後兩個工作天內出現在您的 Activity Feed 上。事件只有在符合提供條件後才會進入日誌，因此日誌絕不會提早揭露事件。由於日誌是在摘要提供事件之前寫入的，條目可能會在其事件出現在您的摘要中之前短暫出現在日誌中。這段落差並非不一致。
• 檢查點： 每當您的日誌增長時，就會發布新的檢查點。
• 包含證明： 新提供事件的證明，會在涵蓋該事件位置的檢查點發布後提供，通常在事件出現後很快就會發布。如果您提早請求，會收到 404，請稍候再重試。
• 驗證頻率： 請至少每天執行一次驗證。每小時一次是合理的。
• 取消註冊： 如果您的組織停止使用 Access Transparency，不會刪除任何內容。您的日誌仍可透過相同的端點讀取。如果之後再次啟用 Access Transparency，會延續同一份日誌。

保留與刪除

• 透明度日誌： Anthropic 不會從您的日誌中刪除條目，日誌也沒有到期日。即使您的組織停止使用 Access Transparency，或在您的組織被刪除之後，日誌仍會保留，因為移除條目正是日誌存在所要偵測的變更。條目套件保存每個事件的葉節點欄位，因此這些欄位會與日誌保留同樣長的時間。
• Activity Feed： Activity Feed 上的 Access Transparency 事件遵循摘要的保留政策。活動會保留 6 年。請參閱查詢 Activity Feed。
• 您無法刪除： 透明度日誌端點為唯讀。無法刪除或修改條目。

透明度日誌端點

在 https://api.anthropic.com/v1/compliance/transparency_log/ 下提供六個唯讀端點：

檢查點、圖塊與條目套件完全遵循 C2SP tlog-tiles 傳輸格式。兩個證明端點是為了方便而提供：每個證明也都可以從圖塊計算出來，因此您永遠不必信任證明端點的輸出。您會針對已簽署的檢查點驗證它所回傳的雜湊。

驗證與範圍

如同每個 Compliance API 請求，請在 x-api-key 標頭中傳送您的 Compliance Access Key，並附上 anthropic-version 標頭（請參閱版本控制）。您的組織必須已啟用 Compliance API。

沒有獨立的透明度日誌權限。任何能讀取您組織 Activity Feed 的金鑰（無論屬於您的組織或其父組織），都能讀取您的整份日誌，包括其條目套件中的事件欄位。

每個請求恰好讀取一個組織的日誌：

• 組織層級的金鑰讀取其所屬組織的日誌。organization_id 查詢參數為選用。若有提供，它必須指定該金鑰所屬的組織。
• 父組織層級的金鑰必須傳入 organization_id，指定一個子組織。
• organization_id 接受 org_... 標記 ID 或組織 UUID。

404 表示沒有此金鑰可讀取的日誌。超出金鑰範圍的組織、不存在的組織，以及日誌尚未建立的組織，刻意設計為無法區分。已停止使用 Access Transparency 之組織的日誌不屬於此情況：它會持續被提供。

錯誤

所有端點（包括文字與二進位端點）的錯誤都使用標準的 Compliance API JSON 錯誤封裝。請參閱錯誤以了解封裝格式與共用錯誤類型。

快取

回應僅可由發出請求的用戶端快取。Cache-Control 一律包含 private，且回應帶有 Vary: x-api-key。請勿在這些端點前放置共用快取。完整圖塊與完整條目套件永遠不會改變，並以 Cache-Control: private, max-age=604800, immutable 提供。其他所有內容，包括檢查點、證明、金鑰、部分圖塊與錯誤，都以 Cache-Control: private, no-store 提供。

讀取最新的檢查點

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"

回應為 text/plain：一份 C2SP signed note。本文各行依序為 origin、十進位的樹大小，以及 base64 根雜湊。接著是一個空白行，然後是簽章行，它以 em dash（U+2014）開頭，指明 origin，並以 base64 值結尾。此處的值僅供說明：

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

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

• 解碼後簽章值的前四個位元組是簽署金鑰的 key_hash，它告訴您要使用驗證者金鑰集中的哪個條目進行驗證。其餘位元組是對 note 本文之 SHA-256 的 ASN.1 DER ECDSA P-256 簽章：即空白行之前的每個位元組，包括本文結尾的換行字元。
• 檢查點可以在根雜湊之後帶有額外的行。請忽略您不理解的行。它們都在簽章的涵蓋範圍內。
• 請忽略名稱不是您的 origin，或其金鑰雜湊不在您持有範圍內的簽章行。
• 切勿快取檢查點。過時的檢查點會隱藏日誌目前的大小，使新提供的事件看起來未被涵蓋。

讀取驗證者金鑰

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>"
    }
  ]
}

key_hash 只涵蓋金鑰位元組：它是 DER SubjectPublicKeyInfo 之 SHA-256 的前四個位元組，這是 ECDSA note-verifier 編碼所使用的規則。它不是基礎 signed-note 格式為 Ed25519 金鑰定義的、依名稱而定的金鑰 ID，因此不會隨 origin 改變。由已發布的金鑰指紋中所列金鑰產生的有效簽章，證明該檢查點來自 Anthropic 的透明度日誌服務。已簽署檢查點內的 origin 行，才是將它與您的組織綁定的關鍵。這就是為什麼您要將該行與您自行推導的 origin 進行比對。

金鑰可能會輪替：

• 輪替是一次切換。從某個檢查點開始，新的檢查點會由新金鑰簽署。
• 在計畫性輪替中，新金鑰會在簽署任何內容之前出現在 log_keys 中，而較早的金鑰仍會保留在清單中。因此，您在輪替前保存的檢查點仍可持續通過驗證。
• 驗證者可以在每次執行時擷取金鑰集，或在本機保存。在本機保存金鑰集的驗證者，在遇到其 key_hash 不在持有範圍內的簽章時，會重新讀取此端點。

已發布的金鑰指紋

Anthropic 在此處（API 之外）發布每個簽署檢查點之金鑰的指紋。這讓您可以將本機持有的金鑰與提供路徑無法竄改的來源進行比對。您持有的金鑰可能來自較早的 GET /keys 回應，或來自固定金鑰的工具。

計畫性輪替會在新金鑰簽署其第一個檢查點前至少 30 天於本頁公告。在該通知期間，新金鑰會連同其切換日期列於 log_keys 與此表格中。已退役的金鑰會連同其服務日期保留在清單中。未出現在此表格中的金鑰都不是合法的，無論 GET /keys 回傳什麼。請將無法在任何已列出金鑰下通過驗證的檢查點視為驗證失敗，並向您的 Anthropic 客戶代表或 Anthropic 支援回報。

axt-verify 在每個版本中都內建目前的金鑰，且從不從 API 讀取金鑰。每個版本恰好內建一把金鑰。在切換日期當天，Anthropic 會開始使用新金鑰簽署，並發布內建該金鑰的 axt-verify 版本。同一天，Anthropic 會以新金鑰重新簽發每個組織的最新檢查點，即使日誌沒有增長也一樣。請在切換日期當天升級。在切換後執行舊版本會以結束狀態 1 失敗，在切換前執行新版本也是如此。只要執行相符的版本，任一失敗都會消除。若您自行維護驗證者，則需要在該日期之前加入新指紋及其切換日期。

擷取包含證明

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"
}

無法依活動 ID 查詢。您一定持有索引，因為它隨事件一起送達，而您會針對從摘要擷取的事件位元組檢查證明。

404 表示最新發布的檢查點未涵蓋所提供的位置：

• 對於您從已提供事件上讀取的索引，這是暫時性的。涵蓋的檢查點很快就會發布，因此請稍候再重試。
• 相同的 404 也會回應任何其他未涵蓋的位置，例如摘要從未提供過的索引。對於此類位置，不保證會發布涵蓋它的檢查點。回應不會說明您屬於哪種情況。

leaf_index 遺失或不是非負整數時，會回傳 400。

擷取一致性證明

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"
}

• 證明一律延伸至最新發布的檢查點。此 API 從不提供歷史檢查點：您需要自行保留提供給您的檢查點。
• from 等於最新檢查點的樹大小時，會回傳空證明。
• 持有的檢查點樹大小為 0 時不需要一致性證明，因為每份日誌都是空日誌的延伸。在這種情況下，請直接採用最新的檢查點。
• from 小於 1，或大於最新檢查點的樹大小時，會回傳 400。
• 如果日誌無法再證明它延伸了曾經為您簽署的檢查點，請將其視為驗證失敗，而非使用錯誤。

讀取雜湊圖塊

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

回傳 application/octet-stream：依 tlog-tiles 串接的 32 位元組 SHA-256 雜湊。圖塊定址完全遵循 tlog-tiles，包括 {level} 與 {index} 路徑語法、大型樹使用的 x001/234 索引形式，以及部分圖塊後綴 .p/{width}。雜湊圖塊是 tlog-tiles 用戶端自行計算證明的單位。

• 完整圖塊不可變，並以 Cache-Control: private, max-age=604800, immutable 提供。
• 部分圖塊會隨著樹的增長而被取代，並以 Cache-Control: private, no-store 提供。一旦圖塊填滿，即使完整圖塊存在，請求其較早的部分形式也可能回傳 404。從部分圖塊退回至完整圖塊是用戶端的工作，如 tlog-tiles 所規定，標準用戶端已經會這麼做。
• level、index 或部分圖塊寬度格式錯誤時，會回傳 400。超出目前樹大小的圖塊位置會回傳 404。

讀取條目套件

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

回傳 application/octet-stream：依 tlog-tiles 排列的連續葉節點條目，每個條目前綴其 big-endian uint16 長度。條目套件包含事件明文：即每個 Access Transparency 事件的標準位元組。這就是為什麼整個介面都需要 Activity Feed 的範圍。定址、部分形式、快取與錯誤都與雜湊圖塊相同。

Activity Feed 事件上的 transparency_log_leaf_index 欄位

GET /v1/compliance/activities 上的 anthropic_access 與 cmek_preserve 事件，只要該事件有葉節點，就會帶有整數 transparency_log_leaf_index。其他活動類型從不帶有此欄位。

• 當事件沒有葉節點時，該鍵會不存在，而非 null。 穩健的驗證者會以相同方式處理不存在的鍵與 null 值。
• 事件只有在兩種情況下會在沒有 transparency_log_leaf_index 的情況下被提供。 第一種是您的組織未註冊 Access Transparency 期間，也就是註冊之前，或在取消註冊與重新註冊之間。第二種是事件在您組織的日誌建立之前就已記錄。對於在透明度日誌推出之前就已註冊的組織，這包括其較早的歷史。一旦您的日誌存在且您處於註冊狀態，每個事件都會在摘要提供之前附加到日誌。如果發生故障導致摘要無法得知索引，摘要會延遲該事件，而不是在沒有索引的情況下提供它。事件不會遺失：它已經在日誌中，並會在故障修復後連同索引出現在摘要中。若事件的日期晚於您的日誌建立時間，且落在您處於註冊狀態的期間內，則不應出現沒有索引的事件。
• 存在的索引只是指標，而非證明。 在將事件視為已提交至日誌之前，請先驗證其包含性。值得呈報的異常，是存在索引但在涵蓋的檢查點早應發布之後很久，仍無法擷取其包含證明。
• 索引是在事件附加到日誌時指派的，並不屬於構成葉節點的欄位。

事件如何成為葉節點

葉節點條目是結構描述版本位元組 0x01，後接 11 個欄位的標準 JSON。該 JSON 遵循 RFC 8785（JSON Canonicalization Scheme），欄位完全依照 Activity Feed 提供事件的方式取得：

• id、type、created_at、accessed_at、organization_id、organization_uuid、workspace_id、accessor_department 與 reason_code
• actor，及其巢狀的 type 與 email_address
• resource_details，及其巢狀的 type、id 與 parent

規則如下：

• 該集合以外的已提供欄位，例如 workspace_uuid 以及 transparency_log_leaf_index 本身，都會被忽略。
• 已提供事件省略的已記載欄位，會以 null 進入葉節點。空字串與 null 不同。
• 當已提供事件帶有 actor 與 resource_details 時，它們是恰好具有其已記載鍵的物件。在版本 0x01 下，actor.email_address 與 resource_details.parent 一律為 null。當已提供事件省略其中一個物件或將其提供為 null 時，整個值在葉節點中為 null，而非由 null 欄位組成的物件。許多存取事件不帶有 resource_details。
• 字串值，包括兩個時間戳記與 reason_code，都逐位元組依提供的內容取得。如果您從其他表示法重新推導時間戳記，請完全重現所提供的呈現方式：
  • 帶有 Z 後綴的 RFC 3339 UTC。
  • created_at 在其微秒為零時沒有小數位數，否則恰好有六位。
  • accessed_at 有零、三、六或九位小數位數，取能精確保留其奈秒的最短位數。
• 標準 JSON 表示物件鍵已排序、沒有無意義的空白，且字串跳脫最少化。葉節點中任何地方都不會出現數字。
• 葉節點雜湊為 RFC 6962 的 SHA-256(0x00 || entry)。內部節點的雜湊為 SHA-256(0x01 || left || right)。
• 驗證者會拒絕未知的版本位元組，以及 type 不屬於兩種 Access Transparency 類型之一的 0x01 葉節點。新的事件類型或規則變更會以新的版本位元組推出。現有的葉節點永遠不會重新雜湊。

例如，Activity Feed 所提供的這個存取事件：

{
  "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
}

會成為以下標準 JSON。它恰好具有 11 個已記載的鍵，已排序，位於同一行。workspace_uuid 與 transparency_log_leaf_index 被移除，而已提供事件中不存在的 resource_details.parent 則以 null 進入：

{"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"}

葉節點條目是位元組 0x01，後接這些 UTF-8 位元組。其葉節點雜湊 SHA-256(0x00 || entry) 以 base64 表示為 6ro7vTcFq+sYDZiiGvZaFetUIoMSLig3DGDrCKK1HFU=。請將此範例作為您自己標準化程式碼的測試向量。

驗證您的日誌

驗證在您自己的基礎架構上執行。API 回傳的所有內容在針對您自行持有的兩樣東西驗證之前，都是不受信任的。第一樣是您從組織 UUID 推導出的 origin。第二樣是您在上次執行時保存的檢查點。完整的驗證執行會依序進行以下步驟：

1. 擷取驗證者金鑰集。自行計算每把金鑰的指紋，即其 base64 解碼後 public_key 的 SHA-256。只保留指紋出現在已發布的金鑰指紋中的金鑰，並一併記錄每把金鑰在該處的狀態。只在該表格列為當日目前金鑰的金鑰下驗證新擷取的檢查點。只有對於您在退役日期之前保存的檢查點，才接受已退役的金鑰。
2. 確立最新的檢查點。第一次執行時，從檢查點端點擷取。之後每次執行時，從您保存的樹大小請求一致性證明。回應會連同證明一起帶有最新的檢查點。
3. 先檢查檢查點的 origin 行。將其第一行與您推導出的 origin 逐位元組比對。在進行任何其他動作之前，拒絕任何 origin 不同的檢查點。
4. 驗證檢查點的簽章。找出以您的 origin 命名、且解碼後前四個位元組等於您所保留之目前有效金鑰 key_hash 的簽章行。使用該金鑰的 public_key，將其餘位元組作為對 note 本文之 SHA-256 的 ECDSA P-256 簽章進行驗證。如果沒有簽章行與此類金鑰相符，或簽章未通過驗證，請拒絕該檢查點。
5. 證明僅附加。如果新的樹大小小於您保存的大小，則失敗。如果相等，根雜湊必須相符。如果較大，請驗證從您保存的大小與根雜湊到新大小與根雜湊的 RFC 9162 一致性證明。
6. 證明每個事件都已包含。讀取 Activity Feed 提供的每個 Access Transparency 事件。對於每個新事件，重建其葉節點、計算雜湊，並擷取其包含證明。從事件索引處的葉節點雜湊沿著稽核路徑往上走到檢查點的根雜湊。不相符表示提供給您的事件並非日誌所提交的事件。證明回應可能帶有與您所持有不同的檢查點。在針對它驗證任何內容之前，請先以一致性證明將它連結到您的歷史中。
7. 重新檢查您先前看過的內容。每當您再次讀取某個事件時，它必須以與您驗證時相同的索引與相同的葉節點位元組提供。任何事件都不得失去其原有的索引，且在您處於註冊狀態期間，任何事件都不得在沒有索引的情況下新出現。第一次執行時在沒有索引的情況下提供的事件，是您日誌建立前的歷史。只重新讀取近期事件的執行，只會重新檢查那些事件。若要重新檢查較舊的事件，請再次驗證您保留的副本（步驟 8）。
8. 保存您驗證過的檢查點，以及您驗證過之每個事件的紀錄。它們是您的證據，也是下次執行的起點。

使用 axt-verify 進行驗證

axt-verify 是 Anthropic 為此日誌提供的開源驗證者。它是一個在您自己的基礎架構上執行的單一 Go 二進位檔。每個版本都恰好內建一把來自已發布的金鑰指紋的日誌簽署金鑰，因此它從不詢問 API 該信任哪把金鑰。當 Anthropic 輪替金鑰時，您需要在切換日期當天升級到內建新金鑰的版本。axt-verify 會從您以 --org 傳入的組織 UUID 推導出您的 origin，也就是您在開始之前從 Console 取得的 UUID。它會拒絕任何 origin 行不同的檢查點。

請使用 Go 1.26 或更新版本安裝。它從 ANTHROPIC_COMPLIANCE_ACCESS_KEY 環境變數讀取您的 Compliance Access Key，從不從旗標或檔案讀取。run 命令是要排程執行的命令：

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

每次 run 都會擷取最新的檢查點，並驗證其簽章與 origin 行。接著它會證明日誌是上次執行所保存之檢查點的僅附加延伸。然後它會逐頁讀取您 Activity Feed 上的 Access Transparency 事件。它從上次執行所讀取之最新事件的七天前（依 created_at）開始，以便仍能擷取到延遲列出或順序錯亂的事件。它會重建每個事件的葉節點、驗證其包含證明，並將先前驗證過的任何事件與當時的紀錄進行比對。最後，它會將新的檢查點與其進度保存到 --state 檔案，下次執行會從該處開始。請至少每天執行一次。每小時一次是合理的。使用父組織金鑰時，請為每個子組織執行一份副本，每份都有自己的 --org 與 --state 檔案。每個子組織的 UUID 也來自 Claude Console，而非來自您正在驗證的 Compliance API 回應。請在子組織的 Settings > Organization 頁面，或在 Console 中父組織的組織清單中找到它。axt-verify checkpoint 只執行檢查點與僅附加步驟。axt-verify events FILE 會驗證您已持有的事件，例如稽核人員的樣本或您自己的匯出資料。它會證明檔案中的每個事件在目前的檢查點下仍已提交至日誌。它不會讀取摘要，也不會動到狀態檔案。

該時間窗口帶來一項限制：run 只會重新讀取最近七天的事件，因此它只會重新檢查近期提供的事件（步驟 7），而非您的整個歷史。請保留您匯出的事件（請參閱保留您自己的檢查點封存）。axt-verify events FILE 可在之後任何日期證明這些副本仍已提交至日誌，但它不會重新讀取摘要。若要偵測較舊的事件是否已從摘要中移除或在摘要中遭改寫，請從 Activity Feed 重新匯出該範圍，並與您保留的副本進行比對。您也可以使用 axt-verify events FILE 驗證重新匯出的資料本身。七天的重疊期間比摘要兩個工作天的送達時間更長，因此延遲送達的事件仍會落在之後某次執行的時間窗口內。如有需要，可使用 --overlap 變更此期間。

如果您需要改用自己的實作，請使用支援 ECDSA note 金鑰的 tlog-tiles 函式庫，並遵循前述的檢查清單。

解讀結果

axt-verify 會印出您的 origin、其所驗證之檢查點的樹大小與根雜湊、僅附加檢查起始的樹大小，以及依結果分類的事件計數。傳入 --json 可將相同的報告以每行一個 JSON 物件的形式輸出。每個事件會有以下四種結果之一：

• 已驗證（Verified）： 從所提供事件重建的葉節點，已提交至簽署日誌中該事件的索引位置。
• 待處理（Pending）： 事件的索引超出最新發布的檢查點。在事件出現後的短時間內，這是正常現象。在 run 中，axt-verify 會記住該事件，待檢查點涵蓋它後於之後的執行中驗證它，若耗時超過 24 小時則判定為失敗。events FILE 沒有後續執行可以處理它，因此會等待最多一分鐘，讓涵蓋它的檢查點發布。若沒有檢查點發布，它會將該事件回報為尚未涵蓋，並以結束狀態 3 結束。請稍後再執行一次。若 events FILE 在相隔至少一天的兩次執行中都將同一事件回報為尚未涵蓋，請將其視為驗證失敗，並比照結束狀態 1 進行呈報。
• 未記錄（Not logged）： 該事件在提供時沒有索引。只有在您的組織尚未註冊 Access Transparency 時，或事件記錄於您組織的日誌建立之前時，事件才會在沒有 transparency_log_leaf_index 的情況下提供（請參閱 Activity Feed 事件上的 transparency_log_leaf_index 欄位）。axt-verify 會將此類事件回報為未記錄，且不會因此使執行失敗。若事件的日期晚於您的日誌建立時間，且落在您已註冊的期間內，則不應出現沒有索引的事件。請檢閱執行摘要或 --json 輸出中的未記錄清單，而不要僅依賴結束狀態。
• 失敗（Failed）： 請參閱結束狀態 1。

結束狀態會告訴您的排程器發生了什麼事：

• 0： 沒有任何失敗。未記錄的事件會被回報而非判定失敗，run 中的待處理事件也是如此。

• 1： 驗證失敗。這是一項安全性發現，而非暫時性錯誤。請保留狀態檔案與輸出，並回報給您的 Anthropic 客戶代表或 Anthropic 支援。原因包括：

  • 檢查點的 origin 錯誤，或簽章無法以您 axt-verify 版本內建的金鑰驗證。請將失敗檢查點簽章行上的 key_hash 與已發布的金鑰指紋進行比對。若該處列出的金鑰帶有您尚未因應升級的切換日期，表示您需要對應的版本。若金鑰未列於該處，無論您執行哪個版本，都屬於安全性發現。發生此失敗時，axt-verify 會印出所提供檢查點上每個簽章的金鑰雜湊，以及其所信任金鑰的金鑰雜湊，各為八個十六進位數字。這些輸出足以進行比對。
  • 檢查點不是格式正確的 signed note（簽署註記），例如根雜湊不是 32 位元組。
  • 日誌縮小了，或無法證明其延伸自您所保存的檢查點。此時輸出會包含兩個檢查點與證明，因此證據本身即可成立。
  • 同一樹大小有兩個根雜湊不同的簽署檢查點。輸出會包含這兩個檢查點。
  • 以 --from 傳入的檢查點檔案，其簽章無法以您 axt-verify 版本內建的金鑰驗證，或 --from 或 --from-trusted 檔案的 origin 不屬於您。對於在金鑰輪替前簽署的封存，請參閱保留您自己的檢查點封存。
  • 包含證明無法為您所收到的事件重現簽署的根雜湊。
  • 執行時間範圍內的事件，其提供方式與先前執行所記錄的不同：葉節點位元組不同、索引不同，或原本有索引卻沒有索引。
  • 事件在執行首次看到它的 24 小時後仍處於待處理狀態。
  • 對於摘要提供給您的事件，包含證明遭到拒絕（400、401 或 403）。
  • 傳回的包含證明所對應的 leaf_index 與所請求的不同。
  • 在 events FILE 中，某事件的索引在檢查開始時已被最新檢查點涵蓋，但在等待時間結束前未提供任何包含證明。
  • 事件的 organization_uuid 不是您以 --org 傳入的組織 UUID。當父組織對涵蓋多個子組織的匯出執行 events FILE 時，其他每個組織的事件都會以此方式失敗，因此請先依組織拆分匯出，再以各自的 --org 驗證每個部分。
  • 在單次執行或單一 events FILE 輸入中，同一活動 id 出現在兩個不同的索引，或在同一索引出現兩次但內容不同。
  • 事件的葉節點無法重建：例如，某個已記載的欄位不是字串、某個欄位名稱出現兩次，或 type 缺失或是 Access Transparency 類型中無法辨識的變體。events FILE 會略過其他活動類型的資料列，且不會將其判定為失敗。

• 2： 使用方式或設定錯誤。原因包括：

  • 旗標缺失或格式錯誤。
  • 沒有 ANTHROPIC_COMPLIANCE_ACCESS_KEY。
  • 在任何檢查點驗證之前，API 拒絕了金鑰（401 或 403）。
  • 狀態檔案無法讀取，或屬於其他 origin。

• 3： 執行無法完成。在 run 中，已驗證的內容會保存至狀態檔案。請再次執行。原因包括：

  • events FILE 中某事件的索引在等待時間內未被任何已發布的檢查點涵蓋。對於此類事件，待處理結果說明了何時應停止重新執行並進行呈報。
  • 網路錯誤、速率限制或伺服器錯誤持續超過重試次數。
  • 非預期的回應。
  • 狀態檔案或 --save 檔案無法寫入。

  在 Anthropic 為您的組織記錄第一個 Access Transparency 事件之前，出現帶有 404 回應的結束狀態 3 是預期中的情況，因為在該事件建立日誌之前，每個透明度日誌端點都會傳回 404。若在您的 Activity Feed 首次顯示 Access Transparency 事件的數天後，透明度日誌端點仍傳回 404，無論該事件是否帶有 transparency_log_leaf_index，都請進行呈報。這種組合並非預期情況。一旦執行成功過，若結束狀態 3 持續出現，請進行呈報。

保留您自己的檢查點封存

您所能持有的最有力證據，是您自己對日誌在特定日期內容的記錄。axt-verify --save FILE 會逐字寫入執行所驗證的檢查點，而在之後的執行中使用 --from FILE 會要求日誌證明其仍延伸自該檢查點。請將保存的檢查點封存在您所控制的儲存空間中，例如每日一次。數個月後，從該封存檢查點之樹大小出發的 一致性證明仍必須能導向日誌所提供的任何檢查點，否則驗證就會失敗。在計畫性輪替後，先前的金鑰仍會列於驗證者金鑰集中，因此封存的檢查點仍可持續驗證。使用 axt-verify 時，若簽署封存檢查點的金鑰已被輪替淘汰，請以 --from-trusted 而非 --from 傳入該封存。也請保留事件。您從摘要匯出的 Access Transparency 事件是 axt-verify events FILE 的有效輸入，可在之後任何日期證明這些副本在目前的檢查點下仍已提交至日誌。由於 events FILE 不會重新讀取摘要，您保留的匯出也是您用來比對之後重新匯出同一範圍時的參考依據。

常見問題

相關資源

• Access Transparency
• 查詢 Activity Feed
• Compliance API 概覽
• 錯誤
• axt-verify，Anthropic 針對透明度日誌的開源驗證者
• C2SP tlog-tiles 與 C2SP signed note，圖塊、條目套件與檢查點的傳輸格式
• RFC 9162，Merkle 樹、包含證明與一致性證明演算法
• RFC 8785，用於葉節點的 JSON Canonicalization Scheme（JSON 正規化方案）