Uma pesquisa da Unit 42, publicada em setembro de 2026, mostra que a configuração padrão do AWS AgentCore Harness permite que um atacante use injeção de prompt indireta para levar um agente de IA a executar comandos com privilégio de root e exfiltrar credenciais armazenadas no AgentCore Identity. Quem opera agentes em produção na AWS — assistentes de suporte, automações conectadas a servidores MCP, bots com acesso a sistemas internos — precisa revisar agora o parâmetro allowedTools, os privilégios das contas de serviço do cofre de identidades e o tráfego de saída dos contêineres do Harness. A cadeia não exige má configuração: ela existe no estado de fábrica do serviço.
O que a pesquisa mostrou
A Unit 42 construiu um cenário de laboratório com um agente de atendimento ao cliente rodando no AgentCore Harness, conectado a um servidor MCP que exigia um token Bearer armazenado no AgentCore Identity — o cofre de credenciais recomendado pela própria AWS. Em vez de tentar convencer o modelo diretamente, os pesquisadores plantaram uma instrução escondida em um ticket de suporte: um comentário HTML invisível que pedia para baixar e executar um script. O agente leu o ticket, acionou a ferramenta shell embutida e o código dos pesquisadores passou a rodar dentro do Harness.
As configurações padrão entregam as ferramentas shell e file_operations em todas as sessões, sem que o operador as tenha declarado. A documentação da AWS é explícita: as duas ferramentas ficam disponíveis a menos que o operador restrinja com allowedTools, e a shell executa comandos bash. A Unit 42 verificou que essa shell roda como root e compartilha o mesmo espaço de memória do processo principal do Harness — o PID 1, no qual as credenciais do cofre são resolvidas para texto claro no momento do uso.
Por que o cofre não segurou
O AgentCore Identity faz o que promete no papel: criptografia em repouso, criptografia em trânsito, chaves do KMS e acesso controlado por IAM. O problema aparece no instante em que a credencial precisa sair do cofre para ser usada. Para autenticar em um servidor MCP, o Harness resolve a referência ARN da credencial em um token JWT real, dentro do próprio processo. Nesse instante, o segredo existe em texto claro na memória — e a shell embutida, rodando como root no mesmo espaço de endereçamento, consegue lê-lo.
Os pesquisadores escreveram um script que varre a heap do processo em busca de dois padrões: o JWT em si e a URL do servidor MCP contra o qual ele poderia ser reutilizado. O par — um token de 1.034 bytes e o endereço do alvo — foi enviado em uma única requisição HTTP para um webhook simulado. Na sequência, o token foi usado de fora do ambiente, sem qualquer credencial da AWS, para listar as ferramentas do servidor MCP e chamar uma função de consulta de clientes que devolvia dados pessoais de teste.
Um detalhe muda a leitura do risco: a credencial roubada não era o JWT do usuário final, e sim a conta de serviço do operador — no teste, mcp-service. É a identidade estável que o Harness usa para alcançar todos os serviços downstream conectados. Quem pergunta ao agente tem uma autoridade; quem o agente representa tem outra, muito maior. Um único comando injetado coloca tudo o que o operador conectou ao alcance do atacante, o que tornou possível exfiltrar credenciais em texto claro do AgentCore Identity sem quebrar criptografia alguma.
A resposta da AWS
A Unit 42 divulgou o achado para a AWS. A empresa revisou e encerrou o relatório como informativo, invocando o modelo de responsabilidade compartilhada do AgentCore: o escopo do allowedTools e a filtragem de tráfego de saída foram apontados como controles do lado do cliente. Não há CVE, não há patch e não há advisory — a decisão sobre o perímetro do agente ficou com quem declara o Harness.
A documentação oficial reforça essa divisão de trabalho. O parâmetro allowedTools controla a seleção de ferramentas pelo modelo durante o InvokeHarness; se omitido, todas as ferramentas são permitidas. E existe um caminho paralelo que o parâmetro não alcança: a API InvokeAgentRuntimeCommand, que executa comandos diretamente sem passar pelo modelo. A recomendação da própria AWS é não conceder a ação bedrock-agentcore:InvokeAgentRuntimeCommand em políticas IAM onde a execução direta de comandos não seja necessária.
Controles que freiam o ataque
A defesa cabe em três movimentos, e dois deles são apenas configuração. A tabela resume o que priorizar:
| Prioridade | Controle | Como aplicar | Efeito |
|---|---|---|---|
| P1 | Restringir allowedTools |
Declarar em cada invocação apenas as ferramentas que o agente precisa; nunca deixar o parâmetro vazio | Fecha o caminho padrão da shell |
| P1 | Mínimo privilégio no cofre | Limitar a conta de serviço do Identity ao estritamente necessário para a integração downstream | Contém o dano se o token vazar |
| P1 | Bloquear execução direta | Não conceder bedrock-agentcore:InvokeAgentRuntimeCommand onde não for usada |
Fecha a rota que ignora o allowedTools |
| P2 | Filtragem de saída | Rodar sessões em modo VPC com security groups e VPC Flow Logs; alertar sobre destinos incomuns | Dificulta e revela a exfiltração |
| P2 | Rotação de credenciais | Rotacionar segredos do cofre e validar qual identidade responde por cada requisição downstream | Reduz a janela de reuso |
O caminho de rede merece atenção separada: por padrão, as sessões do Harness usam rede pública. O modo VPC permite governar para onde o runtime e suas ferramentas podem falar — e o AWS Security Hub já marca runtimes em rede pública como reprovados no controle dedicado ao AgentCore.
Para quem conecta agentes a servidores MCP, o benchmark do CIS para servidores MCP oferece um ponto de partida auditável de hardening, e o guia de NIST e CISA contra roubo de tokens em nuvem cobre o lado de identidade e detecção do mesmo problema.
Sinais de comprometimento
Três pistas indicam que a cadeia já aconteceu no seu ambiente:
- Chamadas à shell do Harness que não correspondem a tarefas declaradas do agente, em especial downloads seguidos de execução com python3 ou curl com pipe;
- Requisições de saída de contêineres do Harness para destinos nunca vistos, com payload maior que o normal de resposta de agente;
- Uso do token da conta de serviço downstream a partir de endereços fora da faixa da AWS ou em horários sem invocação registrada.
Se qualquer um desses sinais aparecer, trate a credencial do cofre como comprometida: rotacione o segredo, revise os logs de acesso do serviço downstream e investigue a sessão que executou o comando.
O perímetro é a declaração do agente
A lição estrutural vai além da AWS. Agentes com acesso programático a shells, arquivos e credenciais estáveis ampliam a superfície de ataque a cada capacidade nova que recebem. O modelo não distingue de forma confiável uma instrução legítima de uma injetada; o que limita o dano é o conjunto de ferramentas e privilégios que o operador declarou. A pergunta de arquitetura que fica é simples: cada ferramenta que o agente pode chamar precisa existir? Para a maioria dos casos de uso, uma função tipada e específica — como uma consulta de cliente com esquema fechado — faz o mesmo trabalho que uma shell generalista, com uma fração do risco.
Revisar a declaração do agente custa pouco; reorganizar uma conta de serviço vazada, não. A janela para fazer essa revisão é agora, antes que a primeira cadeia real apareça em um relatório de incidente.