GhostWriter e o envenenamento da memória de agentes de IA

GhostWriter e o envenenamento da memória de agentes de IA: a nova fronteira dos ataques cibernéticos persistentes

A evolução da inteligência artificial generativa está conduzindo o mercado de tecnologia para uma nova geração de sistemas capazes não apenas de conversar, mas também de executar tarefas, utilizar ferramentas externas, consultar bancos de dados, navegar pela internet, interagir com aplicações e tomar decisões com diferentes níveis de autonomia.

Essa transformação deu origem aos chamados agentes de inteligência artificial.

Diferentemente de um chatbot tradicional, que normalmente responde a uma solicitação dentro de uma única sessão, um agente pode manter informações ao longo do tempo para personalizar suas respostas e melhorar a execução de tarefas futuras. Ele pode recordar preferências, decisões anteriores, instruções de trabalho e informações relevantes sobre o ambiente em que opera.

A memória persistente tornou-se, portanto, um dos componentes mais importantes da arquitetura dos sistemas agentivos.

Mas existe um problema.

Quanto mais um agente de IA se lembra, maior pode ser sua superfície de ataque.

Uma memória capaz de influenciar decisões futuras também pode ser utilizada como mecanismo de persistência por um invasor.

Esse é o cenário por trás do chamado memory poisoning, ou envenenamento de memória, uma categoria de ameaça que começa a receber atenção crescente da comunidade de segurança cibernética.

O conceito ganhou destaque em estudos recentes sobre agentes baseados em grandes modelos de linguagem, os LLMs, e também foi abordado em reportagem publicada pelo iMasters sobre uma técnica denominada GhostWriter, descrita como uma forma de manipulação da memória de longo prazo de agentes de IA. Segundo a publicação, o ataque busca inserir instruções ocultas que posteriormente podem ser recuperadas pelo sistema e influenciar seu comportamento em interações futuras.

 

A gravidade dessa ameaça está justamente na sua persistência.

Um ataque tradicional de prompt injection pode afetar uma única interação.

O envenenamento de memória pode permanecer adormecido durante dias, semanas ou até mais tempo, esperando que uma determinada condição seja satisfeita.

Nesse cenário, o atacante não precisa necessariamente controlar o modelo de inteligência artificial.

Ele precisa influenciar aquilo que o agente acredita ser uma informação confiável.

E essa diferença pode representar uma mudança importante na segurança dos sistemas de IA.

 

A evolução dos chatbots para agentes autônomos

Para compreender o risco, é necessário entender como os sistemas de IA estão evoluindo.

Um chatbot tradicional recebe uma pergunta e produz uma resposta.

O ciclo é relativamente simples:

usuário → modelo → resposta.

Um agente de IA possui uma arquitetura muito mais complexa.

O fluxo pode envolver:

usuário → modelo → memória → ferramentas → APIs → bancos de dados → sistemas externos → ação.

Essa ampliação de capacidades permite que o agente realize atividades mais sofisticadas.

Um sistema pode:

• consultar documentos;

• analisar e-mails;

• acessar sistemas corporativos;

• executar código;

• criar arquivos;

• realizar pesquisas;

• atualizar bancos de dados;

• interagir com APIs;

• automatizar processos.

A vantagem é evidente.

A superfície de risco também.

Cada novo componente cria uma possibilidade adicional de entrada, manipulação ou abuso.

 

A memória persistente como nova superfície de ataque

A memória existe para resolver um problema conhecido dos modelos de linguagem: a falta de continuidade entre diferentes interações.

Imagine um assistente corporativo que precisa lembrar que determinado funcionário prefere relatórios em PDF.

Sem memória, essa informação precisa ser fornecida novamente.

Com memória persistente, o agente pode armazenar essa preferência e utilizá-la posteriormente.

O mesmo mecanismo pode armazenar:

• preferências;

• decisões;

• fatos sobre o usuário;

• instruções;

• informações de projetos;

• histórico de interações.

