투명성 로그로 Access Transparency 이벤트 검증하기

Access Transparency 이벤트가 조직의 투명성 로그에 커밋된 후 제거되거나 변경되지 않았음을 암호학적으로 검증하는 방법을 알아봅니다.

투명성 로그의 작동 방식

"Transparency log"(투명성 로그)는 기록을 변조 감지 가능하게 만드는 기법입니다. 항목은 오직 추가만 됩니다. 로그가 커질 때마다 운영자는 "checkpoint"(체크포인트)라고 하는 짧은 문장에 서명하며, 이 체크포인트는 Merkle 트리 해시를 통해 지금까지의 모든 항목을 커밋합니다. 체크포인트를 보관한 사람은 누구나 나중에 현재 로그가 해당 체크포인트가 포함했던 모든 것을 변경 없이 같은 순서로 여전히 포함하고 있다는 증명을 요구할 수 있습니다. 따라서 항목을 제거하거나 다시 쓰면, 해당 항목을 포함하는 체크포인트를 보관한 검증자가 반드시 알아차리게 됩니다. Certificate Transparency와 Go 모듈 체크섬 데이터베이스도 같은 기법을 기반으로 구축되었습니다. C2SP tlog-tiles는 이러한 로그를 서명된 체크포인트와 해시 및 항목으로 구성된 정적이고 캐시 가능한 타일로 제공하기 위한 개방형 사양으로, 클라이언트가 해시를 가져와 모든 증명을 직접 계산할 수 있게 합니다.

Access Transparency가 활성화되면 Anthropic은 조직을 위한 투명성 로그를 유지 관리합니다. 이는 Access Transparency 이벤트(anthropic_access 및 cmek_preserve)에 대한 추가 전용(append-only)의 암호학적으로 서명된 기록입니다. 로그가 생성된 후 조직에 대해 기록된 이러한 이벤트는 각각 로그에 추가됩니다. 로그는 C2SP tlog-tiles 형식을 따르므로, 해당 표준용으로 구축된 도구가 로그의 체크포인트, 타일, 증명을 이해할 수 있습니다.

• 조직당 하나의 로그. 각 조직의 로그에는 고정된 origin 문자열 axt.anthropic.com/<your organization UUID>가 있습니다. origin은 조직이 존재하는 동안 절대 변경되지 않습니다.
• 모든 새 이벤트는 리프가 됩니다. Access Transparency 이벤트가 Activity Feed에 표시될 자격을 갖추면, 먼저 로그에 리프로 추가된 후에야 피드에 제공됩니다. 리프는 이벤트의 문서화된 필드를 결정론적으로 직렬화한 것입니다. 피드의 이벤트에는 로그 내 0부터 시작하는 위치인 transparency_log_leaf_index가 포함됩니다.
• 체크포인트는 전체 기록을 커밋합니다. 로그는 Merkle 트리입니다. 로그가 커질 때마다 Anthropic은 서명된 체크포인트를 게시합니다. 체크포인트는 로그의 origin, 현재 크기, 모든 리프를 커밋하는 루트 해시를 명시하는 짧은 텍스트 문서입니다. 각 체크포인트에는 로그 서명 키의 서명이 정확히 하나 포함됩니다.
• 두 가지 증명이 뒤따릅니다. "Inclusion proof"(포함 증명)는 특정 이벤트가 체크포인트 아래 해당 위치에 존재함을 보여줍니다. "Consistency proof"(일관성 증명)는 이후의 체크포인트가 이전에 저장한 체크포인트의 추가 전용 확장임을 보여주므로, 그 사이에 아무것도 제거되거나 변경되지 않았음을 나타냅니다.
• 검증 키는 대역 내(in-band)로 제공됩니다. 검증자 키 엔드포인트는 체크포인트에 서명하는 공개 키를 반환합니다. 계획된 키 교체 시에는 새 키가 서명을 시작하기 전에 해당 목록에 추가되며, 이전 키도 목록에 계속 남아 있습니다. 따라서 이미 보유한 체크포인트는 계속 검증됩니다.

투명성 로그가 증명하는 것

• 보유한 이벤트의 리프 필드(이벤트가 리프가 되는 방식에 나열됨)가 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 이벤트는 접근 후 2영업일 이내에 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/ 아래에서 6개의 읽기 전용 엔드포인트가 제공됩니다.

체크포인트, 타일, 항목 번들은 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, 10진수 트리 크기, base64 루트 해시입니다. 그 뒤에 빈 줄이 오고, 이어서 서명 줄이 옵니다. 서명 줄은 em 대시(U+2014)로 시작하고, origin을 명시하며, base64 값으로 끝납니다. 여기의 값은 예시입니다.

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

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

• 디코딩된 서명 값의 처음 4바이트는 서명 키의 key_hash이며, 검증자 키 세트의 어떤 항목으로 검증해야 하는지 알려줍니다. 나머지 바이트는 노트 본문의 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의 처음 4바이트이며, 이는 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}

