Pesquisadores de segurança digital identificaram oito vetores de ataque com potencial de alto impacto no AWS Bedrock, a plataforma de IA generativa da Amazon voltada à criação de aplicações com grandes modelos de linguagem. As conclusões reforçam uma mensagem incômoda para empresas que estão acelerando projetos de IA: o ponto frágil não é apenas o modelo em si, mas todo o ecossistema de permissões, integrações e fluxos de dados que cercam o ambiente.
Em vez de mirar diretamente nos modelos, muitos cenários de ataque descritos no estudo exploram como o Bedrock se conecta a outros serviços corporativos e de nuvem. Configurações frouxas de identidade e acesso, integrações mal segmentadas e falta de visibilidade sobre o que os agentes de IA conseguem fazer em nome do usuário acabam abrindo brechas para exfiltração de informações sensíveis, execução de ações não autorizadas e movimentos laterais dentro da infraestrutura da organização.
Um dos pontos mais delicados identificados pelos pesquisadores está nos logs de invocação dos modelos. O Bedrock registra prompts, parâmetros e respostas para fins de auditoria e rastreabilidade. Se um atacante obtém credenciais com permissões excessivas, passa a ter a capacidade de consultar esses registros diretamente em buckets S3 ou redirecionar o fluxo de logs para um ambiente que ele controla. Nesse cenário, é possível capturar conversas inteiras entre usuários e a IA, coletando segredos de negócio, informações pessoais, dados operacionais e até credenciais inseridas inadvertidamente em prompts.
Além do risco de espionagem silenciosa, o mesmo mecanismo de logging pode ser manipulado para ocultar rastros. Com privilégios suficientes, o invasor pode apagar ou alterar registros de invocação, dificultando a detecção de atividade maliciosa e comprometendo investigações futuras. Isso transforma o subsistema de auditoria em um alvo estratégico: quem domina os logs tem poder tanto para observar quanto para apagar evidências.
Outro vetor particularmente crítico mencionado pelos pesquisadores envolve as Knowledge Bases integradas ao AWS Bedrock, especialmente em arquiteturas baseadas em RAG (Retrieval-Augmented Generation). Essas bases permitem que o modelo de IA consulte dados corporativos externos para enriquecer as respostas. Na prática, isso significa que o Bedrock passa a ter um canal direto com repositórios como S3, Salesforce, SharePoint, Confluence e outros sistemas de gestão de conteúdo e CRM.
Se um invasor consegue explorar falhas de configuração nessas integrações ou comprometer as credenciais usadas para conectá-las, ganha uma porta de entrada para recursos fora da camada de IA. Em vez de atacar diretamente bancos de dados ou aplicações críticas, ele pode se aproveitar do papel privilegiado que a plataforma de IA ocupa, usando-a como ponte para realizar movimentação lateral, explorar dados arquivados, baixar documentos confidenciais ou acionar APIs internas com o mesmo nível de acesso concedido ao agente de IA.
A pesquisa também chama atenção para os riscos ligados ao armazenamento de dados já indexados em bases vetoriais e serviços de banco de dados. Soluções especializadas como Pinecone e Redis Enterprise Cloud, bem como serviços gerenciados nativos, como Aurora e Redshift, tornam-se parte integrante da arquitetura de IA generativa quando são usados para armazenar embeddings e coleções de conhecimento. Nesses casos, o elo fraco muitas vezes não é a tecnologia em si, mas a forma como credenciais, redes e papéis de acesso são configurados.
Com o conjunto adequado de permissões – por exemplo, chaves de API reutilizadas em vários ambientes, funções de IAM muito amplas ou falta de segmentação entre desenvolvimento e produção -, um atacante pode assumir privilégios administrativos sobre a base de conhecimento. A partir daí, não apenas é possível extrair grandes volumes de dados, como também injetar informações falsas, corromper índices, alterar pesos de relevância ou apagar seletivamente conteúdos, influenciando diretamente o comportamento dos modelos que dependem desse repositório.
Os pesquisadores ressaltam que esses vetores de ataque são potencializados por um padrão recorrente nas empresas: a pressa em colocar soluções de IA no ar, muitas vezes herdando permissões e integrações de outros projetos, sem uma revisão profunda de ameaças específicas para ambientes de IA generativa. Workloads de IA acabam recebendo privilégios “temporários” que nunca são reduzidos, funções de serviço ganham acesso a mais dados do que precisam e pipelines inteiros são criados sem um mapeamento claro de quem pode ver, alterar ou copiar cada etapa do fluxo.
Outro ponto sensível é o comportamento dos agentes de IA que interagem com diversos serviços em nome do usuário. Em muitos desenhos de arquitetura, esses agentes têm autorização para ler, criar ou modificar registros em múltiplos sistemas corporativos. Se o atacante conseguir manipular prompts, instruções de sistema ou parâmetros de execução, pode levar o agente a realizar ações indevidas, como exportar grandes conjuntos de dados, alterar configurações de segurança ou disparar rotinas automatizadas que abrem novas superfícies de ataque.
Em ambientes híbridos, onde o Bedrock se conecta tanto à nuvem quanto a sistemas on-premises, o risco de “efeito dominó” aumenta. Uma brecha aparentemente limitada a um bucket S3 ou a uma base vetorial na nuvem pode ser o ponto de partida para alcançar diretórios internos, aplicações legadas ou servidores com dados altamente sensíveis. Sem um mapeamento claro dos caminhos de ataque possíveis entre o ambiente de IA e os sistemas internos, a organização tende a subestimar o impacto de uma única credencial comprometida.
Para reduzir a exposição, o estudo recomenda um conjunto de medidas alinhadas às boas práticas de segurança em nuvem, mas adaptadas à realidade da IA generativa. A primeira linha de defesa é a revisão rigorosa das permissões associadas a todos os componentes envolvidos nos workloads de IA: funções de IAM, perfis de serviço, chaves de API, integrações com SaaS e acessos a bancos de dados. O princípio do menor privilégio deve ser aplicado não só a usuários humanos, mas a agentes, pipelines e serviços auxiliares.
Outra recomendação é mapear explicitamente os caminhos de ataque potenciais entre o ambiente de nuvem e a infraestrutura interna. Isso implica construir diagramas de fluxo que mostrem, por exemplo, como um pedido feito a um modelo no Bedrock pode levar a consultas em um banco de dados corporativo, passando por uma base vetorial e por uma aplicação intermediária. Ao enxergar esses encadeamentos, fica mais simples identificar pontos onde segmentação de rede, autenticação forte ou logging mais detalhado podem interromper ou dificultar movimentos laterais.
Os controles sobre logs, prompts, agentes e bases de conhecimento também precisam ser elevados a um patamar equivalente ao de sistemas críticos tradicionais. Isso inclui classificar dados contidos em logs de invocação, criptografar informações sensíveis em repouso e em trânsito, adotar rotação de chaves, aplicar mascaramento ou minimização de dados quando possível e estabelecer políticas claras sobre o que pode ou não ser registrado em texto puro. Em paralelo, é essencial monitorar acessos a esses logs em busca de padrões anômalos, como consultas em massa, acessos fora do horário ou tentativas de alteração de registros históricos.
No caso das Knowledge Bases e integrações RAG, a recomendação é tratá-las como fronteiras de alta criticidade. Cada fonte de dados conectada ao Bedrock deve ter suas próprias políticas de acesso, auditoria dedicada e, sempre que factível, escopos restritos apenas aos conjuntos de documentos estritamente necessários para cada caso de uso. Conectar um repositório inteiro a um agente de IA “genérico” tende a criar um alvo muito atraente para atacantes, além de ampliar desnecessariamente o impacto de um eventual vazamento.
Bases vetoriais e bancos de dados usados como repositório de embeddings merecem uma governança de credenciais mais rígida. Isso significa evitar o compartilhamento de usuários de serviço entre ambientes, segmentar funções administrativas e de leitura, usar autenticação baseada em identidade da nuvem em vez de senhas estáticas quando possível e revisar periodicamente quais aplicações realmente precisam de acesso direto a essas bases. Quanto menos superfícies expostas e menos credenciais privilegiadas em circulação, menor a probabilidade de comprometimento catastrófico.
Empresas que já operam aplicações em AWS Bedrock devem considerar avaliações de segurança específicas para seus fluxos de IA generativa, indo além de pentests tradicionais. Testes de abuso de prompts, simulações de comprometimento de credenciais de agentes e exercícios de “ameaça interna” focados em acesso a logs e bases de conhecimento podem revelar fraquezas que não aparecem em avaliações genéricas de nuvem. A ideia é tratar a pilha de IA como um novo domínio de risco, que conversa com o restante do ambiente, mas tem características próprias.
Por fim, os pesquisadores defendem que a segurança em projetos de IA generativa precisa ser pensada desde a concepção, e não enxertada depois que a solução já está em produção. Modelar ameaças específicas para interações entre modelos, agentes, dados corporativos e integrações externas ajuda a definir limites claros de responsabilidade, requisitos mínimos de proteção e critérios de monitoramento contínuo. Em um cenário em que agentes de IA assumem cada vez mais tarefas operacionais, ignorar os vetores de ataque mapeados em plataformas como o AWS Bedrock é abrir espaço para incidentes com grande potencial de dano estratégico e reputacional.