AgentCorruption: riscos de metadados e IAM no AgentCore

A pesquisa de outubro de 2026 da Zenity relata que ferramentas influenciadas pelo modelo podiam alcançar os metadados do runtime AgentCore e que permissões históricas do papel padrão ampliavam o acesso. A AWS considera esperado o acesso às credenciais do próprio papel do runtime e recomenda privilégios mínimos. A pesquisa da Zenity não cita identificador CVE nem comprova comprometimento de clientes.^{[1], [4]}

💡 Explicação em Linguagem Simples (ELI5)

Imagine um agente trabalhando numa oficina e recebendo um crachá para as tarefas autorizadas. A Zenity relata que uma ferramenta guiada pelo modelo podia pedir esse crachá ao balcão interno de credenciais; as permissões antigas do crachá abriam mais salas do que o agente precisava. A AWS diz que é esperado que o agente receba as credenciais do próprio papel dentro da oficina. A defesa prática é limitar as portas abertas por cada crachá e controlar quais ferramentas podem fazer requisições internas.^{[1], [4]}

Conceitos Centrais e Termos

AgentCorruption: Nome dado pela Zenity Labs à sua cadeia de pesquisa controlada contra o Amazon Bedrock AgentCore. A Zenity não cita um identificador CVE, e sua pesquisa não comprova uma violação de clientes.^{[1], [7]}
MMDS e credenciais do papel de execução: A AWS documenta que o código dentro de uma microVM do AgentCore pode acessar pelo MMDS credenciais temporárias do papel de execução daquele runtime. O serviço considera esse comportamento esperado; as permissões do papel determinam o que as credenciais autorizam.^{[4], [5]}
Raio de impacto das permissões: O papel de execução define quais ações e recursos da AWS o código do agente pode acessar. A Zenity relata permissões históricas amplas na mesma conta e região. A AWS recomenda privilégios mínimos; a autorização depende das políticas de identidade e de recurso aplicáveis à operação. A AWS diz especificamente que o acesso entre contas exige concessões no papel e no recurso de destino.^{[3], [1], [6]}
CWE-918 — classificação editorial: Esta página usa CWE-918 como classificação editorial para uma requisição iniciada por ferramenta do agente até um serviço interno de metadados. A AWS não atribuiu essa CWE; o acesso aos metadados é um comportamento documentado.^{[8], [4], [1]}

Mapeamentos de frameworks

Mapeamento conceitual da FlawOpen para o MITRE CWE; nenhum fornecedor ou registro CVE atribuiu este identificador de fraqueza a esta demonstração de pesquisa. CWE-918

Fluxo de Ataque Passo a Paso

Passo 1

Um agente público tem uma ferramenta de saída

A Zenity testou um agente AgentCore acessível publicamente com uma ferramenta capaz de enviar requisições externas. O cenário exige um agente alcançável e um caminho de ferramenta influenciável pelo modelo; não representa toda implantação.^{[2], [1]}

Passo 2

A influência do modelo alcança os metadados

A Zenity relata que seu agente de teste podia ser induzido a consultar o serviço local de metadados. A AWS documenta que o código na microVM pode acessar credenciais do MMDS; a questão de segurança em disputa é o caminho de confiança entre modelo e ferramenta e a autoridade dessas credenciais, não a existência das credenciais próprias do runtime.^{[2], [1], [4]}

Passo 3

A resposta representa o papel do agente

A AWS documenta que o MMDS fornece credenciais temporárias do papel de execução configurado. Essas credenciais não autorizam automaticamente acesso a todos os recursos; políticas IAM e políticas de recurso aplicáveis definem as operações permitidas. A AWS especifica que o acesso entre contas requer concessões explícitas tanto no papel quanto no recurso de destino.^{[4], [6], [1]}

Passo 4

Permissões históricas ampliaram o impacto

A Zenity relata que o papel padrão da época permitia operações em outros recursos AgentCore da mesma conta e região, incluindo invocação, acesso a sessões/eventos, operações de memória e acesso a segredos. Segundo a Zenity, a AWS restringiu substancialmente o papel padrão até 29 de setembro de 2026. Isso não demonstra alterações automáticas em papéis gerenciados pelo cliente.^{[3], [1], [6]}

Passo 5

Os controles atuais protegem limites diferentes

