Verificar eventos do Access Transparency com o log de transparência

Saiba como verificar criptograficamente que nenhum evento do Access Transparency foi removido ou alterado depois de ser registrado no log de transparência da sua organização.

Como o log de transparência funciona

Um "transparency log" (log de transparência) é uma técnica que torna detectável qualquer adulteração de um registro. As entradas são apenas acrescentadas. Cada vez que o log cresce, seu operador assina uma declaração curta, chamada "checkpoint" (ponto de verificação), que se compromete com todas as entradas até aquele momento por meio de um hash de árvore de Merkle. Qualquer pessoa que guarde um checkpoint pode depois exigir a prova de que o log atual ainda contém tudo o que aquele checkpoint cobria, sem alterações e na mesma ordem. Remover ou reescrever uma entrada, portanto, não pode passar despercebido por um verificador que guardou um checkpoint que cobria essa entrada. O Certificate Transparency e o banco de dados de checksums de módulos Go são construídos sobre a mesma técnica. O C2SP tlog-tiles é uma especificação aberta para servir esse tipo de log como checkpoints assinados mais tiles estáticos e armazenáveis em cache de hashes e entradas, para que os clientes possam buscar os hashes e calcular todas as provas por conta própria.

Quando o Access Transparency está habilitado, a Anthropic mantém um log de transparência para a sua organização. Ele é um registro somente de acréscimo e assinado criptograficamente de eventos do Access Transparency (anthropic_access e cmek_preserve). Cada evento desse tipo registrado para a sua organização após a criação do log é acrescentado a ele. O log segue o formato C2SP tlog-tiles, então ferramentas criadas para esse padrão entendem seus checkpoints, tiles e provas.

• Um log por organização. O log de cada organização tem uma string de origem fixa: axt.anthropic.com/<your organization UUID>. A origem nunca muda durante a existência da organização.
• Cada novo evento se torna uma folha. Quando um evento do Access Transparency se torna elegível para aparecer no seu Activity Feed, ele é primeiro acrescentado ao seu log como uma folha e só então servido no feed. Uma folha é uma serialização determinística dos campos documentados do evento. O evento no seu feed traz transparency_log_leaf_index, sua posição baseada em zero no seu log.
• Checkpoints se comprometem com todo o histórico. O log é uma árvore de Merkle. Sempre que ele cresce, a Anthropic publica um checkpoint assinado: um documento de texto curto que declara a origem do log, seu tamanho atual e o hash raiz que se compromete com todas as folhas. Cada checkpoint traz exatamente uma assinatura da chave de assinatura do log.
• Duas provas decorrem disso. Uma prova de inclusão mostra que um evento específico está presente em sua posição sob um checkpoint. Uma prova de consistência mostra que um checkpoint posterior é uma extensão somente de acréscimo de um anterior que você salvou, de modo que nada entre eles foi removido ou alterado.
• As chaves de verificação são servidas na própria API. O endpoint de chaves de verificação retorna as chaves públicas que assinam os checkpoints. Em uma rotação de chave planejada, a nova chave é adicionada a essa lista antes de começar a assinar, e as chaves anteriores continuam listadas. Os checkpoints que você já possui, portanto, continuam sendo verificados.

O que o log de transparência prova

• Os campos de folha de um evento que você possui (listados em Como um evento se torna uma folha) são, byte a byte, o que a Anthropic registrou no log.
• O log da sua organização apenas cresce. A verificação contra um checkpoint que você possui falha se um evento registrado no log for posteriormente excluído ou reescrito nele. Ela também falha se for servido a você um histórico diferente daquele que foi servido antes.
• Novas entradas só podem ser acrescentadas. Um evento não pode ser inserido em um histórico que você já verificou.

O que ele não prova nem altera

• Ele não prova que todo acesso foi registrado, nem que um evento registrado descreve o acesso com precisão. Ele prova apenas que o que a Anthropic registrou no log não mudou desde então.
• Ele não altera o que o Access Transparency cobre nem quando os eventos chegam.
• Campos servidos fora da folha, como workspace_uuid e qualquer campo adicionado posteriormente, não são cobertos pela prova.
• Uma prova de inclusão vale para um evento que foi servido a você. Ela não prova, por si só, que o feed listou todas as folhas que o log contém. Os pacotes de entradas do log contêm todas as folhas, então você pode ler diretamente o conjunto completo de eventos registrados quando precisar.
• A presença de transparency_log_leaf_index em um evento é um ponteiro, não uma prova. Sempre verifique a inclusão antes de tratar um evento como registrado no log.
• A proteção contra um histórico reescrito vem dos checkpoints que você guarda. A assinatura de um checkpoint por uma chave listada em Impressões digitais de chaves publicadas prova que ele veio do log da Anthropic. Uma prova de consistência a partir do checkpoint que você salvou da última vez prova que o histórico que você já observou apenas cresceu.