tlog-tiles에 따라 연결된 32바이트 SHA-256 해시인 application/octet-stream을 반환합니다. 타일 주소 지정은 {level} 및 {index} 경로 문법, 큰 트리를 위한 x001/234 인덱스 형식, 부분 타일 접미사 .p/{width}를 포함하여 tlog-tiles를 정확히 따릅니다. 해시 타일은 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}

tlog-tiles에 따라 각각 빅엔디언 uint16 길이가 접두사로 붙은 연속된 리프 항목인 application/octet-stream을 반환합니다. 항목 번들에는 이벤트 평문, 즉 각 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
• 중첩된 type 및 email_address를 포함하는 actor
• 중첩된 type, id, parent를 포함하는 resource_details

규칙은 다음과 같습니다.

• 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은 마이크로초가 0이면 소수 자릿수가 없고, 그렇지 않으면 정확히 6자리입니다.
  • accessed_at은 나노초를 정확히 보존하는 가장 짧은 자릿수인 0, 3, 6 또는 9자리의 소수 자릿수를 가집니다.
• 정규 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으로 명명되고 디코딩된 처음 4바이트가 보관한 현재 유효한 키의 key_hash와 같은 서명 줄을 찾습니다. 해당 키의 public_key를 사용하여 나머지 바이트를 노트 본문의 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을 도출하며, 이 UUID는 시작하기 전에에서 Console로부터 가져온 값입니다. origin 줄이 다른 체크포인트는 거부합니다.

Go 1.26 이상으로 설치하세요. Compliance Access Key는 플래그나 파일이 아닌 ANTHROPIC_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 기준) 7일 전부터 시작합니다. 각 이벤트의 리프를 재구성하고, 포함 증명을 검증하며, 이전에 검증한 이벤트를 당시 기록한 내용과 비교합니다. 마지막으로 새 체크포인트와 진행 상황을 --state 파일에 저장하며, 다음 실행은 이 파일에서 시작합니다. 최소 하루에 한 번 실행하세요. 매시간 실행하는 것도 합리적입니다. 상위 조직 키를 사용하는 경우 하위 조직마다 각각 고유한 --org 및 --state 파일로 하나씩 실행하세요. 각 하위 조직의 UUID도 검증 대상인 Compliance API 응답이 아니라 Claude Console에서 가져옵니다. 하위 조직의 Settings > Organization 페이지 또는 Console의 상위 조직 조직 목록에서 찾을 수 있습니다. axt-verify checkpoint는 체크포인트 및 추가 전용 단계만 수행합니다. axt-verify events FILE은 감사자의 샘플이나 자체 내보내기와 같이 이미 보유한 이벤트를 검증합니다. 파일의 각 이벤트가 현재 체크포인트 아래 로그에 여전히 커밋되어 있음을 증명합니다. 피드를 읽거나 상태 파일을 건드리지 않습니다.

이 기간으로 인해 한 가지 제한이 있습니다. run은 최근 7일간의 이벤트만 다시 읽으므로, 전체 기록이 아니라 최근 제공된 이벤트만 다시 확인합니다(7단계). 내보낸 이벤트를 보관하세요(자체 체크포인트 아카이브 보관하기 참조). axt-verify events FILE은 이후 언제든지 해당 사본이 로그에 여전히 커밋되어 있음을 증명하지만, 피드를 다시 읽지는 않습니다. 피드에서 제거되거나 다시 쓰인 오래된 이벤트를 감지하려면 Activity Feed에서 해당 범위를 다시 내보내고 보관한 사본과 비교하세요. 다시 내보낸 것 자체도 axt-verify events FILE로 검증할 수 있습니다. 7일의 중첩 기간은 피드의 2영업일 전달 시간보다 길기 때문에, 늦게 도착한 이벤트도 이후 실행의 기간 내에 포함됩니다. 필요한 경우 --overlap으로 기간을 변경할 수 있습니다.

대신 자체 구현이 필요한 경우, ECDSA 노트 키를 지원하는 tlog-tiles 라이브러리를 사용하여 앞의 체크리스트를 따르세요.

결과 해석

axt-verify는 origin, 검증한 체크포인트의 트리 크기와 루트 해시, 추가 전용 검사가 시작된 트리 크기, 그리고 결과별 이벤트 수를 출력합니다. --json을 전달하면 동일한 보고서를 한 줄에 하나의 JSON 객체 형태로 받을 수 있습니다. 각 이벤트는 다음 네 가지 결과 중 하나를 가집니다:

