AWS e Vercel corrigem brechas graves em agentes de IA e acendem alerta sobre segurança
A recente correção de vulnerabilidades em plataformas de agentes de inteligência artificial da AWS e da Vercel expõe um problema estrutural na forma como esses sistemas lidam com ferramentas externas. As falhas permitiam que ações sensíveis fossem executadas sem uma autorização real do modelo de IA, abrindo caminho para abusos em ambientes corporativos que dependem de agentes autônomos para automatizar tarefas.
Em cenários específicos, comandos críticos podiam ser disparados sem que a IA de fato analisasse, interpretasse ou aprovasse a operação. Ou seja, bastava que a infraestrutura acreditasse que a chamada havia sido “assinada” pelo agente, quando, na prática, ela podia ter sido injetada diretamente pelo usuário ou por código malicioso.
Esses problemas se enquadram em um padrão de vulnerabilidade conhecido como CoreBreak. Nesse modelo de falha, o sistema de orquestração dos agentes de IA trata determinadas chamadas de ferramentas como se fossem, por definição, confiáveis. Em vez de validar se o pedido partiu realmente do agente após um raciocínio do modelo, a infraestrutura assume que qualquer chamada com o formato esperado é legítima – o que abre uma porta perigosa para ataques.
No caso da AWS, a vulnerabilidade foi catalogada como CVE-2026-18830 e afetava a API InvokeHarness do Amazon Bedrock AgentCore. Um usuário autenticado conseguia anexar uma chamada especialmente manipulada ao final de uma requisição legítima. Com isso, era possível acionar diretamente ferramentas disponíveis no ambiente, contornando a lógica que deveria ficar sob controle exclusivo do agente de IA.
Já na plataforma da Vercel, foram corrigidas duas falhas distintas, registradas como CVE-2026-64650 e CVE-2026-64651. Ambas estavam relacionadas à forma como código executado dentro de uma sandbox Linux podia, em determinadas condições, ultrapassar os limites desse ambiente isolado e alcançar ferramentas expostas no sistema hospedeiro. Na prática, o isolamento que deveria proteger a infraestrutura podia ser quebrado.
A gravidade aumenta de acordo com as permissões configuradas para essas ferramentas. Em muitos cenários, um invasor poderia, a partir dessas brechas, consultar segredos armazenados, interagir com APIs de provedores de nuvem ou realizar operações diretamente ligadas a pipelines de implantação. Isso amplia significativamente o impacto de qualquer código malicioso processado por agentes voltados a tarefas de programação, DevOps ou automação de infraestrutura.
Apesar da criticidade técnica, até o momento não há confirmação pública de que essas vulnerabilidades tenham sido exploradas em ataques concretos. Ainda assim, o risco teórico é alto o suficiente para exigir uma resposta rápida das empresas. Organizações que utilizam agentes de IA integrados a workloads sensíveis devem tratar o caso como um alerta importante sobre o desenho de seus fluxos de autorização.
Especialistas recomendam que as empresas atualizem imediatamente os componentes afetados, aplicando as correções fornecidas pelos fornecedores. Mas a mitigação não termina no patch. É essencial limitar o conjunto de ferramentas que um agente de IA pode acionar, adotando o princípio do menor privilégio: o agente só deve acessar exatamente o que for indispensável para sua função, nada além disso.
Outro ponto crítico é a forma como entradas externas são tratadas. Históricos de conversas, eventos recebidos de outros sistemas, webhooks e qualquer tipo de chamada encaminhada a um agente devem ser considerados, por padrão, como dados potencialmente maliciosos. Isso implica validar formatos, impor limites de contexto, inspecionar conteúdos suspeitos e, sempre que possível, adicionar camadas intermediárias de checagem antes de permitir ações de alto impacto.
As falhas relacionadas ao padrão CoreBreak também revelam um problema cultural: muitos times tratam agentes de IA como “usuários confiáveis” dentro da arquitetura, mas esquecem que tudo o que chega a eles é, na essência, input. Quando não há uma separação clara entre o que o usuário pede e o que o agente realmente decidiu executar, qualquer mecanismo de chamada de ferramenta se torna um alvo óbvio para exploração.
Do ponto de vista de governança, é recomendável mapear com detalhes quais agentes estão em produção, que ferramentas eles conseguem acessar e quais dados são expostos em cada integração. Documentar essas relações ajuda a identificar pontos de acoplamento excessivo, onde um único agente tem acesso ao mesmo tempo a segredos, APIs de nuvem e mecanismos de implantação – uma combinação extremamente atraente para invasores.
Outra medida prática é implementar camadas de autorização independentes do agente. Em vez de confiar apenas na “intenção” inferida pelo modelo, ferramentas críticas podem exigir políticas adicionais, como aprovação baseada em regras, checagem de contexto, exigência de justificativas e até validação humana em operações mais sensíveis, como destruição de recursos, alterações de credenciais ou deploys em ambientes de produção.
O episódio também reforça a necessidade de incluir agentes de IA em processos formais de teste de segurança. Avaliações que antes se limitavam a aplicações web tradicionais agora precisam contemplar fluxos de prompt injection, manipulação de chamadas de ferramenta, quebras de isolamento em sandboxes e abuso de integrações com APIs internas. Scans automatizados não são suficientes: é preciso combinar testes dinâmicos, análise de arquitetura e, cada vez mais, técnicas de segurança assistidas por IA.
Para equipes de desenvolvimento, uma boa prática é tratar a camada de orquestração dos agentes como código de segurança crítica, adotando revisões rigorosas, testes unitários e de integração focados especificamente no comportamento das ferramentas. Simular chamadas maliciosas, inputs truncados e cenários de bypass ajuda a identificar fragilidades antes que se tornem vulnerabilidades exploráveis.
Em termos estratégicos, o caso da AWS e da Vercel mostra que a corrida pela adoção de agentes autônomos precisa andar lado a lado com um amadurecimento acelerado em segurança. A cada nova capacidade adicionada – como acesso a mais APIs, maior liberdade de ação ou automação de processos de negócio – cresce também a superfície de ataque. Ignorar esse equilíbrio é transformar inovação em risco.
Ao corrigirem rapidamente as falhas e divulgarem informações técnicas sobre os problemas, AWS e Vercel sinalizam que a indústria começa a tratar a segurança de agentes de IA como uma disciplina própria, e não apenas como um apêndice da segurança tradicional de aplicações. Para as empresas usuárias, a mensagem é clara: atualizar, restringir, monitorar e revisar periodicamente o desenho de seus agentes deixou de ser opcional. É uma exigência básica para operar com IA de forma responsável e segura.