Antes de começar

Você precisa de:

• Uma Compliance Access Key com o escopo read:compliance_activities, a mesma chave e o mesmo escopo que você usa para o Activity Feed. Uma chave de organização pai pode ler o log de cada organização filha inscrita, nomeando a organização filha em cada requisição.
• O UUID da sua organização. Encontre-o no Claude Console em Settings > Organization. É o mesmo valor que o Activity Feed serve como organization_uuid, mas obtenha-o no Console. Esse valor é o que torna um checkpoint seu, então ele não deve vir da API que você está verificando. Você deriva a origem do seu log a partir dele como axt.anthropic.com/<organization UUID>. Derive essa string você mesmo. Não a leia de uma resposta da API.
• Um local durável para guardar o último checkpoint que você verificou. Esse checkpoint salvo é o que transforma "o log está consistente hoje" em "o log está consistente desde que você começou a observá-lo".

Prazos

• Eventos: Os eventos do Access Transparency aparecem no seu Activity Feed em até dois dias úteis após o acesso. Um evento entra no log somente quando está elegível para ser servido, então o log nunca revela um evento antecipadamente. Como o log é gravado antes de o feed servir o evento, uma entrada pode aparecer brevemente no log antes de seu evento aparecer no seu feed. Essa diferença não é uma discrepância.
• Checkpoints: Um novo checkpoint é publicado sempre que seu log cresce.
• Provas de inclusão: Uma prova para um evento recém-servido fica disponível assim que um checkpoint que cobre a posição do evento é publicado, normalmente muito pouco tempo depois de o evento aparecer. Se você solicitar uma antes disso, receberá um 404 e deverá tentar novamente após um curto intervalo.
• Frequência de verificação: Execute sua verificação pelo menos diariamente. A cada hora é razoável.
• Cancelamento da inscrição: Se a sua organização deixar de usar o Access Transparency, nada é excluído. Seu log continua legível pelos mesmos endpoints. Se o Access Transparency for habilitado novamente mais tarde, o mesmo log continua.

Retenção e exclusão

• Log de transparência: A Anthropic não exclui entradas do seu log, e o log não expira. Ele é mantido se a sua organização deixar de usar o Access Transparency e após a exclusão da sua organização, porque remover entradas é exatamente a alteração que o log existe para detectar. Os pacotes de entradas contêm os campos de folha de cada evento, então esses campos são mantidos enquanto o log existir.
• Activity Feed: Os eventos do Access Transparency no Activity Feed seguem a retenção do feed. As atividades são retidas por 6 anos. Consulte Consultar o Activity Feed.
• Sem exclusão por você: Os endpoints do log de transparência são somente leitura. Não há como excluir ou alterar uma entrada.

Endpoints do log de transparência

Seis endpoints somente leitura são servidos em https://api.anthropic.com/v1/compliance/transparency_log/:

Checkpoints, tiles e pacotes de entradas seguem exatamente o formato de transmissão do C2SP tlog-tiles. Os dois endpoints de prova são conveniências: toda prova também pode ser calculada a partir dos tiles, então você nunca precisa confiar na saída de um endpoint de prova. Você verifica os hashes que ele retorna contra um checkpoint assinado.

Autenticação e escopo

Envie sua Compliance Access Key no cabeçalho x-api-key e o cabeçalho anthropic-version, como em toda requisição da Compliance API (consulte Versionamento). A Compliance API deve estar habilitada para a sua organização.

Não há uma permissão separada para o log de transparência. Qualquer chave que possa ler o Activity Feed da sua organização, seja da sua organização ou da organização pai, pode ler todo o seu log, incluindo os campos de eventos em seus pacotes de entradas.

Cada requisição lê o log de exatamente uma organização:

• Uma chave de nível de organização lê o log da sua própria organização. O parâmetro de consulta organization_id é opcional. Se presente, ele deve nomear a própria organização da chave.
• Uma chave de nível de organização pai deve passar organization_id, nomeando uma organização filha.
• organization_id aceita o ID com prefixo org_... ou o UUID da organização.

Um 404 significa que não há nenhum log que essa chave possa ler. Uma organização fora do escopo da chave, uma organização inexistente e uma organização cujo log ainda não foi criado são deliberadamente indistinguíveis. O log de uma organização que deixou de usar o Access Transparency não se enquadra nesse caso: ele continua sendo servido.