O problema surge quando o sistema não consegue distinguir adequadamente entre:

informação confiável

e

informação manipulada.

Se qualquer conteúdo externo puder ser transformado em memória persistente sem validação adequada, o armazenamento deixa de ser apenas um recurso de personalização.

Ele se transforma em uma possível porta de entrada para ataques.

 

O que é memory poisoning

O envenenamento de memória ocorre quando um atacante consegue fazer com que uma informação falsa, manipulada ou maliciosa seja armazenada e posteriormente recuperada por um agente de IA como se fosse uma informação legítima.

A lógica básica pode ser representada assim:

entrada maliciosa → armazenamento → persistência → recuperação → influência sobre decisão.

O aspecto mais preocupante é que o ataque pode ser dividido em momentos diferentes.

A primeira etapa ocorre quando a informação é introduzida.

A segunda acontece quando a memória é consolidada.

A terceira surge quando o sistema recupera aquele conteúdo.

A quarta aparece quando o agente utiliza a informação contaminada para tomar uma decisão.

Isso cria uma distância temporal entre o ataque e seus efeitos.

O invasor pode plantar uma informação hoje.

O agente pode utilizá-la somente semanas depois.

Essa característica dificulta a investigação.

 

GhostWriter: quando o ataque fica escondido na memória

O conceito de GhostWriter apresentado pelo iMasters ilustra justamente essa possibilidade.

Segundo a publicação, o atacante busca inserir conteúdo oculto na memória persistente do agente. Posteriormente, quando uma solicitação relacionada ao assunto contaminado é realizada, o sistema recupera aquele registro e passa a considerar a informação como parte de seu contexto.

O comportamento pode ser comparado a um ataque de “cavalo de Troia”.

O conteúdo parece inofensivo no momento em que é armazenado.

Entretanto, possui uma instrução ou informação capaz de produzir efeitos posteriores.

A grande diferença para um malware convencional é que o código malicioso não precisa necessariamente estar instalado no sistema operacional.

A persistência pode existir no próprio contexto cognitivo utilizado pelo agente.

 

Uma nova forma de persistência

Na segurança tradicional, um atacante procura mecanismos de persistência como:

• tarefas agendadas;

• serviços;

• chaves de registro;

• backdoors;

• contas privilegiadas;

• scripts;

• malware.

Em sistemas agentivos, surge uma possibilidade adicional:

persistência sem necessariamente manter um código executável.

O invasor tenta permanecer presente na memória utilizada para orientar o agente.

Isso é particularmente preocupante porque as ferramentas tradicionais de segurança podem não identificar esse tipo de manipulação.

Um antivírus pode verificar arquivos.

Um EDR pode monitorar processos.

Um firewall pode controlar conexões.

Mas nenhum desses mecanismos, isoladamente, consegue determinar se uma informação armazenada em uma memória vetorial é verdadeira ou maliciosa.

 

Memory poisoning não é simplesmente prompt injection

Os dois conceitos estão relacionados, mas não são idênticos.

No prompt injection tradicional, o atacante tenta manipular o modelo por meio de instruções inseridas no contexto atual.

Por exemplo, um documento pode conter uma instrução maliciosa destinada a influenciar a resposta do modelo.

O efeito pode desaparecer quando a interação termina.

No memory poisoning, o objetivo é diferente.

O atacante tenta fazer com que a informação maliciosa seja armazenada e posteriormente reutilizada.

A diferença fundamental é a persistência.

Podemos representar:

Prompt Injection

Ataque → processamento → resposta comprometida.

Memory Poisoning

Ataque → armazenamento → persistência → recuperação futura → comportamento comprometido.

Essa diferença aumenta significativamente a complexidade da defesa.

Pesquisas recentes sobre envenenamento de memória identificaram múltiplos canais pelos quais informações adversariais podem chegar ao armazenamento persistente e apontaram vulnerabilidades estruturais em capacidades do modelo, desenho de prompts e arquitetura dos agentes. O estudo também observou que defesas tradicionais contra prompt injection não cobrem necessariamente os ataques contra a camada de memória.

 

