Dividiu o trabalho por treze agentes. O Paperclip não dividiu a chave.

Fez a coisa moderna. Em vez de um agente grande, montou uma frota — um para triar tickets, outro para escrever texto, outro para correr o pipeline de design, uma dúzia deles, cada um com a sua função e o seu config. Parece mais seguro assim. Raio de impacto menor. Mais privilégio mínimo.

Depois, uma análise de segurança percorreu os configs de uma framework de agentes com 71.000 estrelas chamada Paperclip e descobriu que doze dos seus treze agentes carregavam as mesmas credenciais — um token idêntico, colado em texto simples no config de cada agente [1]. Uma chave da API da Anthropic estava hardcoded, em claro, no config de um agente de design. Um bot token destinado a um agente era legível por agentes que nada tinham a ver com ele.

Treze portas. Uma chave, copiada para doze delas. Roube-a do agente mais fraco e tem as outras onze.

O que aconteceu realmente

O Paperclip dá a cada agente um config de servidor MCP — o ficheiro que diz ao agente a que ferramentas e serviços pode aceder, e como se autentica neles. Em algum ponto do caminho, os segredos foram diretamente para esses ficheiros como texto literal: um JWT do n8n, um bearer token, uma chave da API da Anthropic. Não por referência. Não injetados em runtime. Escritos à mão — e depois, porque criar o agente seguinte é copiar-colar, duplicados por toda a frota.

A análise assinalou três coisas. Os tokens partilhados em texto simples entre doze agentes (classificado HIGH). A chave da Anthropic em claro no config de um agente de design (classificado CRITICAL). E um bot token com âmbito alargado a agentes para os quais nunca foi pensado — uma falha simples de privilégio mínimo [1]. Em seu crédito, a equipa do Paperclip agiu depressa: migrou para referências de credenciais, passou a redigir o config em leituras entre agentes e começou a impor sincronização de binding [2]. A direção certa.

Isto não é o Paperclip a ser descuidado

Eis a parte que vale a pena ponderar. O Paperclip fez o que quase toda a framework faz. Pôr um segredo num ficheiro de config é a forma como o software se autentica há trinta anos. Funcionava porque havia uma aplicação, um config, um operador que sabia onde a chave estava guardada.

A época mudou por baixo desse hábito. Um sistema multi-agente não é uma aplicação com um config — é uma dúzia de processos, cada um com um ficheiro, cada um uma cópia do anterior. Texto simples no config era um atalho tolerável quando havia um único sítio por onde vazar. Com treze, o mesmo atalho significa que uma fuga são treze fugas — e “que agente fez aquilo?” não tem resposta, porque o token no log pertencia a todos eles.

As referências de credenciais — a correção que o Paperclip entregou — são genuinamente melhores. Mas repare no que mudam e no que não mudam. Uma referência continua a resolver-se para um segredo real no sítio onde o agente corre; o agente, ou qualquer coisa que o comprometa, continua a poder ler o valor resolvido. E o próprio bug tracker da framework já mostra o modo de falha seguinte: uma referência que dessincroniza do seu binding, fazendo com que o config pareça preenchido enquanto a validação falha silenciosamente [3]. O segredo recuou uma camada. Não saiu do edifício.

Não é só o Paperclip

Mesma semana, mesma causa de raiz, repositórios diferentes. Um agente de programação amplamente usado foi reportado por imprimir valores crus de .env — palavras-passe, tokens, chaves de API — diretamente para o seu output de chat. Outro runner de agentes foi encontrado a passar o ambiente completo do pai a subprocessos, tornando cada chave de fornecedor visível a um processo filho [4]. Um voice hook escrevia transcrições, credenciais incluídas, em /tmp legível por todos [5]. Equipas independentes, modelos de ameaça independentes, uma premissa partilhada: a de que está bem o segredo viver onde o agente o consegue ver. Todo o argumento que um atacante tem de fazer é que não está.

Construído para isto, de propósito

O Clavitor parte da premissa oposta: o agente nunca detém a credencial. Pede uma ação; o pedido é intercetado, autenticado contra um segredo que o agente não consegue ler, e executado. Não há config onde colar um token, porque não há token no config. Nada a copiar por treze agentes, porque o ambiente do agente nunca contém aquilo que vale a pena roubar.

Cada agente acede apenas ao que foi nomeado para aceder — não a todo o armazenamento — por isso um bot token não pode acabar legível por um agente que nunca o pediu. E cada ação é registada no ator específico que a executou, nunca num token partilhado que doze agentes tinham em comum — por isso “qual deles fez aquilo?” tem resposta.

O limite honesto: isto não torna um agente à prova de hacking. Um agente comprometido continua a poder fazer, no momento, as coisas a que estava autorizado. O que não pode é ir-se embora com a chave e tornar-se os outros doze — porque não há chave nas suas mãos para levar.

A lição não é “rodar o token”

O Paperclip vai rodar os tokens, concluir a migração e fechar as issues. Bem — deve. Mas a rotação não é a lição. A lição é que, no momento em que tem uma frota de agentes em vez de uma aplicação, “o segredo vive no config” deixa de ser um atalho e passa a ser um multiplicador. Não resolve um multiplicador tornando o segredo um pouco mais difícil de ler. Resolve-se garantindo que o segredo nunca esteve nas mãos do agente.

Escrevemos as regras que achamos que uma ferramenta de credenciais deve cumprir na era dos agentes — entre elas, a de que o segredo nunca vive onde o código corre, e a de que um agente acede apenas ao que foi nomeado. Teste as suas contra elas: clavitor.ai/rules.

Clavitor (@clavitorai) é o cofre de credenciais construído para agentes de IA, e contra eles. clavitor.ai

Fontes

[1] Framework de agentes Paperclip — conclusões de higiene de credenciais (CFG-H1 tokens partilhados em texto simples, CFG-C1 chave da Anthropic hardcoded, CFG-H2 bot token com âmbito incorreto): https://github.com/paperclipai/paperclip

[2] Paperclip — impor sincronização de binding de segredos dos agentes em fluxos de ciclo de vida (merged): https://github.com/paperclipai/paperclip/pull/8307

[3] Paperclip — entradas secret_ref em env podem dessincronizar das linhas de secret_bindings, o config parece preenchido mas a validação falha silenciosamente (#8309): https://github.com/paperclipai/paperclip/issues/8309

[4] Chetter — runBatchAgent herda o ambiente completo do runner, expondo chaves de API de fornecedores ao subprocesso (#56): https://github.com/flatout-works/chetter/issues/56

[5] Voice hook do Claude Code — transcrições completas (credenciais incluídas) escritas em /tmp legível por todos (#58): https://github.com/rodlaneedu-hash/claude-code-voice-hook/issues/58