Erros

Os erros usam o envelope de erro JSON padrão da Compliance API em todos os endpoints, incluindo os de texto e binários. Consulte Erros para o envelope e os tipos de erro compartilhados.

Cache

As respostas podem ser armazenadas em cache apenas pelo cliente solicitante. Cache-Control sempre inclui private, e as respostas trazem Vary: x-api-key. Não coloque um cache compartilhado na frente desses endpoints. Tiles completos e pacotes de entradas completos nunca mudam e são servidos com Cache-Control: private, max-age=604800, immutable. Todo o resto, incluindo checkpoints, provas, chaves, tiles parciais e erros, é servido com Cache-Control: private, no-store.

Ler o checkpoint mais recente

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"

A resposta é text/plain: uma signed note (nota assinada) do C2SP. As linhas do corpo são a origem, o tamanho da árvore em decimal e o hash raiz em base64. Segue-se uma linha em branco e, depois, a linha de assinatura, que começa com um travessão (U+2014), nomeia a origem e termina com um valor em base64. Os valores aqui são ilustrativos:

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

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

• Os primeiros quatro bytes do valor de assinatura decodificado são o key_hash da chave de assinatura, que indica com qual entrada do conjunto de chaves de verificação verificar. Os bytes restantes são uma assinatura ECDSA P-256 em ASN.1 DER sobre o SHA-256 do corpo da nota: todos os bytes antes da linha em branco, incluindo a quebra de linha final do corpo.
• Um checkpoint pode trazer linhas adicionais após o hash raiz. Ignore as linhas que você não entende. Elas são cobertas pela assinatura.
• Ignore uma linha de assinatura cujo nome não seja a sua origem ou cujo hash de chave você não possua.
• Nunca armazene um checkpoint em cache. Um checkpoint desatualizado oculta o tamanho atual do log, fazendo com que eventos recém-servidos pareçam não cobertos.

Ler as chaves de verificação

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

O key_hash cobre apenas os bytes da chave: são os primeiros quatro bytes do SHA-256 sobre o SubjectPublicKeyInfo em DER, que é a regra usada pela codificação de note-verifier ECDSA. Ele não é o ID de chave dependente do nome que o formato base de signed note define para chaves Ed25519, então não muda com a origem. Uma assinatura válida por uma chave listada em Impressões digitais de chaves publicadas prova que o checkpoint veio do serviço de log de transparência da Anthropic. A linha de origem dentro do checkpoint assinado é o que o vincula à sua organização. É por isso que você compara essa linha com a origem que você mesmo deriva.

As chaves podem ser rotacionadas:

• Uma rotação é uma transição. A partir de determinado checkpoint, os novos checkpoints são assinados pela nova chave.
• Em uma rotação planejada, a nova chave aparece em log_keys antes de assinar qualquer coisa, e as chaves anteriores continuam listadas. Um checkpoint que você salvou antes da rotação, portanto, continua sendo verificado.
• Um verificador pode buscar o conjunto de chaves a cada execução ou mantê-lo localmente. Um verificador que o mantém localmente relê este endpoint quando encontra uma assinatura cujo key_hash ele não possui.

Impressões digitais de chaves publicadas

A Anthropic publica aqui, fora da API, a impressão digital de cada chave que assina checkpoints. Isso permite que você confira uma chave que mantém localmente contra uma fonte que o caminho de entrega não pode alterar. A chave que você possui pode vir de uma resposta anterior de GET /keys ou de ferramentas que fixam a chave.

Uma rotação planejada é anunciada nesta página pelo menos 30 dias antes de a nova chave assinar seu primeiro checkpoint. Durante esse período de aviso, a nova chave é listada em log_keys e nesta tabela com sua data de transição. Chaves desativadas continuam listadas com suas datas de serviço. Uma chave que não aparece nesta tabela não é legítima, independentemente do que GET /keys retorne. Trate um checkpoint que não é verificado por nenhuma chave listada como uma falha de verificação e informe-o ao seu representante de conta da Anthropic ou ao suporte da Anthropic.

O axt-verify traz a chave atual em cada versão e nunca lê uma chave da API. Cada versão traz exatamente uma chave. Na data de transição, a Anthropic começa a assinar com a nova chave e publica a versão do axt-verify que a traz. Na mesma data, a Anthropic reemite o checkpoint mais recente de cada organização sob a nova chave, mesmo para um log que não cresceu. Atualize na data de transição. Executar a versão antiga após a transição falha com status de saída 1, assim como executar a nova versão antes dela. Qualquer uma dessas falhas desaparece assim que você executa a versão correspondente. Um verificador que você mesmo mantém precisa ter a nova impressão digital, com sua data de transição, adicionada antes dessa data.

