Memory Infection: como hackers infectam a memória dos seus agentes de IA sem você perceber

Sistemas de IA agênticos estão se tornando cada vez mais sofisticados, mas com autonomia crescente vêm novos vetores de ataque. Em um hackathon interno recente focado em segurança de IA, pesquisadores descobriram algo preocupante: é possível manipular gradualmente a memória persistente de um agente de IA até que ele execute comandos maliciosos, sem precisar de exploits tradicionais ou injeção de prompts.

O experimento foi conduzido em ambiente controlado de laboratório, utilizando o OpenClaw - uma plataforma de agentes de IA open-source. O que começou como uma análise de segurança revelou uma vulnerabilidade fundamental em sistemas com memória de longo prazo: a capacidade de "envenenar" gradualmente a memória do agente até modificar seu comportamento de execução.

O experimento: condicionando um agente através do Discord

A configuração era deliberadamente minimalista. Um agente OpenClaw rodando localmente com GPT-4.1-o-mini, sem skills adicionais habilitados, apenas com integração ao Discord. Nenhum sistema de produção foi envolvido, e nenhum dado corporativo estava conectado.

O agente estava rodando com privilégios administrativos na máquina de teste - uma configuração comum em ambientes locais. O objetivo era observar como o comportamento do agente evoluiria sob condições típicas de uso.

Importante: O usuário que eventualmente conseguiu acionar a execução maliciosa não tinha privilégios administrativos no Discord. Esta é uma distinção crítica que demonstra a natureza do ataque.

Como a memória persistente funciona

O OpenClaw mantém estado persistente em um diretório local de workspace:

.openclaw/workspace/

Dentro deste diretório, existe um arquivo chamado MEMORY.md que armazena contexto de longa duração que persiste entre sessões. Adicionalmente, há um subdiretório memory/ para entradas mais granulares e temporais, como arquivos de memória diária.

O experimento focou especificamente no arquivo global MEMORY.md, que influencia comportamento durável através de sessões. Este arquivo molda como o agente interpreta:

• Relacionamentos de confiança

• Preferências comportamentais

• Continuidade de tarefas

• Prioridade de instruções

Diferente do contexto transitório de conversação, entradas no MEMORY.md tornam-se parte do estado durável do agente. Elas sobrevivem a reinicializações e influenciam tomadas de decisão subsequentes.

Instruction drift: a mudança gradual de comportamento

O mecanismo-chave foi o que chamamos de "instruction drift" - deriva de instruções.

Através de interações repetidas, a priorização interna do agente mudou. Um usuário sem privilégios administrativos no Discord foi gradualmente tratado como uma autoridade confiável.

Algumas clarificações importantes:

• O usuário que acionou a execução não tinha privilégios elevados no Discord

• A configuração base do agente não concedia autoridade de execução especial

• Tentativas diretas de execução sem condicionamento prévio não tiveram sucesso

Tentativas anteriores de acionar execução sem reforço de memória falharam. O modelo resistia a instruções maliciosas diretas quando nenhum contexto de confiança havia sido estabelecido.

Somente após entradas de memória terem acumulado padrões de reforço é que a execução se tornou viável. O agente começou a elevar as requisições do usuário condicionado acima de sua hierarquia de instruções original.

Isso não foi tanto uma injeção de prompt, mas uma evolução de estado.

Execução de reverse shell: o ataque bem-sucedido

Uma vez que as premissas de confiança do agente haviam mudado, a execução seguiu um caminho previsível.

O binário malicioso foi apresentado como uma atualização de sistema consistente com interações anteriores. O condicionamento de memória anterior havia estabelecido o usuário requisitante como confiável. A requisição de atualização foi estruturada para alinhar com comportamentos previamente aprovados.

Como a execução de ferramentas já estava disponível no ambiente, o agente tinha capacidade de executar comandos shell. A arquitetura permitia isso.

A requisição acionou a execução de um binário local. Nos testes, isso incluiu um payload de reverse shell, resultando em acesso remoto à máquina.

Nenhuma escalação de privilégios foi necessária. O agente executou dentro das permissões já concedidas ao seu processo.

Tentativa de execução falha (sem condicionamento de memória)

Nas primeiras tentativas, sem o condicionamento adequado da memória, o agente resistiu a comandos de execução direta. O modelo manteve sua postura de segurança inicial.

Execução após condicionamento de memória

Após múltiplas interações que reforçaram padrões de confiança na memória persistente, o agente executou o binário como se fosse uma requisição legítima de atualização do sistema.