• Verified: 제공된 이벤트로부터 재구성한 리프가 서명된 로그에서 해당 이벤트의 인덱스에 커밋되어 있습니다.
• Pending: 이벤트의 인덱스가 최신 게시된 체크포인트의 범위를 넘어섭니다. 이는 이벤트가 나타난 직후 잠시 동안은 정상입니다. run에서 axt-verify는 해당 이벤트를 기억해 두었다가 이후 실행에서 체크포인트가 이를 포함하게 되면 검증하며, 24시간 이상 걸리면 실패로 처리합니다. events FILE에는 이를 해결할 이후 실행이 없으므로, 포함하는 체크포인트가 게시될 때까지 최대 1분간 기다립니다. 그때까지 게시되지 않으면 해당 이벤트를 아직 포함되지 않은 것으로 보고하고 종료 상태 3으로 끝납니다. 나중에 다시 실행하세요. events FILE이 최소 하루 간격을 둔 두 번의 실행에서 동일한 이벤트를 아직 포함되지 않은 것으로 보고하면, 이를 검증 실패로 간주하고 종료 상태 1과 같이 에스컬레이션하세요.
• Not logged: 이벤트가 인덱스 없이 제공되었습니다. 이벤트는 조직이 Access Transparency에 등록되지 않은 동안이거나, 조직의 로그가 생성되기 전에 기록된 경우에만 transparency_log_leaf_index 없이 제공됩니다(Activity Feed 이벤트의 transparency_log_leaf_index 필드 참조). axt-verify는 이러한 이벤트를 not logged로 보고하며, 이로 인해 실행을 실패 처리하지 않습니다. 로그가 생성된 이후 날짜이면서 등록 기간 내에 속하는 이벤트에 인덱스가 없는 것은 예상되지 않는 상황입니다. 종료 상태에만 의존하지 말고 실행 요약이나 --json 출력의 not-logged 목록을 검토하세요.
• Failed: 종료 상태 1을 참조하세요.

종료 상태는 스케줄러에 무슨 일이 일어났는지 알려줍니다:

• 0: 실패한 항목이 없습니다. Not-logged 이벤트는 실패가 아닌 보고 대상이며, run의 pending 이벤트도 마찬가지입니다.

• 1: 검증 실패입니다. 이는 일시적인 오류가 아니라 보안상의 발견 사항입니다. 상태 파일과 출력을 보관하고, Anthropic 계정 담당자 또는 Anthropic 지원팀에 보고하세요. 원인은 다음과 같습니다:

  • 잘못된 origin을 가진 체크포인트, 또는 사용 중인 axt-verify 릴리스에 내장된 키로 검증되지 않는 서명. 실패한 체크포인트의 서명 줄에 있는 key_hash를 게시된 키 지문과 비교하세요. 그곳에 나열된 키이면서 아직 업그레이드하지 않은 전환 날짜가 있다면, 해당하는 릴리스가 필요하다는 의미입니다. 그곳에 나열되지 않은 키는 어떤 릴리스를 실행하든 보안상의 발견 사항입니다. 이 실패 시 axt-verify는 제공된 체크포인트의 모든 서명의 키 해시와 자신이 신뢰하는 키의 키 해시를 각각 8자리 16진수로 출력합니다. 이 출력만으로 비교하기에 충분합니다.
  • 올바른 형식의 signed note가 아닌 체크포인트. 예를 들어 루트 해시가 32바이트가 아닌 경우입니다.
  • 축소된 로그, 또는 저장해 둔 체크포인트를 확장한다는 것을 증명할 수 없는 로그. 이 경우 출력에 두 체크포인트와 증명이 모두 포함되므로, 증거가 그 자체로 성립합니다.
  • 동일한 트리 크기에 대해 루트 해시가 서로 다른 두 개의 서명된 체크포인트. 출력에 두 체크포인트가 모두 포함됩니다.
  • --from으로 전달된 체크포인트 파일의 서명이 사용 중인 axt-verify 릴리스에 내장된 키로 검증되지 않는 경우, 또는 --from이나 --from-trusted 파일의 origin이 본인의 것이 아닌 경우. 키 교체 이전에 서명된 아카이브에 대해서는 자체 체크포인트 아카이브 보관하기를 참조하세요.
  • 제공받은 이벤트에 대해 서명된 루트 해시를 재현하지 못하는 포함 증명.
  • 실행 범위 내의 이벤트가 이전 실행에서 기록된 것과 다르게 제공된 경우: 다른 리프 바이트, 다른 인덱스, 또는 이전에 인덱스가 있었는데 없는 경우.
  • 실행에서 처음 확인된 후 24시간이 지나도 여전히 pending 상태인 이벤트.
  • 피드가 제공한 이벤트에 대해 거부된 포함 증명(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의 이벤트 중 대기 시간 내에 게시된 체크포인트가 해당 인덱스를 포함하지 않은 이벤트. 이러한 이벤트의 경우 Pending 결과에서 재실행을 중단하고 에스컬레이션할 시점을 설명합니다.
  • 재시도 횟수를 넘어 지속된 네트워크 오류, 속도 제한 또는 서버 오류.
  • 예상치 못한 응답.
  • 쓸 수 없는 상태 파일 또는 --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 대신 --from-trusted로 전달하세요. 이벤트도 보관하세요. 피드에서 내보낸 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