Buscar uma prova de inclusão

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

Não há busca por ID de atividade. Você sempre possui o índice, porque ele chega no evento, e verifica a prova contra os bytes do evento que você buscou no feed.

Um 404 significa que o checkpoint publicado mais recente não cobre a posição fornecida:

• Para um índice que você leu de um evento servido, isso é transitório. Um checkpoint que o cobre é publicado em breve, então tente novamente após um curto intervalo.
• O mesmo 404 responde a qualquer outra posição não coberta, como um índice que o feed nunca serviu. Para essa posição, não há garantia de que um checkpoint que a cubra seja publicado algum dia. A resposta não informa em qual caso você está.

Um leaf_index ausente ou que não seja um inteiro não negativo retorna 400.

Buscar uma prova de consistência

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

• A prova sempre se estende até o checkpoint publicado mais recente. Esta API nunca serve checkpoints históricos: você guarda os que lhe são servidos.
• Um from igual ao tamanho da árvore do checkpoint mais recente retorna a prova vazia.
• Um checkpoint mantido com tamanho de árvore 0 não precisa de prova de consistência, porque todo log estende o log vazio. Nesse caso, adote diretamente o checkpoint mais recente.
• Um from menor que 1, ou maior que o tamanho da árvore do checkpoint mais recente, retorna 400.
• Se o log não conseguir mais provar que estende um checkpoint que ele já assinou para você, trate isso como uma falha de verificação, não como um erro de uso.

Ler um tile de hashes

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

Retorna application/octet-stream: hashes SHA-256 de 32 bytes concatenados, conforme o tlog-tiles. O endereçamento de tiles segue exatamente o tlog-tiles, incluindo a gramática de caminho {level} e {index}, a forma de índice x001/234 para árvores grandes e o sufixo de tile parcial .p/{width}. Os tiles de hashes são a unidade a partir da qual os clientes tlog-tiles calculam as provas por conta própria.

• Tiles completos são imutáveis e são servidos com Cache-Control: private, max-age=604800, immutable.
• Tiles parciais são substituídos à medida que a árvore cresce e são servidos com Cache-Control: private, no-store. Quando um tile fica completo, uma requisição para sua forma parcial anterior pode retornar 404, mesmo que o tile completo exista. Recorrer ao tile completo a partir do tile parcial é tarefa do cliente, conforme especificado pelo tlog-tiles, e os clientes padrão já fazem isso.
• Um level, index ou largura de tile parcial malformado retorna 400. Uma posição de tile além do tamanho atual da árvore retorna 404.

Ler um pacote de entradas

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

Retorna application/octet-stream: entradas de folha consecutivas, cada uma prefixada com seu comprimento uint16 big-endian, conforme o tlog-tiles. Os pacotes de entradas contêm o texto simples dos eventos: os bytes canônicos de cada evento do Access Transparency. É por isso que toda a superfície exige o escopo do Activity Feed. O endereçamento, a forma parcial, o cache e os erros são idênticos aos dos tiles de hashes.

O campo transparency_log_leaf_index nos eventos do Activity Feed

Os eventos anthropic_access e cmek_preserve em GET /v1/compliance/activities trazem transparency_log_leaf_index, um inteiro, sempre que o evento tem uma folha. Outros tipos de atividade nunca o trazem.

• A chave fica ausente, e não null, quando o evento não tem folha. Um verificador robusto trata uma chave ausente e um valor null da mesma forma.
• Um evento é servido sem transparency_log_leaf_index em apenas dois casos. O primeiro é enquanto a sua organização não está inscrita no Access Transparency, ou seja, antes da inscrição ou entre um cancelamento de inscrição e uma nova inscrição. O segundo é quando o evento foi registrado antes da criação do log da sua organização. Para uma organização inscrita antes da introdução do log de transparência, isso inclui seu histórico anterior. Depois que seu log existe e enquanto você está inscrito, todo evento é acrescentado ao log antes de o feed servi-lo. Se uma falha impedir o feed de obter o índice, o feed atrasa o evento em vez de servi-lo sem índice. O evento não é perdido: ele já está no log e aparece no feed, com o índice incluído, assim que a falha é corrigida. Um evento sem índice não é esperado quando é datado após a criação do seu log e está dentro de um período em que você estava inscrito.
• Um índice presente é um ponteiro, não uma prova. Verifique a inclusão antes de tratar o evento como registrado no log. A anomalia que vale a pena escalar é um índice presente cuja prova de inclusão ainda não pode ser obtida muito tempo depois de um checkpoint que o cubra já deveria ter sido publicado.
• O índice é atribuído quando o evento é acrescentado ao log e não é um dos campos que compõem a folha.