O ataque pode atravessar sessões

Imagine que um agente corporativo seja utilizado diariamente por uma equipe.

Durante uma determinada interação, o sistema processa um documento contaminado.

O conteúdo malicioso consegue influenciar o mecanismo de memória.

A sessão termina.

No dia seguinte, outro usuário utiliza o mesmo agente.

O ataque continua.

Isso significa que a vítima que introduziu a informação maliciosa não precisa ser a mesma pessoa que sofrerá as consequências.

Essa característica torna o problema especialmente relevante em ambientes corporativos.

Uma memória compartilhada pode transformar um ataque localizado em uma ameaça organizacional.

 

O risco da memória compartilhada

Sistemas de IA podem utilizar diferentes modelos de armazenamento.

A memória pode ser:

• individual;

• por usuário;

• por equipe;

• por projeto;

• global.

Quanto maior o compartilhamento, maior a necessidade de controle de acesso.

Se uma informação inserida por um usuário puder influenciar as respostas fornecidas a outros usuários, o sistema precisa garantir isolamento adequado.

Caso contrário, um atacante pode tentar contaminar a memória de um ambiente inteiro.

Essa ameaça é particularmente relevante para agentes corporativos conectados a sistemas de conhecimento compartilhados.

 

O perigo dos bancos vetoriais

Muitos sistemas de IA utilizam bancos vetoriais para armazenar informações que posteriormente serão recuperadas por similaridade semântica.

O processo geralmente envolve:

• transformar o conteúdo em embeddings;

• armazenar os vetores;

• realizar uma consulta;

• localizar conteúdos semanticamente relacionados;

• enviar os resultados ao modelo.

Esse mecanismo é eficiente.

Mas cria uma nova questão.

O banco vetorial pode conter informações de diferentes níveis de confiabilidade.

Se um conteúdo malicioso for armazenado e posteriormente recuperado, o agente pode interpretá-lo como contexto relevante.

O problema não está necessariamente no algoritmo de busca.

Está na confiança atribuída ao resultado.

 

A ameaça do “trust laundering”

Um conceito particularmente relevante é a chamada lavagem de confiança.

O conteúdo original pode vir de uma fonte não confiável.

Depois, é armazenado.

Posteriormente, é recuperado como memória.

Ao ser apresentado ao modelo dentro de um contexto aparentemente confiável, perde-se a informação sobre sua origem.

A informação passa por uma transformação:

fonte desconhecida → memória interna → contexto confiável.

O agente pode deixar de saber de onde aquela informação veio.

Esse problema de proveniência é um dos grandes desafios da segurança de sistemas agentivos.

Uma memória sem histórico confiável de origem pode transformar conteúdo externo em uma falsa autoridade.

 

Ataques silenciosos são mais perigosos

Um ataque que altera imediatamente o comportamento do sistema pode ser detectado rapidamente.

Um ataque silencioso é diferente.

O invasor pode introduzir uma informação que:

• parece normal;

• não produz efeitos imediatos;

• não gera alertas;

• permanece armazenada;

• é ativada somente em condições específicas.

Esse modelo é semelhante ao conceito de sleeper attack.

Pesquisas recentes estudaram justamente ataques em que conteúdo externo manipula a memória de um agente e permanece dormente até ser recuperado em uma interação posterior. Em um estudo sobre “sleeper memory poisoning”, os pesquisadores avaliaram ataques em que memórias falsas são introduzidas por meio de documentos, páginas ou repositórios e posteriormente influenciam ações do agente.

 

A memória pode se transformar em uma arma

A memória foi projetada para melhorar a experiência do usuário.

Ela permite personalização.

Permite continuidade.

Permite aprendizado contextual.

Mas essas mesmas características podem ser exploradas.

Um atacante pode tentar influenciar:

• quais informações o agente considera confiáveis;

• quais fontes recomenda;