A Zenity diz que novos agentes passaram a usar MMDSv2 em 14 de fevereiro de 2026. A documentação atual da AWS exige MMDSv2 habilitado para invocar o runtime desde 30 de junho de 2026. A AWS ainda documenta o acesso às credenciais do papel por código dentro da microVM; portanto, MMDSv2 não substitui IAM de privilégio mínimo nem o controle das ferramentas influenciadas pelo modelo. Essa separação é uma inferência defensiva baseada nas fontes.^{[5], [4], [1]}

Evidências e escopo atual

Limite	Evidência	Ação defensiva
Acesso a metadados	A Zenity relata acesso em seu teste; a AWS documenta credenciais MMDS para código dentro da microVM.	Trate o código do agente e as ferramentas influenciadas pelo modelo como detentores do papel de execução.
Permissões do papel	A Zenity relata padrões históricos amplos. A AWS diz que acesso entre contas exige concessões explícitas no papel e no recurso de destino; outras operações seguem suas políticas IAM e de recurso aplicáveis.	Inspecione papéis implantados e políticas de recursos; verifique as políticas aplicáveis a cada operação e não deduza o escopo de autorização a partir de um prompt ou padrão de serviço.
Mudança no papel padrão	A Zenity diz ter observado a AWS restringir o papel padrão em 29 de setembro de 2026. Não afirma que papéis gerenciados pelos clientes mudaram automaticamente; a pesquisa não cita CVE nem comprova violação de clientes.	Verifique os papéis efetivos em cada conta e região; não presuma que os papéis dos clientes foram alterados.
MMDSv2	A Zenity situa a adoção de MMDSv2 por novos agentes em 14 de fevereiro de 2026; a documentação atual da AWS exige habilitação para invocação do runtime desde 30 de junho de 2026. A AWS ainda documenta acesso a credenciais dentro da VM.	Habilite MMDSv2 e, separadamente, restrinja ações, recursos e chamadores do papel.

Análise de Causa Raiz

Avalie dois limites separadamente: ferramentas influenciadas pelo modelo podem fazer requisições de dentro do runtime, e o papel de execução define a autoridade dessas requisições. A AWS considera esperado o acesso às credenciais próprias do runtime; o impacto entre agentes relatado pela Zenity dependia do escopo histórico do papel. Habilitar MMDSv2 não restringe o IAM, enquanto restringir o papel não impede requisições internas dirigidas pelo modelo. Revise a saída de rede das ferramentas e a autorização IAM de forma independente; restrições de saída, por si só, não provam que o MMDS esteja inacessível ao código dentro da microVM.^{[1], [3], [4], [5]}

Código-Fonte: Vulnerável vs. Seguro

Apenas exemplos ilustrativos de declarações de política IAM; não são a política histórica da AWS nem a mudança posterior no papel padrão. A AWS recomenda restringir permissões de runtime a ARNs de recursos específicos e evitar curingas. A primeira declaração ilustra o padrão amplo de recurso; a segunda limita a invocação a um runtime aprovado, se essa permissão for necessária. Remova a permissão se ela não for necessária. Valide o suporte à ação/recurso e as políticas de recurso complementares para a implantação real; isto não é uma política completa pronta para implantação.^{[3], [6], [5]}

IMPLEMENTAÇÃO VULNERÁVEL

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

PATCH SEGURO E ROBUSTO

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Lista de Verificação de Segurança para Engenharia

✓Inventarie cada papel de execução dos runtimes em todas as contas e regiões; compare as permissões efetivas com as políticas atuais da AWS e as gerenciadas pelo cliente.^{[6], [5]}
✓Remova invocação entre runtimes, acesso a conversas, recuperação de segredos, gravação de memórias e acesso a imagens, salvo quando cada ação tiver necessidade documentada.^{[3], [6]}
✓Se um runtime precisar invocar outro, restrinja as políticas de identidade e de recurso ao runtime e endpoint aprovados; teste se runtimes não relacionados são negados.^[6]
✓Habilite MMDSv2 conforme exigido pela AWS, mas trate o acesso às credenciais do papel por código dentro da microVM como um limite de autorização separado.^{[5], [4], [1]}
✓Reduza os destinos que ferramentas influenciadas pelo modelo podem contatar ao que a carga de trabalho exige; trate isso como redução do risco de saída, não como prova de que o código dentro da VM não pode acessar o MMDS.^[5]
✓Conceda aos agentes públicos papéis com privilégios iguais ou inferiores aos dos principais que podem invocá-los; valide as permissões efetivas com o IAM Access Analyzer e casos negativos de autorização.^{[5], [6]}

Fontes

← AI Security Directory →