Como um evento se torna uma folha

Uma entrada de folha é o byte de versão de esquema 0x01 seguido do JSON canônico de 11 campos. O JSON segue a RFC 8785 (JSON Canonicalization Scheme), e os campos são obtidos do evento exatamente como o Activity Feed o serve:

• id, type, created_at, accessed_at, organization_id, organization_uuid, workspace_id, accessor_department e reason_code
• actor, com seus campos aninhados type e email_address
• resource_details, com seus campos aninhados type, id e parent

As regras:

• Campos servidos fora desse conjunto, como workspace_uuid e o próprio transparency_log_leaf_index, são ignorados.
• Um campo documentado que o evento servido omite entra na folha como null. Uma string vazia é diferente de null.
• actor e resource_details são objetos com exatamente suas chaves documentadas quando o evento servido os traz. Na versão 0x01, actor.email_address e resource_details.parent são sempre null. Quando o evento servido omite um desses objetos ou o serve como null, o valor inteiro é null na folha, e não um objeto de campos null. Muitos eventos de acesso não trazem resource_details.
• Os valores de string, incluindo ambos os timestamps e reason_code, são obtidos byte a byte como servidos. Se você derivar novamente um timestamp a partir de outra representação, reproduza exatamente a renderização servida:
  • RFC 3339 UTC com sufixo Z.
  • created_at não tem dígitos fracionários quando seus microssegundos são zero, e exatamente seis caso contrário.
  • accessed_at tem zero, três, seis ou nove dígitos fracionários, o menor número que preserva exatamente seus nanossegundos.
• JSON canônico significa chaves de objeto ordenadas, nenhum espaço em branco insignificante e escape mínimo de strings. Nenhum número aparece em nenhum lugar da folha.
• O hash da folha é o SHA-256(0x00 || entry) da RFC 6962. Os nós internos são calculados como SHA-256(0x01 || left || right).
• Um verificador rejeita um byte de versão desconhecido e uma folha 0x01 cujo type não seja um dos dois tipos do Access Transparency. Novos tipos de evento ou mudanças de regras são lançados sob um novo byte de versão. As folhas existentes nunca têm seu hash recalculado.

Por exemplo, este evento de acesso, como o Activity Feed o serve:

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

torna-se este JSON canônico. Ele tem exatamente as 11 chaves documentadas, ordenadas, em uma única linha. workspace_uuid e transparency_log_leaf_index são descartados, e resource_details.parent, ausente do evento servido, entra como 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"}

A entrada de folha é o byte 0x01 seguido desses bytes UTF-8. Seu hash de folha, SHA-256(0x00 || entry), é 6ro7vTcFq+sYDZiiGvZaFetUIoMSLig3DGDrCKK1HFU= em base64. Use este exemplo como vetor de teste para o seu próprio código de canonicalização.

Verifique seu log

A verificação é executada na sua própria infraestrutura. Tudo o que a API retorna não é confiável até ser verificado contra duas coisas que você mesmo possui. A primeira é a origem que você deriva do UUID da sua organização. A segunda é o checkpoint que você salvou na sua última execução. Uma execução de verificação completa faz o seguinte, nesta ordem:

1. Busque o conjunto de chaves de verificação. Calcule você mesmo a impressão digital de cada chave como o SHA-256 de seu public_key decodificado de base64. Mantenha apenas as chaves cuja impressão digital aparece em Impressões digitais de chaves publicadas, junto com o status de cada chave ali. Verifique um checkpoint recém-obtido apenas com uma chave que essa tabela lista como atual naquela data. Aceite uma chave desativada apenas para um checkpoint que você salvou antes da data de desativação dela.
2. Estabeleça o checkpoint mais recente. Na primeira execução, busque-o no endpoint de checkpoint. Em cada execução posterior, solicite uma prova de consistência a partir do tamanho de árvore que você salvou. A resposta traz o checkpoint mais recente junto com a prova.
3. Verifique primeiro a linha de origem do checkpoint. Compare sua primeira linha, byte a byte, com a origem que você derivou. Rejeite qualquer checkpoint cuja origem seja diferente, antes de fazer qualquer outra coisa.
4. Verifique a assinatura do checkpoint. Encontre a linha de assinatura nomeada com a sua origem cujos primeiros quatro bytes decodificados sejam iguais ao key_hash de uma chave atualmente válida que você manteve. Verifique os bytes restantes como uma assinatura ECDSA P-256 sobre o SHA-256 do corpo da nota, usando o public_key dessa chave. Se nenhuma linha de assinatura corresponder a essa chave, ou se a assinatura não for verificada, rejeite o checkpoint.
5. Prove que o log é somente de acréscimo. Se o novo tamanho da árvore for menor que o que você salvou, falhe. Se for igual, os hashes raiz devem coincidir. Se for maior, verifique a prova de consistência da RFC 9162 do seu tamanho e hash raiz salvos até o novo tamanho e hash raiz.
6. Prove que cada evento está incluído. Leia todos os eventos do Access Transparency que o Activity Feed serve. Para cada novo evento, reconstrua sua folha, calcule o hash e busque sua prova de inclusão. Percorra o caminho de auditoria a partir do hash da sua folha no índice do evento até o hash raiz do checkpoint. Uma divergência significa que o evento que foi servido a você não é o evento que o log registrou. A resposta da prova pode trazer um checkpoint diferente daquele que você possui. Vincule-o ao seu histórico com uma prova de consistência antes de verificar qualquer coisa contra ele.
7. Verifique novamente o que você viu antes. Sempre que você ler um evento novamente, ele deve ser servido com o mesmo índice e os mesmos bytes de folha de quando você o verificou. Nenhum evento pode perder o índice que tinha e, enquanto você estiver inscrito, nenhum evento pode aparecer pela primeira vez sem um. Os eventos servidos sem índice na sua primeira execução são o seu histórico anterior ao log. Uma execução que relê apenas eventos recentes verifica novamente apenas esses. Para verificar novamente os mais antigos, verifique outra vez as cópias que você guardou (etapa 8).
8. Salve o checkpoint que você verificou e um registro de cada evento que você verificou. Eles são sua evidência e seu ponto de partida para a próxima execução.

Verificar com o axt-verify

O axt-verify é o verificador de código aberto da Anthropic para este log. Ele é um único binário Go que você executa na sua própria infraestrutura. Cada versão tem exatamente uma chave de assinatura do log de Impressões digitais de chaves publicadas incorporada, então ele nunca pergunta à API em qual chave confiar. Quando a Anthropic rotaciona a chave, você atualiza para a versão que traz a nova chave na data de transição. O axt-verify deriva sua origem a partir do UUID da organização que você passa com --org, que é aquele que você obteve no Console em Antes de começar. Ele rejeita qualquer checkpoint cuja linha de origem seja diferente.

Instale-o com Go 1.26 ou mais recente. Ele lê sua Compliance Access Key da variável de ambiente ANTHROPIC_COMPLIANCE_ACCESS_KEY, nunca de uma flag ou de um arquivo. O comando run é o que deve ser agendado:

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

Cada run busca o checkpoint mais recente e verifica sua assinatura e sua linha de origem. Em seguida, prova que o log é uma extensão somente de acréscimo do checkpoint que a execução anterior salvou. Depois, percorre as páginas de eventos do Access Transparency no seu Activity Feed. Ele começa sete dias (por created_at) antes do evento mais recente que a execução anterior leu, para que eventos listados com atraso ou fora de ordem ainda sejam capturados. Ele reconstrói a folha de cada evento, verifica uma prova de inclusão para ela e compara qualquer evento que já verificou antes com o que registrou naquela ocasião. Por fim, salva o novo checkpoint e seu progresso no arquivo --state, a partir do qual a próxima execução começa. Execute-o pelo menos diariamente. A cada hora é razoável. Com uma chave de organização pai, execute uma cópia por organização filha, cada uma com seu próprio --org e arquivo --state. O UUID de cada organização filha também vem do Claude Console, não das respostas da Compliance API que você está verificando. Encontre-o na página Settings > Organization da organização filha ou na lista de organizações da sua organização pai no Console. axt-verify checkpoint executa apenas as etapas de checkpoint e de somente acréscimo. axt-verify events FILE verifica eventos que você já possui, como uma amostra de um auditor ou sua própria exportação. Ele prova que cada evento no arquivo ainda está registrado no log sob o checkpoint atual. Ele não lê o feed nem altera o arquivo de estado.

