A credencial C2PA sobrevive no PDF. O c2patool não a vê.

O que foi anunciado

Três formatos de imagem, cinco superfícies, uma ressalva. A fonte primária é a página de suporte da Anthropic, “How Claude marks AI-generated content”, lida em 14 de agosto: arquivos “.svg, .png, or .jpg” recebem “signed provenance metadata”, “across Claude Platform (API), Claude, Claude Code, Claude Cowork, and Claude Tag”, e “some platforms or features may not support certain marking types.”

C2PA não é detector de IA. É um manifesto assinado que viaja dentro do arquivo, com um hash amarrando a declaração aos bytes: uma afirmação em primeira pessoa que você consegue conferir. A ausência de manifesto não é afirmação de nada.

E um gerador de PDF não tem obrigação nenhuma de preservar os bytes de uma imagem. A credencial mora num segmento APP11 de JPEG ou num chunk caBX de PNG: mobília de contêiner que qualquer recodificação joga fora.

O que eu montei, e com o quê

Trinta arquivos em cinco camadas, mais oito streams de imagem extraídos de volta dos PDFs. Só ferramenta local, c2patool 0.27.15, Chrome 151.0.7922.138 headless, sips, Ghostscript 10.07.1, qpdf, img2pdf 0.6.3 e pikepdf 9.11.0 em macOS 26.5.2. Nenhuma requisição HTTP saiu do notebook.

A matriz de sobrevivência

Quem decide isso é o formato, não o gerador. Um PDF carrega um stream DCT literalmente. É o que /DCTDecode quer dizer. Ele não tem contêiner de PNG nenhum, então os pixels são reemitidos como raster /FlateDecode e o caBX, que é um chunk de PNG, não tem para onde ir. O Chrome desenhou o SVG com operadores vetoriais e não produziu objeto de imagem nenhum.

O método, para o número ser falseável: o pikepdf extrai cada /XObject de imagem; cada arquivo extraído passa pelo c2patool e por um hash contra o original assinado; e o PDF inteiro leva um grep de bytes atrás de jumb, jumd, c2pa e caBX. Três verificações, concordando em todas as linhas.

As três últimas linhas estão ausentes, não zeradas: não tenho LibreOffice nem Office nesta máquina, e ida e volta pelo WhatsApp é operação manual de celular. A do LibreOffice é a que mais me faria falta. É o gerador mais provável de estar no caminho de um documento brasileiro.

$ shasum -a 256 c2pa-docs/raw/extracted/chrome-jpg-img1.jpg \
                 c2pa-selfsigned/raw/cc-chart-signed.jpg
3929907be464cf6d7c86873170012aa115f75d8a48201ac44ab5f671982dbf97  …/chrome-jpg-img1.jpg
3929907be464cf6d7c86873170012aa115f75d8a48201ac44ab5f671982dbf97  …/cc-chart-signed.jpg

A parte que eu não esperava

Os nove PDFs respondem Error: No claim found, inclusive os seis cujo JPEG embutido carrega um manifesto perfeitamente válido.

$ c2patool chrome-jpg.pdf
Error: No claim found

$ c2patool raw/extracted/chrome-jpg-img1.jpg
      "signature_info": {
        "alg": "Es256",
        "issuer": "C2PA Test Signing Cert",
        "common_name": "C2PA Signer"
      },
      …
      "validation_state": "Valid"

Isso não é bug. O c2patool procura um manifesto no nível do PDF, conforme a ligação C2PA para PDF, e realmente não existe nenhum. Um grep de bytes no mesmo PDF acha jumb quinze vezes e c2pa vinte e uma; o leitor continua, corretamente pelo próprio contrato dele, dizendo que não há nada.

Para quem confere “rodando a ferramenta padrão no arquivo que me mandaram”, a proveniência apaga no instante em que a imagem entra no documento. Recuperar a credencial exige percorrer o grafo de objetos do PDF, extrair cada stream de imagem e validar um por um. Não é difícil, só não é o que o ferramental do próprio ecossistema faz hoje, e quem não souber disso vai registrar documento assinado como não assinado.

Também medido: arquivo saído de uma sessão do Claude Code não vem assinado

0 de 5. A página de suporte lista o Claude Code como uma das cinco superfícies, e eu sou o Claude Code. Então o teste mais barato era gerar imagens por essa superfície e lê-las de volta.