• quais procedimentos executa;

• quais decisões prioriza;

• quais ferramentas utiliza.

Nesse sentido, a memória pode funcionar como uma espécie de camada de controle indireto.

O atacante não precisa controlar o modelo.

Pode tentar controlar o contexto que orienta o modelo.

 

O impacto em agentes com acesso a ferramentas

O risco aumenta significativamente quando o agente possui capacidade de executar ações.

Um chatbot que produz uma resposta incorreta pode causar desinformação.

Um agente que executa ações pode causar consequências concretas.

Imagine um agente capaz de:

• enviar e-mails;

• modificar configurações;

• criar usuários;

• acessar sistemas;

• executar comandos;

• realizar compras;

• movimentar informações.

Se sua memória for manipulada, uma informação falsa pode influenciar uma ação real.

A cadeia passa a ser:

memória contaminada → decisão equivocada → ferramenta acionada → impacto operacional.

Essa é uma das principais razões pelas quais a segurança de agentes de IA precisa ser tratada de maneira diferente da segurança de chatbots tradicionais.

 

Ataques contra agentes de programação

Agentes utilizados no desenvolvimento de software também estão expostos.

Um agente pode memorizar:

• padrões de arquitetura;

• decisões técnicas;

• caminhos de arquivos;

• credenciais;

• comandos;

• procedimentos.

Se uma memória contaminada for recuperada durante uma tarefa de programação, o agente pode gerar código baseado em uma informação maliciosa.

Em cenários extremos, pode:

• introduzir dependências suspeitas;

• recomendar bibliotecas falsas;

• alterar configurações;

• inserir vulnerabilidades;

• sugerir comandos perigosos.

A ameaça é particularmente relevante em ambientes DevSecOps.

 

O risco para ambientes corporativos

Empresas estão começando a utilizar agentes de IA para atividades administrativas.

Um único agente pode ter acesso a:

• e-mail;

• CRM;

• documentos;

• sistemas financeiros;

• bancos de dados;

• ferramentas internas.

Se sua memória for contaminada, o ataque pode atingir múltiplos sistemas.

A segurança precisa considerar não apenas o modelo.

É necessário proteger todo o ecossistema.

 

O princípio Zero Trust aplicado à memória

O conceito de Zero Trust pode ser adaptado à arquitetura de memória.

Em vez de assumir:

“Tudo que está na memória é confiável.”

O sistema deveria considerar:

“Toda memória precisa ter uma origem e um nível de confiança verificáveis.”

Isso implica:

• validar quem escreveu;

• registrar quando foi escrito;

• identificar a origem;

• manter histórico de alterações;

• aplicar controles de acesso;

• limitar escopo;

• permitir auditoria.

A memória precisa ser tratada como um ativo protegido.

 

Proveniência deve ser obrigatória

Cada registro persistente deveria possuir metadados suficientes para responder:

• quem criou?

• quando foi criado?

• de onde veio?

• qual usuário estava envolvido?

• qual aplicação inseriu?

• houve alterações?

• quem acessou?

• quem aprovou?

Sem essas informações, a investigação de um incidente torna-se muito mais difícil.

A ausência de proveniência também aumenta o risco de trust laundering.

 

Memória não deveria ser automaticamente confiável

Uma das principais lições do memory poisoning é que armazenamento não equivale a validação.

Um sistema pode armazenar milhares de registros.

Isso não significa que todos sejam verdadeiros.

A arquitetura precisa diferenciar:

dados não confiáveis

dados verificados

dados aprovados

instruções do sistema

Essa separação é essencial.

 

A importância da segregação de memória

Uma estratégia de defesa consiste em separar diferentes tipos de memória.

Por exemplo:

• memória do usuário;

• memória do sistema;

• memória operacional;

• memória externa;

• memória de conhecimento.

Uma informação fornecida por um usuário não deveria automaticamente possuir o mesmo nível de autoridade de uma política de segurança.

Essa separação pode reduzir a possibilidade de escalada de confiança.

 