Uma limitação decorre dessa janela: run relê apenas os últimos sete dias de eventos, então verifica novamente os eventos servidos recentemente (etapa 7), não todo o seu histórico. Guarde os eventos que você exporta (consulte Mantenha seu próprio arquivo de checkpoints). axt-verify events FILE prova, em qualquer data posterior, que essas cópias ainda estão registradas no log, mas não relê o feed. Para detectar um evento mais antigo removido ou reescrito no feed, exporte novamente esse intervalo do Activity Feed e compare-o com as cópias que você guardou. Você também pode verificar a própria nova exportação com axt-verify events FILE. A sobreposição de sete dias é maior que o prazo de entrega de dois dias úteis do feed, então um evento que chega com atraso ainda cai dentro da janela de uma execução posterior. --overlap altera a duração, se você precisar.

Se, em vez disso, você precisar da sua própria implementação, siga a lista de verificação anterior com uma biblioteca tlog-tiles que suporte chaves de nota ECDSA.

Interpretar o resultado

O axt-verify imprime sua origem, o tamanho da árvore e o hash raiz do checkpoint que ele verificou, o tamanho da árvore a partir do qual a verificação de somente acréscimo começou e uma contagem de eventos por resultado. Passe --json para obter o mesmo relatório como um objeto JSON por linha. Cada evento tem um de quatro resultados:

• Verificado: a folha reconstruída a partir do evento servido está registrada no índice do evento no log assinado.
• Pendente: o índice do evento está além do checkpoint publicado mais recente. Isso é normal por um curto período após o surgimento de um evento. Em run, o axt-verify memoriza o evento, verifica-o em uma execução posterior assim que um checkpoint o cobrir e o reprova se isso levar mais de 24 horas. events FILE não tem uma execução posterior para resolvê-lo, então ele aguarda até um minuto pela publicação de um checkpoint que o cubra. Se nenhum chegar, ele relata o evento como ainda não coberto e termina com status de saída 3. Execute-o novamente mais tarde. Se events FILE relatar o mesmo evento como ainda não coberto em duas execuções com pelo menos um dia de intervalo, trate isso como uma falha de verificação e escale como para o status de saída 1.
• Não registrado: o evento foi servido sem um índice. Um evento é servido sem transparency_log_leaf_index apenas enquanto sua organização não está inscrita no Access Transparency, ou quando foi registrado antes da criação do log da sua organização (consulte O campo transparency_log_leaf_index nos eventos do Activity Feed). O axt-verify relata esses eventos como não registrados e não reprova a execução por causa deles. Um evento sem índice não é esperado quando é datado após a criação do seu log e se enquadra em um período em que você estava inscrito. Revise a lista de não registrados no resumo da execução ou na saída --json em vez de confiar apenas no status de saída.
• Falhou: consulte o status de saída 1.

O status de saída informa ao seu agendador o que aconteceu:

• 0: Nada falhou. Eventos não registrados são relatados, não reprovados, assim como eventos pendentes em run.

• 1: Uma falha de verificação. Esta é uma constatação de segurança, não um erro transitório. Mantenha o arquivo de estado e a saída, e relate-a ao seu representante de conta da Anthropic ou ao suporte da Anthropic. As causas são:

  • Um checkpoint com a origem errada, ou uma assinatura que não é verificada com a chave incorporada à sua versão do axt-verify. Compare o key_hash na linha de assinatura do checkpoint com falha com as Impressões digitais de chaves publicadas. Uma chave listada ali com uma data de transição para a qual você não atualizou significa que você precisa da versão correspondente. Uma chave não listada ali é uma constatação de segurança, qualquer que seja a versão que você executa. Nessa falha, o axt-verify imprime o hash de chave de cada assinatura no checkpoint servido e o hash de chave da chave em que ele confia, com oito dígitos hexadecimais cada. Essa saída é suficiente para fazer a comparação.
  • Um checkpoint que não é uma nota assinada bem formada, por exemplo, um cujo hash raiz não tem 32 bytes.
  • Um log que encolheu, ou que não consegue provar que estende o checkpoint que você salvou. A saída então contém ambos os checkpoints e a prova, de modo que a evidência se sustenta por si só.
  • Dois checkpoints assinados para o mesmo tamanho de árvore com hashes raiz diferentes. A saída contém ambos os checkpoints.
  • Um arquivo de checkpoint passado com --from cuja assinatura não é verificada com a chave incorporada à sua versão do axt-verify, ou um arquivo --from ou --from-trusted cuja origem não é a sua. Para um arquivo assinado antes de uma rotação de chave, consulte Mantenha seu próprio arquivo de checkpoints.
  • Uma prova de inclusão que não reproduz o hash raiz assinado para o evento que foi servido a você.
  • Um evento dentro da janela da execução servido de forma diferente de como uma execução anterior o registrou: bytes de folha diferentes, um índice diferente ou nenhum índice onde antes havia um.
  • Um evento ainda pendente 24 horas após a execução tê-lo visto pela primeira vez.
  • Uma prova de inclusão recusada (400, 401 ou 403) para um evento que o feed serviu a você.
  • Uma prova de inclusão retornada para um leaf_index diferente do solicitado.
  • Em events FILE, um evento em um índice que o checkpoint mais recente já cobria quando a verificação começou, para o qual nenhuma prova de inclusão é servida antes que a espera se esgote.
  • Um evento cujo organization_uuid não é o UUID da organização que você passou com --org. Quando uma organização pai executa events FILE em uma exportação que abrange várias organizações filhas, o evento de cada outra organização falha dessa forma, então divida a exportação por organização primeiro e verifique cada parte com seu próprio --org.
  • O mesmo id de atividade em dois índices diferentes, ou duas vezes em um índice com conteúdo diferente, dentro de uma execução ou de uma entrada de events FILE.
  • Um evento cuja folha não pode ser reconstruída: por exemplo, um campo documentado que não é uma string, um nome de campo que aparece duas vezes, ou um type ausente ou que é uma variante não reconhecida de um tipo do Access Transparency. events FILE ignora linhas de outros tipos de atividade e não as reprova.