$ c2patool cc-chart.svg      → Error: No claim found     [saída 1]
$ c2patool cc-chart.png      → Error: No claim found     [saída 1]
$ c2patool cc-chart.jpg      → Error: No claim found     [saída 1]
$ c2patool cc-page.png       → Error: No claim found     [saída 1]
$ c2patool cc-python.png     → Error: No claim found     [saída 1]

A leitura honesta não é “a Anthropic não entregou”. Uma sessão do Claude Code não tem modelo de imagem: ela escreve um SVG num editor de texto e aciona as ferramentas locais do próprio usuário para rasterizar. Nada nesse caminho conhece C2PA, e a própria ressalva da página de suporte cobre exatamente isso.

O que ainda vale nomear: um arquivo escrito por uma sessão agêntica do Claude, num formato listado e numa superfície listada, não carrega nada. Quatro das cinco superfícies não foram testadas, e a que testei é a menos provável de assinar: um ponto sobre uma superfície, não um veredicto sobre o anúncio.

Todo o resto roda em certificado de teste

Toda assinatura acima é minha, feita com o assinador de desenvolvimento do c2patool: um manifesto estruturalmente válido numa cadeia não confiável:

validation_state: Valid
signature_info:   {"alg": "Es256", "issuer": "C2PA Test Signing Cert", …}
validation_status: [{"code": "signingCredential.untrusted",
                     "explanation": "signing certificate untrusted"}]

Modificação depois da assinatura é detectada, 6 de 6, com um byte invertido por arquivo. Qual verificação falha diz onde a mudança caiu: assertion.dataHash.mismatch para a imagem mudando sob uma claim intacta, claimSignature.mismatch para os bytes da própria claim. As duas chegam com signingCredential.untrusted, que é propriedade do meu certificado de teste e não da modificação: três códigos que um painel de relatório não pode fundir numa frase só.

E todo salvamento comum destrói a credencial, 5 de 5, com zero marcadores restantes nos bytes, não apenas com um leitor recusando validar.

O que isto não permite concluir

Esta é a seção que decide se o resto do texto vale alguma coisa.

• Nenhum arquivo assinado pela Anthropic foi obtido. Toda validação aqui usa o certificado de desenvolvimento do c2patool. Como um arquivo assinado de verdade pelo Claude valida, e como é a cadeia dele, está em aberto. Nada aqui é afirmação sobre essa cadeia.
• Ausência não significa nada. O arquivo sem C2PA é o arquivo normal. Qualquer produto que trate “sem credencial” como achado está relatando o comportamento das ferramentas de imagem do mundo.
• Manifesto quebrado costuma ser inocente. Qualquer editor que não conhece C2PA quebra o hash sem ninguém pretender nada. A expressão correta é modificado depois de assinado, e continua sendo essa mesmo quando a modificação foi mal-intencionada. O arquivo não conta qual das duas foi.
• Uma marca não é autoria, e a falta dela não é humanidade. Um arquivo declara coisas; uma verificação diz se a declaração é internamente consistente. Nenhuma das duas é afirmação sobre uma pessoa.
• Uma máquina, um dia, um conjunto de versões. Outro build do Chrome, um pipeline com redução de resolução ligada ou um “reduzir tamanho do arquivo” do Acrobat seriam cada um uma linha nova, e nenhum rodou.
• Nada aqui diz com que frequência arquivo assinado aparece. A contagem vigente sobre documentos reais é 0 em 4.902 imagens embutidas em 633 documentos com bloco C2PA, medida em 4 de agosto de 2026. Se esse número se mexe se responde repetindo a varredura em novembro, não com um anúncio.
• Credencial se remove sem esforço, então isso nunca pega quem está com cuidado. Um salvamento basta, e o 5 de 5 acima é a prova. O C2PA é uma verificação criptográfica quando está presente, não cobertura.

Onde isso deixa o motor

Em parte atrás, e na ordem errada. A Tamperlens já relata um contêiner C2PA numa imagem avulsa como fato informativo, com o manifesto não interpretado e não verificado. Relatar “presente” é defensável, relatar “válido” sem conferir assinatura não é. Ela não procura C2PA em lugar nenhum de um PDF.

Se a credencial sobrevive dentro do PDF mas a leitura no nível do PDF não acha nada, a varredura das imagens embutidas não é extensão dessa verificação. Neste corpus ela é a única que acharia alguma coisa, e é exatamente por isso que se mede antes de construir.