Bedrock da AWS: a IA que poderia abrir a porta a ataques encadeados em toda a sua empresa

A Amazon Bedrock abriu uma porta enorme para que as empresas integrem modelos de linguagem avançados em seus processos: permite que os modelos não respondam apenas perguntas, mas consultem CRMs, activem funções serverless e recuperem informações de repositórios corporativos. Essa mesma ponte entre IA e sistemas empresariais é o que multiplica o risco, porque transforma o agente da IA em outro elemento mais da infraestrutura com permissões, alcance de rede e vetores de ataque próprios.

Uma equipe de pesquisa em segurança do XM Cyber tem desmenuçado este problema e validado várias rotas de ataque que aproveitam precisamente essa conectividade. Não se trata de quebrar a caixa de um modelo por força bruta, mas de abusar das credenciais, configurações e permissões que rodeiam Bedrock para alcançar recursos valiosos fora do próprio motor de inferência. Para quem administra ou segura um ambiente na AWS, é uma lição clara: proteger os modelos não é suficiente se não for garantido o contexto que os rodeia. Você pode consultar a página de Bedrock no AWS para entender melhor suas capacidades: https://aws.amazon.com/bedrock/, e o estudo completo do XM Cyber com diagramas e recomendações técnicas está disponível em: Building and Scaling Secure Agentic AI Applications in AWS Bedrock.

Uma via de ataque que chama a atenção é a que utiliza os registros de invocação do modelo. Bedrock guarda traços de cada interação por motivos de auditoria; esses arquivos podem conter prompts sensíveis ou resultados com PII. Se um ator malicioso pode ler o bucket onde esses logs são armazenados ou redirecioná-los para um destino sob seu controle, obtém um fluxo contínuo de informação. Em outro cenário relacionado, quem tem permissões para remover objetos em S3 ou remover streams de logs pode apagar vestígios de manipulação ou jailbreak, complicando a pesquisa forense e mantendo acesso encoberto.

A arquitetura de Knowledge Bases em Bedrock — o padrão conhecido como Retrieval Augmented Generation (RAG) — é outra superfície crítica. Aqui convivem as fontes originais de dados (S3, SharePoint, Salesforce, Confluence) com os índices e stores que fazem consultabilidade desse conteúdo. Se um atacante conseguir credenciais para ler diretamente a fonte, você pode exfiltrar dados sem passar pelo modelo; se roubar segredos que Bedrock usa para conectar com serviços SaaS, você pode se mover lateralmente para sistemas de identidade como Active Directory. A diferença entre ler dados em bruto e manipular a conexão é a diferença entre espionagem e uma porta para escalada de privilégios.

Complementando isso, o lugar onde se armazena a informação já processada – as bases vetorials ou os armazéns estruturados – tem seu próprio risco. Plataformas de vetores comerciais ou serviços gerenciados podem conter chaves e endpoints em configurações que, se leem por APIs de Bedrock (por exemplo, através de pedidos que recuperem objetos de configuração), permitem ao atacante controlar índices inteiros ou clonar dados. Com bases nativas da AWS como Aurora ou Redshift, o roubo de credenciais pode dar acesso direto a tabelas e à informação relacional completa.

Os agentes de Bedrock são elementos autônomos projetados para orquestrar tarefas. Um acesso que permita criar ou atualizar agentes pode modificar sua instrução base e as ferramentas que usam, provocando usos indesejados: desde a divulgação de instruções internas até a anexação de executores maliciosos que atuem como “portas traseiras” e realizem mudanças em bases de dados ou em contas de usuário em nome do fluxo legítimo. Nesse tipo de cenários, a ação maliciosa camufla-se dentro do comportamento esperado do agente, o que dificulta a detecção.