• 2: Um erro de uso ou de configuração. As causas são:

  • Uma flag ausente ou malformada.
  • Nenhuma ANTHROPIC_COMPLIANCE_ACCESS_KEY.
  • Uma chave que a API rejeita (401 ou 403) antes que qualquer checkpoint tenha sido verificado.
  • Um arquivo de estado que não pode ser lido ou que pertence a outra origem.

• 3: A execução não pôde ser concluída. Em run, o que já havia sido verificado é salvo no arquivo de estado. Execute novamente. As causas são:

  • Um evento em events FILE cujo índice nenhum checkpoint publicado cobriu dentro da espera. Para esse evento, o resultado Pendente indica quando parar de executar novamente e escalar.
  • Erros de rede, limitação de taxa ou erros de servidor que persistiram além das novas tentativas.
  • Uma resposta inesperada.
  • Um arquivo de estado ou de --save que não pôde ser gravado.

  Um status de saída 3 com respostas 404 é esperado até que a Anthropic tenha registrado um primeiro evento do Access Transparency para sua organização, porque todo endpoint do log de transparência retorna 404 até que esse evento crie o log. Escale se os endpoints do log de transparência ainda retornarem 404 mais de alguns dias depois que seu Activity Feed mostrar pela primeira vez um evento do Access Transparency, quer esse evento contenha ou não um transparency_log_leaf_index. Essa combinação não é esperada. Depois que uma execução tiver sido bem-sucedida, escale um status de saída 3 que persista.

Mantenha seu próprio arquivo de checkpoints

A evidência mais forte que você pode ter é seu próprio registro do que o log dizia em um determinado dia. axt-verify --save FILE grava o checkpoint que uma execução verificou, literalmente, e --from FILE em uma execução posterior faz o log provar que ainda estende esse checkpoint. Arquive um checkpoint salvo em um armazenamento que você controla, por exemplo, diariamente. Meses depois, uma prova de consistência a partir do tamanho de árvore desse checkpoint arquivado ainda deve levar a qualquer checkpoint que o log sirva, ou a verificação falha. Chaves anteriores permanecem listadas no conjunto de chaves de verificação após uma rotação planejada, de modo que um checkpoint arquivado continua sendo verificado. Com o axt-verify, se a chave que assinou um checkpoint arquivado tiver sido retirada por rotação desde então, passe esse arquivo com --from-trusted em vez de --from. Mantenha os eventos também. Os eventos do Access Transparency que você exporta do feed são entradas válidas para axt-verify events FILE, que prova em qualquer data posterior que essas cópias ainda estão registradas no log sob seu checkpoint atual. Como events FILE não relê o feed, sua exportação mantida também é a referência com a qual você compara uma reexportação posterior do mesmo intervalo.

Perguntas frequentes

Recursos relacionados

• Access Transparency
• Consultar o Activity Feed
• Visão geral da Compliance API
• Erros
• axt-verify, o verificador de código aberto da Anthropic para o log de transparência
• C2SP tlog-tiles e C2SP signed note, os formatos de transmissão para tiles, pacotes de entradas e checkpoints
• RFC 9162, os algoritmos de árvore de Merkle, prova de inclusão e prova de consistência
• RFC 8785, o JSON Canonicalization Scheme usado para as folhas