Assinaturas e integridade

Registros importantes podem utilizar mecanismos de integridade.

Dependendo da arquitetura, podem ser utilizados:

• hashes;

• assinaturas digitais;

• HMAC;

• logs imutáveis.

O objetivo é detectar alterações não autorizadas.

Se uma memória crítica for modificada, o sistema deve conseguir identificar a alteração.

Essa abordagem é particularmente útil em ambientes que armazenam instruções operacionais.

 

Memória com expiração

Nem toda informação precisa permanecer armazenada indefinidamente.

Algumas memórias poderiam possuir prazo de validade.

Isso reduz o tempo de exposição.

Uma informação armazenada por poucos dias representa uma superfície de ataque menor do que uma informação que permanece durante anos.

A retenção deve ser baseada na necessidade.

Esse princípio também reduz riscos de privacidade.

 

Revalidação periódica

Memórias importantes podem ser reavaliadas.

O sistema pode verificar:

• se a informação continua correta;

• se a fonte permanece confiável;

• se houve alterações;

• se existem conflitos com outras fontes.

Uma memória que nunca é reavaliada pode se tornar progressivamente menos confiável.

 

Detecção de comportamento anômalo

A segurança também pode observar o comportamento do agente.

Se o agente normalmente recomenda uma fonte e, de repente, passa a promover uma empresa desconhecida, isso pode indicar manipulação.

Se começa a sugerir procedimentos incompatíveis com políticas internas, o evento deve ser investigado.

A análise comportamental pode identificar:

• mudança repentina de recomendações;

• alterações de preferência;

• novos padrões de acesso;

• comandos incomuns;

• decisões fora do padrão.

 

Auditoria contínua da memória

A memória deve ser auditada como qualquer outro componente crítico.

É possível criar processos de revisão para identificar:

• registros duplicados;

• informações contraditórias;

• instruções suspeitas;

• fontes desconhecidas;

• alterações inesperadas.

A auditoria pode utilizar ferramentas automatizadas e revisão humana.

 

A importância do Human-in-the-Loop

Agentes autônomos não devem necessariamente possuir autonomia irrestrita.

Para ações críticas, recomenda-se aprovação humana.

Isso é especialmente importante quando a ação envolve:

• dinheiro;

• dados sensíveis;

• acesso privilegiado;

• alterações de infraestrutura;

• informações reguladas.

Mesmo que uma memória esteja contaminada, o processo de aprovação humana pode interromper a cadeia de ataque.

 

Como as organizações devem se preparar

Empresas que utilizam agentes de IA devem adotar uma estratégia de segurança específica.

Entre as principais recomendações estão:

1. Mapear as memórias utilizadas pelos agentes.

2. Identificar quem pode escrever informações persistentes.

3. Registrar a origem de cada memória.

4. Separar memória confiável de conteúdo não confiável.

5. Implementar controles de acesso.

6. Utilizar mecanismos de integridade.

7. Criar políticas de retenção.

8. Monitorar alterações.

9. Realizar auditorias periódicas.

10. Exigir aprovação humana para ações de alto impacto.

Essas medidas não eliminam completamente o risco, mas reduzem significativamente a superfície de ataque.

 

O papel dos desenvolvedores

A segurança precisa começar na arquitetura.

Desenvolvedores devem evitar modelos nos quais qualquer entrada possa ser automaticamente transformada em memória confiável.

O pipeline precisa considerar:

entrada → classificação → validação → armazenamento → recuperação → uso.

Cada etapa deve possuir controles.

O armazenamento não pode ser tratado como uma operação trivial.

 

O desafio da inteligência artificial autônoma

Quanto mais autônomo o agente, maior é o impacto potencial de uma memória contaminada.

Um sistema que apenas responde pode produzir uma informação incorreta.

Um sistema que age pode executar uma ação incorreta.

Essa diferença deve orientar a arquitetura de segurança.

Autonomia precisa ser proporcional à confiança.

 

