AWS mostra como combinar controles do AgentCore Memory contra memory poisoning, com validação de escrita em camadas

O Amazon Bedrock AgentCore Memory mantém contexto entre sessões com memória de curto e longo prazo. O conteúdo gravado é recuperado e injetado automaticamente em conversas futuras, então o caminho de escrita decide o que o agente vai "lembrar". É aí que a AWS propõe agir contra o memory poisoning, uma forma de prompt injection indireta em que o atacante grava instruções maliciosas na memória de longo prazo. Ao contrário do prompt injection efêmero, a memória envenenada persiste e, em namespaces compartilhados, pode atingir vários agentes e usuários.

Os controles nativos já existem: condition keys do IAM (bedrock-agentcore:namespaceVariable/*) no CreateEvent, validação de namespace-variable (allowedValues, regexPattern), consolidation prompts personalizados e a ApplyGuardrail API. O que falta, segundo o texto, é uma camada única e ajustável que combine sinais. A proposta é um Lambda interceptor de pré-escrita no AgentCore Gateway com quatro sinais: desvio semântico (peso de 40%, similaridade de cosseno com embeddings do Amazon Titan Text Embeddings V2), padrão de instrução por regex (25%), fronteira de namespace (25%) e anomalia na taxa de escrita (10%, contador no DynamoDB). O resultado vira ALLOW (abaixo de 35), QUARANTINE (35 a 60, redireciona para um namespace isolado) ou DENY (acima de 60, bloqueia e dispara alerta via Amazon SNS).

Há complementos: oito políticas Cedar no AgentCore Policy para isolamento de namespaces (por exemplo, agentes não escrevem em system/ e só o Lambda de validação escreve em quarentena) e a escolha de failurePolicy entre ALLOW e BLOCK caso a validação fique indisponível. Nos testes, 11 cenários (3 benignos e 8 ataques) retornaram a decisão esperada, mas usando uma aproximação local por sobreposição de palavras-chave, não o Titan. Três ataques sem correspondência de regex (injeção em espanhol, inglês ofuscado e manipulação sutil de preferência) foram pegos pelo desvio semântico. O autor avisa que os resultados variam no ambiente real. A validação ocorre na camada do Gateway, então escritas por chamadas diretas de SDK escapam dela e exigem validação no código do agente ou controles de IAM e consolidation prompts.

Para quem opera agentes com memória compartilhada, o ponto central é tratar a escrita na memória como superfície de ataque, não só o prompt. Uma única escrita envenenada em namespace compartilhado vale para todo mundo que lê dele. Vale também olhar a lacuna das chamadas diretas de SDK e decidir a failurePolicy conforme o risco do ambiente. Os números dos testes vêm de uma demo simplificada, então calibrar limiares com dados próprios é parte do trabalho.