When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

No mundo moderno da criação de software, um novo tipo de ajudante surgiu: o agente de codificação. Estes são programas de inteligência artificial que podem escrever código, corrigir erros e gerir ficheiros tal como um programador humano faria. Para manter estes assistentes digitais seguros e no caminho certo, os programadores escrevem ficheiros de instruções. Pense nestes ficheiros como um conjunto de regras escritas, como uma receita ou um código de conduta, onde um humano diz ao agente o que ele tem permissão para fazer e o que nunca deve fazer. Um programador pode escrever: "Nunca guarde palavras-passe em texto simples" ou "Pergunte antes de apagar dados importantes". Durante anos, este método de dar instruções tem sido a forma padrão de guiar estas ferramentas inteligentes. A suposição tem sido que, se escrever uma regra claramente, o agente irá compreendê-la e segui-la, criando um ambiente seguro para o software que está a ser construído.

No entanto, um estudo recente do investigador Ting Yan revela uma lacuna silenciosa mas significativa neste sistema. A investigação foca-se num tipo específico de ficheiro de instruções utilizado com um agente de codificação popular chamado Claude Code. O estudo faz uma pergunta simples, mas crítica: quando um programador escreve uma regra de segurança em linguagem natural, o software tem realmente um mecanismo integrado para aplicar essa regra, ou a regra é apenas uma sugestão que a inteligência artificial tem de adivinhar como seguir? As conclusões sugerem que, para a vasta maioria destas regras escritas, a resposta é esta última. O ficheiro funciona como uma rua de sentido único onde o programador fala, mas o sistema nunca confirma se a regra está a ser aplicada. Isto cria uma falsa sensação de segurança, onde um programador acredita que uma ação perigosa está bloqueada, quando, na realidade, o sistema está apenas a confiar que a inteligência artificial se lembre e obedeça à instrução sem que haja uma interrupção rígida em vigor.

Para compreender a escala deste problema, os investigadores recolheram quase quinhentos ficheiros de instruções públicos de programadores de todo o mundo. Eles trataram estes ficheiros como uma coleção de notas manuscritas, analisando-os linha por linha para encontrar frases que soassem a regras de segurança. Procuraram por expressões como "não deve", "nunca" ou "não faça", que sinalizam uma restrição. A partir destes ficheiros, extraíram milhares de regras candidatas. O passo seguinte foi atuar como um tradutor entre a linguagem humana da regra e a linguagem técnica do software. Perguntaram se o agente de codificação específico, o Claude Code, já possuía um interruptor ou configuração integrada que pudesse bloquear automaticamente a ação descrita na regra. Por exemplo, se uma regra dissesse "não execute este comando específico", os investigadores verificaram se o software tinha uma configuração de permissão que pudesse simplesmente negar esse comando antes mesmo de ele acontecer. Se o software não tivesse tal interruptor, a regra era deixada para a inteligência artificial interpretar, o que significa que o agente teria de decidir por si próprio se seguia a instrução.

Os resultados desta comparação foram gritantes. Quando os investigadores aplicaram um padrão rigoroso — exigindo que o controlo integrado cobrisse a ação exata, o alvo exato e a condição exata da regra escrita — apenas uma minúscula fração das regras tinha um mecanismo de segurança correspondente. Especificamente, descobriram que apenas cerca de quatro a seis por cento das regras de segurança que os programadores escreveram eram sustentadas por um controlo integrado que poderia aplicá-las sem qualquer trabalho extra. Mesmo quando utilizaram um padrão mais frouxo, permitindo correspondências parciais, o número subiu para apenas cerca de dezasseis por cento. Isto significa que, para aproximadamente noventa e cinco por cento das regras de segurança escritas nestes ficheiros, não havia uma rede de segurança automática. A regra existia apenas como texto, dependendo inteiramente da inteligência artificial para a interpretar corretamente todas as vezes.

O estudo também analisou por que razão tantas regras careciam de uma correspondência. Os investigadores descobriram que as regras pediam frequentemente coisas que as ferramentas integradas do software simplesmente não conseguiam ver ou fazer. Uma regra poderia dizer: "Nunca submeta segredos para o código", mas as configurações de permissão do software podem bloquear um caminho de ficheiro ou um comando, não o conteúdo real dentro de um ficheiro. Para aplicar uma regra sobre segredos, o software precisaria de ler o ficheiro e compreender o que está lá dentro, o que é uma tarefa que não consegue realizar com as suas definições padrão. Da mesma forma, uma regra poderia exigir a verificação do estado de um sistema ou a obtenção de aprovação de uma pessoa específica, detalhes que os controlos integrados não poderiam aceder. Nestes casos, a regra não era um comando que o software pudesse executar; era um pedido para a inteligência artificial usar o seu julgamento. Os investigadores notaram que esta distinção é invisível para o programador. O ficheiro de instruções parece o mesmo, quer uma regra esteja a ser aplicada por um bloqueio rígido do sistema ou pela memória suave e falível de uma inteligência artificial.

Esta falta de feedback cria o que os investigadores chamam de um canal de "escrita apenas". Na maioria do desenvolvimento de software, quando um programador escreve uma regra, recebe feedback imediato. Se escrever um código que quebre uma regra, o computador pode recusar executá-lo, ou um teste pode falhar, informando-o imediatamente de que algo está errado. Com estes ficheiros de instruções, não existe tal sinal. Um programador pode escrever uma regra, prosseguir e nunca saber se o agente a está realmente a seguir. O estudo destaca que isto é particularmente arriscado para programadores novos em segurança. Eles podem escrever uma regra pensando que asseguraram o seu sistema, sem perceber que o sistema não tem forma de aplicar essa restrição específica. A inteligência artificial pode seguir a regra a maior parte do tempo, mas também pode cometer erros, confundir-se ou ser enganada por outros inputs, deixando o sistema vulnerável.

Os investigadores não descobriram que o software estivesse avariado ou que os programadores estivessem a fazer algo errado. Em vez disso, identificaram uma falha de design na forma como estas ferramentas comunicam com os seus utilizadores. As ferramentas permitem que os utilizadores escrevam regras em linguagem natural, o que é fácil e intuitivo, mas não informam o utilizador sobre quais dessas regras estão realmente a ser aplicadas pelo sistema e quais são apenas sugestões. O estudo sugere que, para estas ferramentas serem verdadeiramente seguras, precisam de fechar este ciclo. Precisam de dar aos programadores uma forma de ver quais as regras que são sustentadas por controlos rígidos e quais não são. Idealmente, o software deveria alertar um programador se este escrever uma regra que o sistema não consegue aplicar, ou deveria ajudá-lo a transformar essa regra numa configuração que o sistema possa realmente utilizar. Até que este ciclo de feedback seja fechado, a segurança destes sistemas dependerá fortemente da esperança de que a inteligência artificial se lembre e obedeça a cada instrução perfeitamente, uma esperança que os dados mostram estar muitas vezes mal depositada.

O estudo conclui enfatizando que este é um problema solucionável, mas requer uma mudança na forma como estas ferramentas são construídas. A lacuna entre o que um programador escreve e o que o sistema aplica não é um mistério; é um facto mensurável. Ao medi-lo, os investigadores demonstraram que a forma atual de assegurar estes agentes é incompleta. A solução reside em tornar o invisível visível, garantindo que, quando um programador escreve uma regra, saiba exatamente que tipo de proteção ela proporciona. Isto transformaria o ficheiro de instruções de uma nota de via única num diálogo de duas vias, onde o sistema confirma que as regras não estão apenas escritas, mas verdadeiramente a funcionar.