A memória de um agente também precisa de poder esquecer
Como separar preferências, informação externa e autorizações para impedir que uma memória antiga decida por uma pessoa.
- Edição
- 2026-09-06
- Âmbito
- Equipas que usam agentes com estado persistente; análise técnica, não notícia de um incidente.
- Natureza
- Análise editorial; factos e recomendações identificados separadamente. Publicada e verificada em 6 de setembro de 2026.
- Revisão
- Rever quando mudar o mecanismo de memória, o modelo ou as permissões de escrita.
Em resumo
O risco não termina quando a conversa acaba: um agente pode voltar a consultar informação guardada noutra sessão. A questão prática é saber quem a escreveu, em que contexto continua válida e como a retirar. Propomos um contrato de memória com âmbito, proveniência e revogação, sem apresentar uma ferramenta experimental como garantia de segurança.
- Uma preferência guardada não é uma autorização permanente.
- Separar memória pessoal, de projeto e partilhada.
- Testar a revogação numa sessão nova, não apenas na conversa original.
O que está documentado — e o que não estamos a afirmar
O OWASP inclui a contaminação da memória e do contexto na categoria ASI06 do seu Top 10 para aplicações agênticas, anunciado em dezembro de 2025. Não é uma descoberta de hoje. O problema distingue-se de uma resposta errada isolada: informação conservada pode influenciar interações posteriores.
A página do projeto Agent Memory Guard descreve controlos de integridade, políticas de leitura e escrita e recuperação de estados anteriores. São capacidades declaradas pelo projeto, não uma avaliação independente de eficácia. A referência LLM04:2025 ajuda a distinguir contaminação de dados de treino ou embeddings; não tratamos todas estas superfícies como se fossem a mesma coisa.
Perspetiva Velqory: guardar menos, com um contrato explícito
Começaria por três classes. Preferências pessoais podem ajustar linguagem e formato. Conhecimento de projeto pode ajudar a localizar uma decisão. Permissões para enviar mensagens, apagar dados ou executar operações financeiras devem vir de um sistema de autorização separado. Uma nota a dizer que alguém aprovou uma ação não deve substituir a verificação atual dessa aprovação.
Para cada registo, proponho conservar origem, autor da escrita, projeto ou utilizador a que pertence, data de validade e motivo da retenção. Um resumo gerado deve apontar para a fonte que resume. Se a origem desaparecer ou for corrigida, os derivados precisam de ser reavaliados. Esta é uma proposta de controlo da Velqory, não uma afirmação de que os agentes disponíveis já fazem esta gestão.
- Responsável do produto: define que informação pode sobreviver à sessão e por quanto tempo.
- Equipa técnica: limita escritas, mantém versões e impede leitura entre projetos sem autorização.
- Segurança e privacidade: definem como investigar alterações suspeitas sem copiar dados pessoais para logs indiscriminados.
O ensaio que pediria antes de ativar memória partilhada
Num ambiente isolado e com dados sintéticos, guarde uma preferência inofensiva, confirme que uma nova sessão a recupera e depois revogue-a. Abra outra sessão e verifique tanto a resposta como os registos consultados. Repita com dois projetos: a memória do primeiro não deve aparecer no segundo. Inclua um documento de origem entretanto corrigido e confirme o tratamento do resumo antigo.
Não executámos este ensaio num produto específico para este artigo. O critério proposto é verificável: revogação efetiva, isolamento entre contextos e rasto suficiente para explicar uma leitura. Se falhar, mantenha a memória partilhada desativada e reduza o âmbito à sessão enquanto a causa é corrigida. Um hash comprova igualdade de bytes; não comprova a verdade do conteúdo.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.