A nova corrida entre ataque e defesa

A evolução dos ataques contra memória mostra que a segurança de IA está entrando em uma nova fase.

No início, o foco estava em:

• jailbreaks;

• prompt injection;

• vazamento de dados.

Agora, pesquisadores estão analisando:

• memória persistente;

• envenenamento de contexto;

• ataques entre sessões;

• manipulação de bancos vetoriais;

• ataques de longa duração.

Isso significa que o campo de segurança de IA ainda está amadurecendo.

 

O futuro da segurança de agentes de IA

Os próximos anos provavelmente serão marcados pela criação de mecanismos especializados para proteger memória.

Podemos esperar avanços em:

• memória com proveniência criptográfica;

• controle de fluxo de informação;

• detecção semântica;

• isolamento de contexto;

• validação automática;

• memória com níveis de confiança;

• monitoramento temporal.

Pesquisas recentes já exploram arquiteturas de defesa que combinam monitoramento temporal, análise de evolução semântica, reconstrução de ataques e controles de escrita com características de Zero Trust.

A tendência é clara.

A memória deixará de ser considerada apenas uma funcionalidade.

Ela será tratada como parte da superfície de segurança.

 

Conclusão

O surgimento de ataques de envenenamento de memória representa uma mudança importante na forma como a segurança cibernética precisa enxergar os agentes de inteligência artificial.

Durante muitos anos, a principal preocupação estava relacionada à capacidade de um invasor manipular diretamente uma aplicação ou explorar uma vulnerabilidade técnica. Com a evolução dos agentes de IA, surge uma nova possibilidade: manipular o contexto persistente utilizado pelo sistema para tomar decisões futuras.

O conceito abordado no caso GhostWriter ilustra justamente essa mudança. Em vez de atacar diretamente o modelo, o adversário procura influenciar a memória que o agente recuperará posteriormente. A informação maliciosa pode permanecer silenciosa durante determinado período e somente produzir efeitos quando uma condição específica ocorrer.

Esse mecanismo apresenta características particularmente preocupantes.

O ataque pode atravessar sessões.

Pode atingir diferentes usuários.

Pode permanecer ativo por longos períodos.

Pode ser difícil de atribuir.

E, em agentes com acesso a ferramentas, pode transformar uma informação falsa em uma ação real.

A principal conclusão, portanto, é que a memória de um agente de IA precisa ser tratada como uma superfície crítica de segurança, e não como um simples recurso de personalização.

Organizações que adotarem agentes autônomos devem implementar controles de proveniência, segregação de memória, autenticação, integridade, auditoria, expiração e monitoramento contínuo.

Mais importante ainda, é necessário abandonar a premissa de que tudo o que o agente “lembra” é verdadeiro.

A memória precisa ter origem.

Precisa ter contexto.

Precisa ter nível de confiança.

Precisa poder ser auditada.

E, principalmente, precisa ser protegida contra alterações não autorizadas.

A inteligência artificial está avançando rapidamente em direção a sistemas capazes de executar tarefas com autonomia crescente. Nesse novo cenário, o objetivo dos atacantes não será necessariamente controlar diretamente o algoritmo.

Em alguns casos, poderá ser mais eficiente controlar aquilo que o algoritmo acredita ser verdade.

Esse é o verdadeiro significado do envenenamento de memória.

O ataque não precisa apagar a inteligência do agente.

Pode simplesmente ensinar ao agente uma mentira e esperar o momento certo para que ele acredite nela.

 

Referências bibliográficas

• iMasters. Hackers agora plantam memórias falsas dentro de agentes de IA. Publicação de 21 de julho de 2026 sobre a ameaça GhostWriter e o envenenamento da memória de longo prazo em agentes de inteligência artificial. Acessar a matéria original do iMasters
• Dash et al. From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents. Estudo de 2026 que analisa canais de escrita de memória, classes de ataques e vulnerabilidades estruturais em agentes baseados em LLMs. Acessar o estudo no arXiv