Existe também um vetor mais sutil: em vez de tocar o agente, o atacante compromete a infraestrutura que o agente invoca. Se um ator puder atualizar o código de uma função Lambda ou publicar camadas com dependências maliciosas, injeta comportamento prejudicial nas chamadas que o agente faz a ferramentas externas. É uma forma eficiente de contaminar uma cadeia de execução sem modificar diretamente o agente.

Os fluxos (flows) que definem passos e condições para completar tarefas também podem ser manipulados. Mudando um fluxo pode ser inserido um nó que reencadeie dados sensíveis a um armazenamento externo, alterar condições que atuam como controles de negócios para permitir pedidos não autorizados, ou mesmo substituir a chave de cifra utilizada para estados e snapshots por uma controlada pelo atacante. Deste modo, a lógica de negócio continua a funcionar aparentemente bem enquanto a confidencialidade ou integridade da informação é comprometida.

Os guardas ou "guardrails" de Bedrock são a primeira linha de defesa para evitar que o modelo crie conteúdo perigoso, aceite injeções de prompt ou exponha dados pessoais. Se alguém pode baixar limiares, remover regras ou remover esses filtros, muito do controle que as organizações se acreditam ter desaparece. A manipulação de guardrails transforma vulnerabilidades lógicas em lacunas operacionais, porque diminui a resiliência contra entradas maliciosas que anteriormente eram bloqueadas.

Finalmente, a gestão centralizada de modelos de prompt oferece um vetor de impacto em larga escala. Modificando um template compartilhado (ou sua versão ativa) pode ser inserida instruções que alterem o comportamento do modelo em todas as aplicações que o consomem, sem necessidade de redeploy. Esse tipo de mudança "em quente" permite exfiltração maciça ou geração coordenada de conteúdos nocivos e é difícil de detectar com a supervisão tradicional de aplicações.

O que devem fazer as equipes de segurança? A boa notícia é que as defesas continuam sendo as de sempre aplicadas com disciplina: governança de identidades e acessos o mais rigoroso possível (princípio de menor privilégio), controle e monitoramento de logs com integridade garantida, gestão segura de segredos e chaves, segmentação de rede e limitação do alcance de agentes e funções. É essencial manter um inventário de cargas de IA e mapear quais recursos têm acesso, porque, como mostra a análise, uma só autorização exagerada pode ser suficiente para desencadear um ataque encadeado. O AWS oferece guias de boas práticas para IAM que são um bom ponto de partida: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html.

A observabilidade é igualmente crítica: garantir que a CloudTrail e os sistemas de registo não podem ser facilmente redireccionados ou apagados, e cifrar logs sensíveis com chaves cujo acesso esteja restrito e auditado. Os guias do CloudTrail e da gestão de chaves da AWS ajudam a projetar essas proteções: CloudTrail e AWS KMS. Para o risco específico de RAG e bases vetorials, convém rever controlos em torno de ingestion pipelines, rotação de credenciais e restrições de rede que limitem a possibilidade de extrair índices completos de fora da VPC ou do ambiente administrado.

No nível de governação da IA é útil olhar para quadros de gestão de riscos e frameworks que ajudem a priorizar controles técnicos e organizacionais. O NIST publicou orientação sobre gestão de riscos para a IA que pode servir como referência para políticas e processos: NIST AI RMF. Implementar revisões de mudanças para guardrails, modelos de prompt e fluxos, e submeter modificações a processos de aprovação com rastreabilidade reduz a possibilidade de manipulações não detectadas.

Em suma, Bedrock e plataformas semelhantes nos obrigam a pensar a segurança da IA em termos amplos: proteger modelos, sim, mas sobretudo proteger contas, rotas de integração e peças de infraestrutura que permitem a um agente tocar o resto da organização. Se você quer aprofundar os testes de conceito, diagramas e recomendações operacionais, o relatório completo de XM Cyber contém esse material técnico e foi contribuído por pesquisadores da equipe, entre eles Eli Shparaga: Building and Scaling Secure Agentic AI Applications in AWS Bedrock.