No vídeo de demonstração (não disponível neste artigo), o executável abre o Chrome e carrega um vídeo do YouTube da Lakera. Para fins de ilustração, o lançamento do navegador serve como um indicador visível de execução bem-sucedida do binário. Como o executável não é legível por humanos, o modelo não consegue determinar seu conteúdo sem ferramentas adicionais e o tratou como uma atualização legítima do sistema.

O que isso demonstra sobre segurança de agentes de IA

Este experimento destaca várias realidades arquiteturais preocupantes:

1. Memória persistente influencia comportamento de execução

Estado de longa duração pode moldar como instruções futuras são interpretadas. A memória não é apenas um recurso de conveniência - ela se torna uma camada de política implícita.

2. Hierarquia de instruções é mutável

Relacionamentos de autoridade não são necessariamente estáticos. Com o tempo, padrões na memória podem elevar certas fontes de entrada acima de outras.

3. Execução de ferramentas herda premissas de confiança

Quando fronteiras de confiança mudam, caminhos de execução seguem. O agente não questionou o binário porque o contexto de confiança havia sido estabelecido.

4. Integridade de memória torna-se uma fronteira de segurança

Se estado persistente pode ser influenciado sem validação, decisões de execução podem derivar ao longo do tempo.

Implicações práticas para arquiteturas de agentes

Sistemas de agentes que combinam memória e capacidades de execução devem tratar estado persistente como crítico para segurança.

Considerações arquiteturais fundamentais:

À medida que agentes se tornam mais autônomos e persistentes, a superfície de ataque muda. Considerações de segurança se estendem além de injeção de prompt para incluir evolução de estado de longa duração.

Memory poisoning não é injeção de prompt

É crucial entender que este ataque não é uma variante de prompt injection. Memory poisoning é fundamentalmente diferente:

Prompt Injection:

• Ataque de sessão única

• Tenta contornar instruções imediatas

• Detectável em tempo real

• Mitigável com validação de entrada

Memory Poisoning:

• Ataque de múltiplas sessões

• Modifica estado persistente gradualmente

• Difícil de detectar em tempo real

• Requer validação de integridade de memória

A diferença é crítica para estratégias de defesa. Proteções contra prompt injection não são suficientes para prevenir memory poisoning.

Contexto mais amplo: o ecossistema OpenClaw

Este experimento foi parte de um hackathon de segurança mais amplo. A segunda trilha de pesquisa examinou o marketplace de skills do OpenClaw em escala, revelando riscos adicionais relacionados a malware delivery através de extensões de agentes.

Para organizações implementando agentes de IA, é essencial compreender que:

• Agentes com memória persistente podem ter seu comportamento modificado ao longo do tempo

• Execução de ferramentas deve sempre ocorrer em ambientes restritos

• Privilégios devem seguir o princípio de menor acesso por padrão

• Validação de integridade de memória deve ser implementada

• Sistemas de monitoramento devem detectar desvios de comportamento

Perguntas frequentes

Isso significa que todos os agentes de IA são vulneráveis?

Não necessariamente. A vulnerabilidade depende de como memória persistente e execução de ferramentas são implementadas. Agentes sem memória de longo prazo ou sem capacidades de execução têm superfície de ataque diferente.

Como posso proteger meus agentes dessa vulnerabilidade?

Implemente validação de integridade de memória, execute agentes em ambientes sandboxed com privilégios mínimos, e estabeleça modelos de confiança explícitos ao invés de confiar em premissas emergentes.

Isso é específico do OpenClaw?

Não. A vulnerabilidade fundamental existe em qualquer sistema de agente que combine memória persistente mutável com capacidades de execução. OpenClaw foi usado como plataforma de pesquisa, mas o princípio se aplica amplamente.

Memory poisoning pode ser detectado?

Sim, mas requer monitoramento ativo. Sistemas devem rastrear mudanças em estado de memória persistente e detectar desvios anômalos em padrões de autoridade ou execução.

Conclusão: segurança de agentes requer nova abordagem

Conforme sistemas de IA se tornam mais autônomos, as considerações de segurança evoluem. Memory poisoning representa uma classe de vulnerabilidade que vai além de ataques tradicionais de injeção.

Para CISOs e equipes de segurança implementando agentes de IA:

• Trate memória persistente como superfície de ataque

• Implemente validação de integridade para estado de longo prazo

• Execute agentes com princípio de menor privilégio

• Estabeleça modelos de confiança explícitos

• Monitore desvios de comportamento ao longo do tempo

A convergência de memória, autonomia e execução de ferramentas cria novas realidades de segurança. As arquiteturas devem evoluir para endereçar esses riscos de forma proativa.

Para mais informações sobre segurança de agentes de IA e práticas recomendadas, acompanhe as discussões no Data Hackers e participe da nossa comunidade de profissionais explorando os desafios de segurança em sistemas de IA.