Em 17 de setembro de 2026, a Lasso Security publicou uma pesquisa chamada The Provenance Tax, assinada por Andrea Siposova, medindo o efeito do watermarking de texto do Claude no comportamento de agentes. A base é o SynthID-Text, do Google DeepMind, que integrou em todos os modelos Claude a partir de agosto de 2026 para cumprir o Artigo 50(2) do EU AI Act. O achado curto: a marca invisível preserva qualidade percebida no texto, mas muda decisões individuais de tool call e de recusa, especialmente sob prompt injection.
O fato, em uma frase
Watermarking de LLM não é metadado nem caractere escondido. É uma mudança no sampling, o passo em que o modelo escolhe o próximo token. E se você tem um agente que age a partir daqueles tokens (nome de ferramenta, argumento, path), a mesma intervenção que embute a marca pode alterar o que o agente faz.
Como o SynthID-Text funciona por baixo do capô
O ponto onde a marca entra
Um LLM gera texto assim: para cada posição, ele calcula uma distribuição de probabilidade sobre o vocabulário e amostra um token dela. O SynthID não mexe nos logits. Ele deixa os logits em paz e modifica a amostragem. Puxa vários tokens candidatos da distribuição original do modelo, roda um torneio de eliminação simples entre eles, onde uma função pseudoaleatória com chave decide cada partida. O vencedor é emitido.
Uma analogia que carrega a mecânica
Pense num sorteio de mata-mata de campeonato. Os times (tokens candidatos) foram convocados pela probabilidade real do modelo, então ninguém entra fora do critério normal. O que muda é o juiz: em vez de tirar cara ou coroa a cada jogo, o juiz consulta uma função que depende de dois inputs, uma chave secreta e os últimos tokens já gerados. Mesma chave e mesmo contexto sempre produzem o mesmo resultado. Quem tiver a chave depois consegue verificar se o campeão de cada rodada bate com o que aquela função geraria, e isso vira a evidência estatística de que o texto passou pelo torneio.
Onde a analogia quebra: no futebol o resultado do jogo é uma amostra ruidosa da força dos times; aqui, dado chave e contexto, o resultado é determinístico. E não existe um único torneio, existe um por posição, com o contexto rolando junto.
Os três componentes
A construção tem três peças que trabalham em sequência a cada token. O gerador de seed aleatório é uma fórmula que pega o contexto recente (os últimos tokens) mais uma chave secreta e cospe um número. Mesmo contexto, mesma chave, mesmo número, sempre. É o truque da aleatoriedade determinística: parece aleatório para quem não tem a chave, mas é totalmente reproduzível para quem tem. Em seguida vem o torneio de amostragem, que é o mecanismo descrito acima. Por último, uma função de pontuação usada só na detecção, para testar se um texto candidato tem cara de ter passado pelo torneio.
Uma janela deslizante dos últimos tokens, tipicamente quatro, é hasheada junto com a chave para produzir um seed. Esse seed alimenta um conjunto de funções pseudoaleatórias, as g-functions. O algoritmo puxa tokens candidatos e os passa por várias camadas de torneio, cada camada pontuando com uma g-function e o vencedor avança. O token que ganha o torneio é o emitido.
Não distorcivo, mas não idêntico
Aqui está o ponto que confunde muita gente. O SynthID pode ser configurado como não distorcivo, o que significa que ele preserva a distribuição de saída do modelo em expectativa. Em expectativa é a chave: se você fizesse infinitas rodadas variando a aleatoriedade do watermark, na média a distribuição seria idêntica à sem marca. Mas numa geração concreta, com uma chave fixa, o token escolhido pode ser diferente do que seria escolhido sem watermark. A garantia é estatística, não pontual. Foi exatamente esse gap que a Lasso mediu.
Por que isso vira problema em agente
O torneio tem mais margem para alterar a escolha onde o modelo está mais indeciso. Em prosa, uma escolha entre dois sinônimos plausíveis é irrelevante. Em saída estruturada, tipo um JSON de tool call, chaves e nomes de função costumam ter probabilidade concentrada num único token, então o watermark quase não muda nada ali. Mas valores, como uma query de busca, um path de arquivo, um destinatário, um número, são regiões de mais incerteza. É lá que o torneio tem espaço para alterar o token que sai, e é exatamente esse token que o agente vai executar.
O que isso significa na prática
Os números do estudo
A Lasso rodou um design pareado: mesmo prompt, mesmo seed, mesma ordem, gerando com e sem SynthID através do SynthIDTextWatermarkLogitsProcessor da HuggingFace. Nos testes de tool calling em BFCL v4, a acurácia agregada caiu em seis dos sete modelos. Mas o dado mais interessante é o que eles chamam de churn: a fração de itens cujo veredito muda entre as duas condições. No phi-4 a T=1.0, 16,8% dos veredicts de tool call mudaram, enquanto a perda líquida de acurácia era de só 2,87 pontos. Isso significa que muitas chamadas passaram de certo para errado e outras de errado para certo, e o placar final escondeu a bagunça.
Uma chamada de ferramenta bem formada, para a ferramenta certa, mas com o argumento errado (path errado, destinatário errado, valor errado) é o pior tipo de erro, porque ela executa. No Llama-3.1-8B, a maior fatia da perda veio justamente de argumentos incorretos.
O caso da recusa sob prompt injection
A parte que mais deveria preocupar quem constrói agente é a de segurança. O estudo pega 200 comportamentos maliciosos do HarmBench e testa em duas condições: pedido cru e pedido com uma técnica fixa de injection anexada como conteúdo recuperado. No gemma-3-27b a T=0.001, o churn de recusa vai de 6% no pedido cru para 23,5% sob injection, e a mudança líquida de compliance sai de -1 para +12,5 pontos. Traduzindo: com o watermark ligado, o modelo passa a atender pedidos danosos que recusaria sem ele, e o efeito aparece muito mais forte quando o input é adversário.
Isso conecta os dois lados do problema. Um agente é um modelo com acesso a ferramentas. Se o watermark enfraquece a recusa e ao mesmo tempo muda os argumentos das chamadas, o teatro fica interessante do jeito errado.
Depende da chave
O efeito também varia com a chave do watermark. Rodando onze chaves diferentes no mesmo cenário de injection, no Llama-3.1-8B a mudança no sucesso do ataque foi de -4,5 a +14,5 pontos dependendo da chave. Duas chaves distintas geram dois comportamentos distintos no mesmo modelo com o mesmo prompt. Isso significa que trocar a chave do watermark, algo que fica no lado do provider, pode alterar o comportamento de segurança do seu agente sem que você toque em nada.
Onde isso quebra
Antes de sair aplicando esse resultado como se fosse uma condenação do SynthID, vale marcar onde a coisa é mais frágil do que parece.
Primeiro, o estudo mede refusal a nível de modelo, não comportamento fim-a-fim de agente com tools reais executando. A ponte entre “o modelo respondeu em vez de recusar” e “o agente executou uma ação danosa” existe, mas não foi medida diretamente no mesmo experimento. A Lasso é honesta sobre isso.
Segundo, o efeito é fortemente dependente do modelo. phi-4 e Qwen3-4B praticamente não se mexem em nenhum dos cenários, mas isso também não é boa notícia: os dois já tendem a over-refuse, inclusive em pedidos benignos. “Não muda” pode significar “já estava travado antes”.
Terceiro, a Anthropic sustenta o oposto sobre qualidade. Em testes internos, eles não viram impacto do watermarking no conteúdo, criatividade ou legibilidade do texto do Claude. No paper do SynthID-Text, o Google DeepMind testou isso servindo um modelo com watermark para uma fatia do tráfego do Gemini e comparando avaliações. Não encontraram diferenças estatisticamente significativas do modelo sem watermark. E num estudo controlado, avaliadores humanos comparando respostas com e sem marca lado a lado não viram diferença de qualidade. Isso não contradiz a Lasso: qualidade percebida em prosa e estabilidade de decisão em tool call são propriedades diferentes. Mas quem só ler o anúncio da Anthropic vai sair com a impressão errada.
Quarto, a técnica de prompt injection do estudo é uma só, fixa. Não sabemos como o efeito escala com técnicas diferentes ou combinadas.
Eu convivo com esse tipo de armadilha quando escrevo sobre ferramentas. Fiz um bot que explica qualquer assunto pelo universo geek que a pessoa gosta. Ele explicou recursão com A Origem e disse que os níveis de sonho rodavam em paralelo, o que no filme acontece e em recursão não. Encantador, confiante e errado exatamente no ponto que importava. Ninguém pegaria isso. Watermarking com efeito de sampling drift é a mesma classe de problema em escala industrial: a saída continua fluente, a métrica agregada quase não muda, e o erro específico passa em branco.
O que não dá para afirmar ainda
O estudo da Lasso usa modelos open weights rodando o processor do HuggingFace com configuração pública do SynthID-Text. Não é o Claude em produção, é uma implementação de referência. A Anthropic não publicou a configuração exata (número de camadas de torneio, tamanho do n-gram, esquema de chaves) da versão que roda nos modelos deles, e disse explicitamente que a implementação é uma versão do SynthID-Text, não a original. Então o quanto desse efeito você vai ver especificamente com Claude via API é uma pergunta aberta.
Também não dá para afirmar que o efeito se traduz linearmente para agentes de produção. Um agente real tem retries, validação de schema, camadas de guardrails, humano no loop em algumas rotas. Cada uma dessas camadas absorve parte do drift. Quanto? Depende do agente. Ninguém mediu ainda.
E há a questão de quanto o efeito depende de estar usando modelo pequeno. Os modelos do estudo vão de 4B a 27B parâmetros. Modelos maiores tendem a ter distribuições de tokens mais concentradas em muitos pontos, o que em tese daria menos margem para o torneio alterar a saída. Em tese.
Como testar isso você mesmo
Se você quer sentir o efeito sem montar um benchmark inteiro, o caminho mínimo é este:
- Instale
transformersrecente e escolha um modelo open weights (Llama-3.1-8B ou gemma-3-12b dão bem para reproduzir o efeito relatado). - Prepare dois pipelines de geração idênticos. Em um deles, adicione o
SynthIDTextWatermarkLogitsProcessorà lista de logits processors. No outro, não. - Fixe seed, temperatura e ordem de execução nos dois. A única diferença deve ser o processor.
- Rode o mesmo conjunto de prompts nos dois. Comece com prompts que peçam saída estruturada (um JSON de chamada de função com um argumento textual longo, tipo query ou path).
- Compare item a item. Não olhe só média. Conte quantos itens tiveram a resposta alterada, mesmo que as métricas agregadas pareçam iguais.
Um trecho mínimo do processor, para orientação:
from transformers import AutoModelForCausalLM, AutoTokenizer
from transformers.generation import SynthIDTextWatermarkingConfig
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")
tok = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")
wm_config = SynthIDTextWatermarkingConfig(
keys=[654, 400, 836, 123, 340, 443, 597, 160, 57, 29],
ngram_len=5,
)
out_wm = model.generate(**inputs, watermarking_config=wm_config, do_sample=True)
out_plain = model.generate(**inputs, do_sample=True) # mesmo seed, sem wm
A partir daí, se você opera um agente, o teste que importa é o pareado sob a mesma técnica de injection que você já usa no seu red team. Rode antes e depois de habilitar o watermark, olhe churn por item, não só a média. Se o número for baixo, ótimo. Se for alto e você não notou, era exatamente esse o ponto do estudo.
Watermarking existe por uma boa razão de proveniência, e o Artigo 50(2) do EU AI Act não vai a lugar nenhum. Mas a pesquisa nova sugere que as modificações do SynthID-Text à seleção de tokens podem ter consequências não intencionais além da escolha de palavras, incluindo influenciar quais ferramentas o modelo invoca e alterar a probabilidade de aderir ou ignorar seus guardrails de segurança. Isso é o tipo de propriedade que precisa entrar na sua bateria de avaliação, não ficar na nota de rodapé do provider.
