Os agentes de IA autoevolutivos são projetados para melhorar, transformando interações passadas em habilidades reutilizáveis. Um novo artigo de pesquisa mostra por que esse recurso cria um problema de segurança diferente: uma interação envenenada pode se tornar um recurso armazenado que é recuperado novamente mais tarde, mesmo quando a solicitação futura do usuário parece benigna.
Os autores de EvoSkill Injection definem um modelo de ameaça para essa falha e apresentam SARGE, uma estrutura de equipe vermelha multiagente que tenta fazer com que agentes em autoevolução gerem, escalonem e reforcem habilidades maliciosas. A importante implicação arquitetônica é mais ampla do que as taxas de ataque relatadas. Depois que um agente grava o comportamento executável em um armazenamento de habilidades persistente, esse armazenamento se torna parte do limite de segurança.
O ataque visa o aprendizado, não apenas a resposta atual
Os testes convencionais de injeção imediata e jailbreak geralmente perguntam se um invasor pode fazer um modelo produzir ou executar algo inseguro agora. EvoSkill Injection tem como alvo um mecanismo de vida mais longa. O invasor fornece uma trajetória de interação adversária e então enquadra o comportamento resultante como uma experiência bem-sucedida que deve ser salva e reutilizada.
O artigo avalia três sistemas autoevolutivos, AutoSkill, Voyager e ExpeL. O SARGE utiliza um orquestrador, agentes de ataque e um juiz para testar três estágios: gerar uma habilidade maliciosa, escalar uma habilidade existente e reforçar uma habilidade para que o agente a trate como um comportamento preferencial. Uma nova sessão é então usada para testar se o recurso armazenado sobrevive e é ativado novamente.
Os autores relatam taxas de sucesso de ataque pass@4 de 43.5% para geração, 54.6% para escalonamento e 49.9% para reforço na configuração AutoSkill baseada em GPT-4o-mini. Esses números são resultados de pesquisas, não taxas de produção estabelecidas, mas demonstram o mecanismo que o artigo está tentando isolar.
A persistência muda o limite do controle
A descoberta mais importante é o que acontece após o ataque. No EvoSkillSafetyBench do jornal, a taxa de resposta prejudicial relatada para o AutoSkill aumentou de 6.5% na condição limpa para 19.2% após o ataque. A Voyager subiu de 5.5% para 32.5%, enquanto a ExpeL subiu de 8.8% para 15.2%. Os autores também relatam aumentos em vários backbones de modelos.
Para as equipes de engenharia, isso sugere que um banco de habilidades não deve ser tratado como um cache comum de contexto útil. Está mais próximo do estado persistente executável. Uma habilidade pode codificar padrões de uso de ferramentas, ações baseadas em código ou procedimentos de decisão, e seu efeito pode sobreviver à interação que a criou.
Isso muda o modelo mínimo de governança. Um sistema de produção precisa saber de onde veio uma habilidade, qual interação causou sua criação, qual versão da política a aprovou, quais permissões ela pode exercer, qual agente ou inquilino pode recuperá-la e como ela pode ser desativada ou revertida. Sem essa origem, uma camada de otimização aparentemente útil pode se tornar um caminho durável de amplificação de privilégios.
As proteções de saída não podem reparar o estado corrompido
O artigo testa defesas leves com base na verificação de habilidades e em instruções de resolução de conflitos. Os autores afirmam que estas medidas reduzem as respostas prejudiciais, mas também aumentam as recusas e não impedem que competências maliciosas sejam geradas, armazenadas ou evoluídas.
Essa distinção é importante. Um filtro de resposta pode impedir que um recurso armazenado se manifeste de uma só vez, sem remover o recurso em si. O próximo modelo, caminho da ferramenta ou condição de recuperação pode ativar a mesma habilidade envenenada de maneira diferente. Em outras palavras, a segurança da saída e a integridade do estado são problemas separados.
Portanto, um design mais robusto precisa de controles no limite de gravação. A criação e atualizações de competências devem ser verificadas por políticas antes da persistência, as competências de alto risco podem exigir validação determinística ou aprovação humana, e as competências armazenadas devem ter proveniência e versões imutáveis. A recuperação também precisa de controles de escopo para que uma habilidade aprendida em uma tarefa não possa ganhar autoridade silenciosamente em outra.
O autoaperfeiçoamento cria uma cadeia de suprimentos dentro do agente
A segurança tradicional da cadeia de suprimentos de software pergunta de onde vieram o código e as dependências antes de entrarem no sistema. Agentes autoevolutivos criam uma cadeia de suprimentos menor dentro do tempo de execução: as interações tornam-se experiências candidatas, as experiências tornam-se habilidades e as habilidades posteriormente influenciam as ações.
O modelo de ameaça do documento é útil porque identifica a transição da experiência para a capacidade reutilizável como uma etapa de construção sensível à segurança. As equipes que já verificam habilidades de terceiros ou servidores MCP ainda podem perder esse caminho se as habilidades geradas internamente forem automaticamente confiáveis apenas porque o próprio agente as criou.
O controle prático é não desabilitar o aprendizado. É separar a proposta de uma habilidade da sua autorização. Um agente pode gerar uma habilidade candidata, mas uma camada de política diferente deve decidir se ela pode ser armazenada, qual escopo ela recebe e se modificações posteriores requerem validação renovada.
A evidência é importante, mas limitada
Este é um resultado de pesquisa arXiv v1, e os autores afirmam que o artigo foi aceito no EMNLP 2026. A avaliação abrange estruturas selecionadas de autoevolução, em vez de cada arquitetura de agente. Baseia-se em trajetórias de ataque construídas, chamadas repetidas de modelos e um juiz baseado em LLM, e os autores observam que modelos de atacantes ou juízes mais fortes podem alterar os resultados. O EvoSkillBench também cobre oito categorias selecionadas de alto risco, em vez de todo o espaço dos ataques do mundo real.
Essas limitações significam que as percentagens comunicadas não devem ser interpretadas como estimativas da frequência com que os agentes de produção são comprometidos. A conclusão mais forte é arquitetónica: os sistemas que convertem autonomamente a experiência em comportamento reutilizável têm uma camada de persistência que pode ser envenenada e os mecanismos de segurança precisam de proteger diretamente essa camada.
Para equipes que constroem agentes de longa duração, a revisão de segurança deve, portanto, incluir todo o ciclo de vida da habilidade: geração, validação, armazenamento, controle de versão, recuperação, execução e exclusão. Depois que os agentes puderem aprender suas próprias ferramentas e rotinas, controlar o que eles lembram não será mais suficiente. As organizações também têm que governar aquilo que lhes é permitido tornar-se.