A semana em que a memória dos agentes virou a nova superfície de ataque — e o hardware que roda esses agentes ficou impagável.
De 83% para zero.
A taxa de sucesso de ataques de envenenamento de memória. Em sistemas de agentes que você já tem em produção hoje.
Este é o Wire da ai|expert, edição doze. A semana em que a memória dos agentes se tornou a nova superfície de ataque — e o hardware que sustenta esses sistemas ficou impagável.
O MemAudit foi publicado no arXiv em 22 de maio e enquadra memória de agentes como problema forense — não apenas como problema de segurança. A distinção é operacional. [ref: memaudit-detecting-poisoned-ag]
Defesas existentes operam sobre o que o agente produz: filtros de prompt, bloqueadores de output. Mas o ataque acontece antes disso. Um usuário adversarial injeta registros maliciosos na memória compartilhada do agente durante interação completamente normal. Quando outro usuário chega com uma query legítima, o agente recupera o registro envenenado — e age sobre ele, na sessão de outra pessoa.
O vetor testado é o MINJA — ataque de injeção query-only, sem acesso direto ao banco de memória. Só interação normal com o agente, como qualquer usuário faria.
Os números: antes do MemAudit, taxa de sucesso de 70% em ataques QA. Em ataques RAP — reasoning-agent poisoning — 83,3%. Depois do MemAudit: zero por cento nos dois. Eliminação completa em ambos os vetores testados.
O framework combina dois sinais. Primeiro: um score de influência contrafactual — mascara cada registro de memória individualmente e mede a mudança no output do agente. Atribuição causal direta. Segundo: um grafo de consistência que flageia registros estruturalmente anômalos dentro do banco de memória como um todo.
O custo que o paper não quantificou: overhead de re-inferência contrafactual em escala. Cada auditoria precisa re-rodar sobre cada registro do banco. Em produção com memória crescendo continuamente, isso tem custo. Mas a pergunta relevante não é se é barato — é se você tem forense pós-incidente de memória hoje, ou não tem.
O LCGuard, do Rensselaer Polytechnic Institute e da IBM Research, abre um vetor diferente — e mais silencioso. [ref: lcguard-preventing-kv-cache-leakage-in-multi-agent-llm-systems]
Frameworks como CAMEL e AutoGen tradicionalmente passam linguagem natural entre agentes: cada passo decodifica, tokeniza e reconstrói o estado semântico — é lento e perde informação. Trabalhos mais recentes passam KV caches diretamente entre agentes para cortar essa latência e preservar estrutura semântica mais rica. E é aí que o problema aparece.
KV caches encodam inputs contextuais, estados intermediários de raciocínio, informação específica do agente. Um adversário com acesso aos artefatos de cache compartilhado — via agente downstream comprometido, infraestrutura de logging, ou modelo auxiliar — pode treinar um decoder para reconstruir os inputs do agente upstream diretamente da representação. Sem nenhuma divulgação textual. O ataque é invisível nos outputs.
Mecanismos de segurança existentes não enxergam esse canal — eles operam sobre outputs gerados ou ações de ferramentas. O que transita nas representações latentes está fora do escopo de qualquer defesa convencional. Esse é o ponto central do paper.
O LCGuard defende com treinamento adversarial: um modelo aprende a reconstruir inputs sensíveis a partir dos artefatos de cache transmitidos. Simultaneamente, o LCGuard aprende uma transformação no nível de representação que minimiza o que o adversário consegue recuperar, preservando semântica útil para os agentes downstream. O framework cobre as três topologias principais — sequencial, hierárquica e baseada em grafo — e é agnóstico a modelo.
Os números específicos — deltas de erro de reconstrução, acurácia de tarefa, overhead de latência — não foram divulgados. É pesquisa pura: formalização da ameaça, blueprint de mitigação, resultados direcionais. Não existe evidência de deployment em produção ainda. Mas se você está desenhando uma camada de comunicação latente via KV sharing, isolamento no nível de representação precisa ser requisito de primeira classe — não um retrofit depois do incidente.
Na mesma semana, um desenvolvedor chamado Fabio Akita documentou com precisão cirúrgica por que o sistema de memória de agentes mais popular do mercado não funcionava em produção. [ref: developer-scraps-buggy-agentmemory-after-week-in-production-ships-ai-memory-buil]
O agentmemory tem 15,7 mil estrelas no GitHub. Akita ficou sete dias em produção, abriu cinco bug reports reproduzíveis, e descartou o projeto inteiro.
Os bugs são estruturais, não de configuração. Acima de 10 mil observações, o índice BM25 colapsa para cerca de 96 bytes no restart — e custa cinco minutos de rebuild a cada vez. Todo write passa por um debounce de cinco segundos do IndexPersistence. Quando o upstream state::set dá timeout em 30 segundos, o processo Node morre levando junto tudo o que estava em RAM. Janela de perda de dados garantida em todo timeout.
O mais silencioso dos cinco: o hook para Claude Code lia data.tool_output, mas o Claude Code emite tool_response. Por seis semanas, aproximadamente 47% de todas as tool calls sumiam sem nenhum aviso. O sistema parecia funcionar. Não estava.
A resposta de Akita foi o ai-memory: SQLite FTS5 para indexing, markdown puro commitado em git para armazenamento, binário único sem dependências externas. O design vem diretamente do gist de Andrej Karpathy sobre LLM Wiki. O problema central que ele resolve é handoff entre agentes — sem memória externa compartilhada, cada troca de agente exige um ciclo manual de escrita e leitura de HANDOFF.md.
Nenhum dos sistemas de compactação de sessão — Claude Code, Codex, opencode — sobrevive cruzando fronteiras de agente. A aposta do ai-memory é explícita: complexidade em camadas é inimiga de confiabilidade antes de você chegar em escala. FTS5 em SQLite local vence um sistema distribuído cheio de bugs em produção hoje.
Saindo de memória. A Cloudflare completou seu stack de plataforma para agentes com um rebuild do Browser Run e seis camadas nomeadas. [ref: cloudflare-ships-six-layer-agent-platform-with-browser-sandbox-and-memory-routin]
O número central: 4x mais concorrência no Browser Run — 120 browsers simultâneos por pool, contra 30 antes. 50% mais rápido em quick actions. A migração foi para Containers dedicados com pools regionais de instâncias Chromium pré-aquecidas. O diagnóstico é direto: infraestrutura otimizada para sessões humanas longas e estáveis colide com o padrão de requests de agentes — curto, esporádico, em spike.
O padrão arquitetural que vale extrair: gerenciamento de estado saiu de Workers KV — consistência eventual causando race conditions durante runs concorrentes — para D1 com Queues, habilitando atribuição transacional de browser. Batch writes suportam até 500 mil containers por localização.
Se você roda agentes concorrentes contra qualquer store com consistência eventual e vê race conditions em atribuição de recurso, fila transacional na camada de dados resolve mais limpo do que locking na aplicação. Esse é o padrão direto para roubar daqui.
O stack completo tem seis camadas: compute em dois tiers — Workers V8 isolates para tarefas leves, Sandboxes GA para Linux completo com git e bash — orquestração com Dynamic Workflows em cerca de 300 linhas MIT, memória em private beta com busca em cinco canais paralelos e Reciprocal Rank Fusion, Browser Run em Containers com suporte a WebGL e WebMCP, e um protocolo de commerce co-desenvolvido com Stripe onde agentes criam contas, registram domínios e iniciam assinaturas de forma autônoma. Teto padrão de 100 dólares por mês por provider.
Esse teto precisa de atenção explícita. É um guardrail, não uma política de controle. Agentes em escala gerando eventos de billing inesperados vão ultrapassá-lo antes que você perceba. Você vai precisar de controles adicionais além do default para isso entrar em produção de verdade.
Hardware. A Morgan Stanley estimou que um rack VR200 NVL72 da linha Vera Rubin vai custar a hyperscalers cerca de 7,8 milhões de dólares. [ref: nvidia-hbm-costs-surged-485-ai-cluster-builds-now-78m]
Memória é 2 milhões desse total — 25% do custo do sistema. Alta de 435% em relação ao custo de memória no GB300 NVL72. Para comparar: GPUs Rubin custam 55 mil dólares cada, CPUs Vera 5 mil. Setenta e dois Rubin GPUs por rack são 3,96 milhões — o maior item isolado. Memória é o segundo maior vetor de custo, e subindo mais rápido que compute.
Dois drivers explicam a alta. O VR200 NVL72 carrega 54 TB de LPDDR5X, contra 17 TB no GB200 NVL72 — três vezes mais capacidade. A SemiAnalysis estima que a NVIDIA pagou 8 dólares por gigabyte de LPDDR5X no primeiro trimestre de 2026; se o preço sobe para 10 dólares por gigabyte, só o LPDDR5X chega a 540 mil dólares por rack. O segundo driver é inteiramente novo: cerca de 1 milhão de dólares em armazenamento 3D NAND por rack — categoria que era praticamente zero no GB200 NVL72.
A inversão é estrutural. Em gerações anteriores, memória era item secundário no bill of materials. No Vera Rubin, memória em todas as suas formas domina a curva de custo. Para quem está orçando um cluster hoje: você vai gastar mais em memória do que em compute. Design eficiente em memória, quantização que reduz pressão de ativação, avaliação cuidadosa de NAND em pipelines de inferência — essas viram alavancas de custo diretas sobre uma decisão de capital de 7,8 milhões de dólares.
Para fechar: o mercado secundário de ações da Anthropic entrou em frenesi especulativo com características estruturais de fraude. [ref: fraud-layered-spvs-and-1-trillion-in-demand-inside-anthropics-pre-ipo-secondary-]
Um trilhão de dólares em capital perseguindo 30 a 50 bilhões em ações disponíveis. A Anthropic, avaliada publicamente pela última vez em 380 bilhões de dólares, está captando a uma valorização reportada de 900 bilhões enquanto simultaneamente busca um round de até 50 bilhões.
Em abril, a Anthropic fez uma chamada de 48 horas para alocações de investidores. Clara Vydyanath — ex-head de investimentos da Hiive, praticante de mercado secundário desde 2018, hoje co-fundando um novo fundo com Hari Raghavan — disse que nunca tinha visto uma empresa fazer uma solicitação pública estruturada dessa forma.
"Esta é a primeira vez que eu vi uma empresa dizer: 'estamos aceitando propostas para investir em nós, porque somos um ticket tão quente que podemos escolher o capital que queremos.'"
A infraestrutura do problema: SPVs não são regulados. Múltiplos brokers comercializam os mesmos blocos de ações simultaneamente. Em estruturas com quatro ou mais camadas de SPV, se as ações da Anthropic existem de fato na base permanece não resolvido até o fechamento. Contratos sintéticos também circulam — alguns investidores compram exposição a preço, não equity.
As taxas documentadas em uma estrutura: taxa fixa de 20% uma vez, mais 2% anuais de administração, totalizando mais de 30% de carry em camadas. A cinco anos de hold, só o item de 2% ao ano já chega a 10% antes do carry tocar. Para um family office alocando entre 50 e 100 milhões de dólares, essa carga pode consumir um terço do retorno nominal antes do ativo subjacente performar.
A Anthropic publicou uma lista de brokers não autorizados e um aviso explícito proibindo SPVs — a lista foi atualizada em ambas as direções: nomes adicionados e removidos, incluindo Forge e Lionheart Ventures. O DOJ começou a processar casos em mercados privados pré-IPO, mas enforcement segue bem atrás da velocidade dos deals num ambiente não regulado. Qualquer deal com mais de duas camadas de SPV precisa de auditoria direta da chain-of-custody até a cap table. Sem isso, é exposição sem lastro.
A memória dos agentes estava exposta muito antes de alguém publicar um paper sobre isso — e vai continuar exposta em todo sistema que ainda não tem forense pós-incidente. Wire na próxima edição. Até lá.