A AWS anunciou em março de 2026 uma expansão importante no serviço AWS Config, adicionando suporte para 30 novos tipos de recursos em seus principais serviços. Esta atualização inclui recursos do Amazon Bedrock AgentCore e Amazon Cognito, entre muitas outras ofertas da plataforma AWS, representando um avanço significativo na capacidade de governança e auditoria da infraestrutura em nuvem.
Com esta ampliação de cobertura, os usuários da AWS ganham maior visibilidade sobre seu ambiente de nuvem, permitindo descobrir, avaliar, auditar e remediar um espectro bem mais abrangente de recursos gerenciados. Essa funcionalidade é particularmente importante para organizações brasileiras que precisam manter conformidade regulatória e controle rigoroso sobre seus ativos em nuvem.
Como a atualização funciona automaticamente
Uma vantagem importante desta atualização é que ela opera de forma transparente. Quando um usuário já tiver habilitado a gravação de todos os tipos de recursos no AWS Config, os novos tipos serão rastreados automaticamente, sem necessidade de reconfiguração manual. Isso simplifica significativamente a operação para equipes de infraestrutura e DevOps.
Os novos tipos de recursos também estão disponíveis em outras funcionalidades do AWS Config, como Config rules (regras de configuração) e Config aggregators (agregadores de configuração), ampliando ainda mais as possibilidades de monitoramento e automação de conformidade.
Novos tipos de recursos agora suportados
O AWS Config agora pode monitorar os seguintes tipos de recursos em todas as regiões da AWS onde esses serviços estão disponíveis:
AWS::AppSync::DataSource
AWS::Batch::ConsumableResource
AWS::Bedrock::DataSource
AWS::BedrockAgentCore::Gateway
AWS::BedrockAgentCore::Memory
AWS::Cognito::IdentityPoolRoleAttachment
AWS::Cognito::LogDeliveryConfiguration
AWS::Cognito::UserPoolUICustomizationAttachment
AWS::Connect::RoutingProfile
AWS::DataBrew::Dataset
AWS::DataBrew::Job
AWS::DataBrew::Project
AWS::DataBrew::Recipe
AWS::DataBrew::Ruleset
AWS::DataBrew::Schedule
AWS::Deadline::LicenseEndpoint
AWS::Deadline::QueueEnvironment
AWS::Detective::OrganizationAdmin
AWS::GameLift::ContainerFleet
AWS::GameLift::ContainerGroupDefinition
AWS::GameLift::GameServerGroup
AWS::GameLift::Location
AWS::IoT::TopicRule
AWS::Omics::ReferenceStore
AWS::PCAConnectorAD::Template
AWS::PCAConnectorSCEP::Challenge
AWS::ResourceExplorer2::View
AWS::ResourceGroups::Group
AWS::Scheduler::ScheduleGroup
AWS::VerifiedPermissions::IdentitySource
Disponibilidade e próximos passos
Todos esses tipos de recursos estão disponíveis em todas as regiões da AWS onde os serviços correspondentes estão operacionais. Para começar a aproveitar este aumento de cobertura, usuários que já têm gravação ativada para todos os tipos de recursos não precisam fazer nada — o rastreamento dos novos tipos começará automaticamente.
Para aqueles que desejam configurações mais granulares ou precisam entender melhor como trabalhar com os novos tipos de recursos, a documentação técnica completa está disponível na documentação oficial do AWS Config.
Introdução: Agentes de IA e Controle de Acesso na AWS
Conforme agentes de IA se integram nos fluxos de trabalho de desenvolvimento na Amazon Web Services (AWS), surge um desafio importante: como conceder a esses agentes permissões para operar com recursos AWS sem criar modelos de controle de acesso paralelos e sem comprometer a segurança? A AWS respondeu a essa demanda durante o evento re:Invent 2025, apresentando quatro servidores gerenciados do Protocolo de Contexto do Modelo (MCP) em fase de visualização prévia.
A abordagem inovadora da plataforma oferece flexibilidade significativa: os agentes de IA trabalham com suas credenciais AWS existentes, aproveitando as mesmas políticas de Identidade e Acesso (IAM) já estabelecidas. Ao mesmo tempo, as organizações ganham a capacidade de implementar controles de governança específicos para diferenciar chamadas de API realizadas por agentes de IA daquelas executadas diretamente por desenvolvedores.
Os Servidores MCP Gerenciados da AWS
A AWS lançou quatro servidores remotos gerenciados do MCP: AWS, EKS e ECS, além do SageMaker. Diferentemente das implementações locais, esses servidores são hospedados e gerenciados pela AWS, eliminando a necessidade de instalação e manutenção manual. A plataforma oferece atualizações automáticas, resiliência, escalabilidade e auditoria completa através do AWS CloudTrail.
Por exemplo, o AWS MCP Server permite aos agentes de IA acessar documentação de AWS e executar chamadas para mais de 15 mil APIs disponíveis, possibilitando que realizem tarefas complexas e em múltiplas etapas, como configurar redes privadas virtuais (VPCs) ou estabelecer alarmes no Amazon CloudWatch.
Contextos de IAM Padronizados: O Cerne do Controle
O ponto central da solução reside em dois contextos de IAM padronizados que funcionam consistentemente em todos os servidores MCP gerenciados pela AWS:
As Duas Chaves de Contexto Principais
aws:ViaAWSMCPService (booleano) — Assume o valor verdadeiro quando a requisição provém através de um servidor MCP gerenciado pela AWS. Utilize essa chave para permitir ou negar todas as ações iniciadas pelo MCP.
aws:CalledViaAWSMCP (cadeia de texto, valor único) — Contém o identificador do serviço principal do servidor MCP (por exemplo, aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, ecs-mcp.amazonaws.com). Empregue essa chave quando precisar permitir ou negar ações originadas de servidores MCP específicos. Conforme novos servidores MCP forem disponibilizados, esse campo incorporará seus identificadores, permitindo configurar acesso refinado aos recursos AWS através de políticas de IAM e de controle de serviço (SCP).
Implementando Políticas de Segurança em Camadas
Para organizações que desejam desabilitar completamente o acesso via servidores MCP em toda a organização ou em unidades organizacionais específicas, é possível utilizar uma política de controle de serviço (SCP) para negar ações quando acessadas através dos servidores MCP:
Em outro cenário, você pode autorizar agentes de IA utilizando o AWS MCP Server a ler baldes do Amazon Simple Storage Service (Amazon S3), mas recusar operações de exclusão. O AWS MCP Server fornece a ferramenta aws___call_aws, capaz de executar qualquer operação de API da AWS, incluindo operações de S3:
Você também pode restringir o acesso apenas a servidores MCP específicos. Por ilustração, permitir operações EKS somente quando chamadas através do servidor MCP para EKS, não através do servidor MCP geral da AWS:
Baseando-se em retorno dos clientes, a AWS está simplificando o modelo de autorização para funcionar de forma equivalente ao AWS Command Line Interface (AWS CLI) e aos SDKs que você já utiliza. A partir de breve, deixará de ser necessário separar ações de IAM específicas do MCP (como aws-mcp:InvokeMCP) para interagir com servidores MCP gerenciados pela AWS.
Nessa abordagem revisada, o servidor MCP adiciona os contextos padronizados de IAM (aws:ViaAWSMCPService e aws:CalledViaAWSMCP) à sua requisição e a encaminha ao serviço AWS a jusante. O servidor MCP continua autenticando a requisição utilizando SigV4 como antes. Posteriormente, o serviço a jusante realiza a verificação de autorização com base em suas políticas de IAM vigentes, que podem referenciar essas chaves de contexto para implementar controle refinado.
Isso signifi que seus agentes de IA funcionam com suas credenciais AWS existentes e com as permissões de nível de serviço, dispensando a necessidade de ações de IAM isoladas para MCP e diminuindo a complexidade operacional.
Fluxo de autorização para servidores MCP gerenciados — fonte: Aws
Segurança em Profundidade com VPC Endpoints
A AWS está desenvolvendo suporte para pontos de extremidade de nuvem privada virtual (VPC endpoints) nos servidores MCP gerenciados, atendendo à demanda de clientes em setores regulados que exigem controles a nível de rede. Organizações em segmentos como serviços financeiros e saúde necessitam de comunicação via rede privada para cumprir mandatos de conformidade.
Com os VPC endpoints, todo o tráfego de agentes de IA permanece na rede privada, eliminando exposição através da internet pública. Quando você configura um ponto de extremidade VPC, o servidor MCP realiza uma verificação de autorização no nível do endpoint VPC antes de encaminhar requisições aos serviços AWS a jusante. Isso estabelece uma estratégia de defesa em profundidade, onde você controla acesso tanto no perímetro de rede (VPC endpoint) quanto no nível de serviço (políticas de IAM).
Você pode combinar VPC endpoints com as chaves de contexto aws:ViaAWSMCPService e aws:CalledViaAWSMCP para implantar controles de segurança em camadas que satisfaçam os critérios específicos de governança e conformidade da sua organização. Detalhes adicionais sobre chaves de contexto e padrões de exemplo estarão disponíveis quando o suporte para VPC endpoints for lançado.
Considerações Importantes para Implementação
Ao executar a autorização de IAM para servidores MCP, você precisa tomar decisões sobre padrões de implementação, design de políticas e práticas operacionais. As seguintes recomendações podem ajudar na escolha da abordagem correta para seu ambiente:
Desenho de Políticas de IAM
Conceda apenas o acesso necessário e refine as políticas regularmente, removendo permissões não utilizadas ao longo do tempo. Use as chaves de contexto para diferenciar chamadas através de soluções de IA de ações diretas de desenvolvedores, mantendo uma postura de segurança coerente em sua infraestrutura.
Segurança e Conformidade
Os VPC endpoints ajudam a atender aos requisitos de comunicação de rede privada em setores regulados. Eles proporcionam um mecanismo adicional de segurança para ambientes que enfrentam exigências estritas de isolamento de rede e conformidade regulatória.
Iniciando a Jornada
Comece com o padrão de implementação que se alinha às suas necessidades atuais. Inicie com políticas de IAM restritivas e flexibilize-as conforme você compreenda melhor os requisitos de seus agentes de IA. Monitore os registros do CloudTrail para observar quais ações seus agentes de IA realizam e utilize esses dados para refinar suas políticas progressivamente.
Conclusão
A AWS entrega às organizações o controle necessário para governar o acesso de agentes de IA aos recursos AWS através dos Servidores MCP Gerenciados, utilizando as mesmas políticas de IAM e ferramentas nas quais você já confia. Os contextos padronizados de IAM (aws:ViaAWSMCPService e aws:CalledViaAWSMCP) estão disponíveis em todos os servidores MCP gerenciados pela AWS, oferecendo controle granular para diferenciar chamadas via soluções de IA de ações iniciadas por pessoas em nível de serviço.
Em lançamentos futuros, os servidores MCP gerenciados da AWS funcionarão sem a necessidade de ações de IAM isoladas através de endpoints públicos, simplificando a gestão de políticas de IAM. Haverá também suporte para VPC endpoints, com segurança aprimorada mediante autorização em duas fases e controles de perímetro de rede para organizações que exigem restrições de acesso adicionais.
Consulte a documentação específica de seu servidor MCP gerenciado para confirmar se oferece suporte ao novo modelo de autorização de endpoint público e aos VPC endpoints. Seja você desenvolvendo assistentes de codificação com IA ou construindo aplicações com agentes autônomos, comece a implementar esses controles hoje para proteger seus fluxos de trabalho de IA, mantendo ao mesmo tempo a flexibilidade de definir regras de acesso que reflitam a postura de segurança da sua organização.
Controles de Criptografia em VPC ganham modelo de precificação
A AWS anunciou a transição para um modelo de precificação para os Controles de Criptografia em VPC, um recurso de segurança e conformidade que permite às organizações auditar e aplicar criptografia em trânsito para todos os fluxos de tráfego dentro de e entre Nuvens Privadas Virtuais (VPCs) em uma região.
Como funcionam os Controles de Criptografia em VPC
O recurso oferece dois modos de operação distintos:
Modo Monitor: detecta a presença de qualquer tráfego não criptografado dentro da VPC, permitindo uma análise do cenário atual sem impor restrições.
Modo Enforce (Aplicação): garante que todos os dados em trânsito sejam criptografados e impede o funcionamento de qualquer recurso que permita tráfego não criptografado dentro da VPC.
Modelo de precificação a partir de março de 2026
A partir de 1º de março de 2026, os Controles de Criptografia em VPC deixaram o período de preview gratuito e passaram a funcionar sob um modelo de preço por hora. A cobrança segue a seguinte lógica:
Cada VPC não vazia (aquela que possui interfaces de rede) com Controles de Criptografia habilitados em modo monitor ou modo enforce será cobrada por uma taxa horária fixa.
VPCs vazias com Controles de Criptografia habilitados não geram cobrança.
Quando a criptografia é habilitada em um Gateway de Trânsito (Transit Gateway), as cobranças padrão dos Controles de Criptografia em VPC se aplicam a todas as VPCs conectadas a ele, independentemente do modo delas (monitor, enforce ou desativado), mesmo que sejam vazias.
Próximos passos
Para compreender melhor como funcionam os Controles de Criptografia em VPC e consultar os preços detalhados por região, a AWS disponibiliza documentação sobre Controles de Criptografia em VPC e a página de precificação de VPC, onde é possível encontrar as informações mais atualizadas para planejar o investimento em segurança de dados em trânsito.
A AWS anunciou uma importante evolução no Network Firewall: agora o serviço se integra com o Amazon EventBridge para entregar notificações em tempo real sobre mudanças de estado e atualizações de configuração do firewall. Essa integração abre novas possibilidades para quem trabalha com infraestrutura de segurança de rede na nuvem.
O que muda com essa integração
A nova capacidade permite monitorar operações críticas do firewall, incluindo atualizações de configuração e modificações de status de endpoints em toda sua infraestrutura de segurança de rede. Com a integração ao EventBridge, você ganha visibilidade imediata sobre mudanças que afetam as Regras Gerenciadas pela AWS, Regras Gerenciadas por Parceiros e as configurações do firewall.
Automatização e resposta rápida
Com a integração ao EventBridge, surge a possibilidade de construir fluxos de trabalho automatizados para diferentes tipos de resposta. É possível enviar notificações através do Amazon SNS, criar tickets automaticamente em sistemas de gerenciamento de serviços de TI (ITSM), ou conectar com soluções externas de Gerenciamento de Informações e Eventos de Segurança (SIEM).
Essa abordagem helps manter melhor consciência operacional da sua infraestrutura de segurança de rede e permite responder com rapidez a mudanças de configuração ou problemas potenciais.
Disponibilidade
As notificações de mudança de estado do AWS Network Firewall através do Amazon EventBridge estão disponíveis em todas as regiões da AWS onde o Network Firewall e o EventBridge já funcionam. Para aprofundar sobre essa integração, consulte a documentação do AWS Network Firewall. Detalhes adicionais sobre o Amazon EventBridge estão disponíveis na documentação do Amazon EventBridge.
A AWS anunciou melhorias significativas no EC2 Image Builder, o serviço responsável por automatizar a criação, distribuição e gerenciamento de imagens de máquinas virtuais personalizadas na plataforma. As novidades focam em dois pontos críticos: suporte a padrões wildcard em políticas de ciclo de vida e simplificação no processo de criação de funções de Controle de Acesso (IAM — Identity and Access Management).
Suporte a Wildcards em Políticas de Ciclo de Vida
O Desafio Anterior
Antes dessa atualização, gerenciar o ciclo de vida de múltiplas imagens exigia criar políticas separadas para cada nova receita de imagem, ou selecionar manualmente cada receita individual. Conforme a infraestrutura crescia e novas receitas eram adicionadas, essa abordagem manual se tornava impraticável e gerava sobrecarga operacional.
A Nova Solução com Wildcards
Com o suporte a padrões wildcard, você pode agora definir expressões como my-recipe-1.x.x em uma única política de ciclo de vida. Isso aplica automaticamente a política a todas as receitas correspondentes — inclusive àquelas que forem criadas no futuro. Essa abordagem reduz a necessidade de intervenção manual e permite que políticas de ciclo de vida escaem naturalmente conforme sua infraestrutura evolui.
Simplificação na Criação de Funções IAM
O Desafio Anterior
Criar funções IAM para gerenciamento de ciclo de vida exigia configurar manualmente todas as permissões necessárias. Esse processo era propenso a erros de configuração e consumia tempo valioso do administrador, mesmo para ambientes padronizados.
A Nova Solução
Agora, ao criar uma nova função IAM diretamente no console do EC2 Image Builder, a AWS popula automaticamente as permissões padrão necessárias. Essa automação reduz significativamente o tempo de configuração e minimiza a possibilidade de erros de permissionamento, tornando o onboarding mais rápido e seguro.
Impacto na Operação em Escala
Combinadas, essas duas melhorias simplificam tanto o processo inicial de integração quanto a manutenção contínua de políticas de ciclo de vida em larga escala. A redução de sobrecarga operacional permite que equipes se concentrem em aspectos mais estratégicos da gestão de imagens, em vez de lidar com configurações repetitivas.
A AWS anunciou a disponibilidade geral do AWS Security Hub Extended, um plano inovador que integra as capacidades de detecção da AWS com soluções de segurança de parceiros selecionados. O objetivo é transformar a complexa tarefa de gerenciar múltiplos fornecedores e ciclos de compra prolongados em uma experiência unificada através de um único vendedor.
Essa abordagem reconhece um desafio real enfrentado pelas empresas: manter relacionamentos com diversos fornecedores de segurança, negociar contratos individuais e gerenciar faturas separadas consome tempo, recursos e aumenta a complexidade operacional. O Security Hub Extended busca resolver esses problemas ao consolidar as melhores soluções de detecção da AWS com produtos curados de parceiros confiáveis.
Três vantagens principais
Simplificação da aquisição e procurement
O plano integra o uso de múltiplas soluções em um único documento de faturamento, reduzindo significativamente a complexidade administrativa. Clientes que contratam o suporte AWS Enterprise também recebem suporte unificado de Nível 1 da AWS, eliminando a necessidade de escalações para múltiplos fornecedores. Apesar dessa consolidação, cada provedor mantém acesso direto, preservando sua expertise específica de domínio.
Proteção mais abrangente
O Security Hub Extended reúne as capacidades de detecção nativas da AWS com soluções de parceiros em categorias estratégicas: proteção de endpoint, gerenciamento de identidades, segurança de email, proteção de rede, segurança de dados, proteção de navegador, segurança em nuvem, segurança com Inteligência Artificial (IA) e operações de segurança. Essa cobertura ampla permite estabelecer defesas mais robustas e coordenadas.
Eficiência operacional aprimorada
As descobertas de segurança são padronizadas em um formato único, oferecendo visibilidade centralizada em todo o ambiente. Isso reduz significativamente o esforço manual necessário para integrar ferramentas de diferentes fornecedores e normalizar dados de múltiplas fontes.
Flexibilidade e modelo de preços
Os clientes acessam e avaliam soluções de parceiros diretamente através do console do Security Hub, selecionando apenas as soluções necessárias. O modelo oferece opções de preço flexível: pagamento conforme o uso ou taxas fixas mensais. Não há compromissos de longo prazo ou investimentos iniciais obrigatórios, permitindo que as empresas adaptem sua postura de segurança conforme suas necessidades evoluem.
Como a AWS atua como fornecedora de registro, o plano Extended pode ser elegível para oportunidades de precificação privada da AWS, aumentando ainda mais a flexibilidade na negociação de contratos e consolidação de faturas.
Próximos passos
O Security Hub Extended está disponível nas regiões comerciais da AWS onde o Security Hub funciona. Para consultar a lista completa de regiões, acesse a tabela de regiões AWS. Informações detalhadas sobre preços estão disponíveis na página de preços do Security Hub, e para começar, visite o produto.
Durante anos, os agentes de inteligência artificial enfrentaram limitações significativas que os impediam de executar tarefas complexas de forma independente. Eles não conseguiam reter informações aprendidas ao longo do tempo, operavam apenas em períodos curtos sem supervisão contínua, e dependiam constantemente de intervenção humana. A situação começou a mudar com o desenvolvimento dos chamados agentes de fronteira—uma nova categoria de IA capaz de realizar raciocínio complexo, planejamento em múltiplas etapas e execução autônoma por períodos estendidos de horas ou até dias.
Essa evolução abriu caminho para uma estratégia poderosa: a colaboração entre múltiplos agentes especializados. Quando diversos agentes trabalham juntos, podem resolver fluxos de trabalho intrincados que exigem diferentes tipos de conhecimento. No desenvolvimento de software, por exemplo, agentes podem se especializarem em geração de código, revisão e testes. Em pesquisa científica, colaboram em revisão bibliográfica, design experimental e análise de dados. E na cibersegurança, agentes diferentes podem se focar em reconhecimento de sistemas, análise de vulnerabilidades e validação de exploits.
Aplicação em Testes de Penetração Automatizados
Os testes de penetração tradicionais são uma atividade cara e demorada. Profissionais de segurança precisam investigar manualmente cada camada da aplicação, um processo que frequentemente consome semanas de trabalho especializado. Embora ferramentas de teste de segurança e scanners de vulnerabilidades existam há décadas, elas têm limitações claras: funcionam com lógica predefinida e não se adaptam bem a contextos específicos das aplicações.
Com os avanços recentes em modelos de linguagem de grande escala (LLMs, do inglês Large Language Models), os agentes de fronteira trouxeram uma perspectiva diferente. Eles conseguem raciocinar sobre o comportamento de aplicações, adaptar suas estratégias conforme recebem feedback, e compreender o contexto de formas que as ferramentas tradicionais não conseguem.
A AWS desenvolveu um sistema multi-agente especializado para testes de penetração. O conceito funciona assim: em vez de um único agente tentar resolver tudo, múltiplos agentes especializados trabalham em conjunto. Um agente mapeia a superfície de ataque da aplicação, enquanto outros analisam falhas na lógica de negócio, validam descobertas e priorizam vulnerabilidades conforme a possibilidade real de exploração. Essa priorização combina tentativas de exploração reais executadas por agentes da rede, re-validação independente por validadores especializados, e uma pontuação baseada em IA segundo o Sistema Comum de Pontuação de Vulnerabilidades (CVSS, do inglês Common Vulnerability Scoring System).
Arquitetura do Sistema de Testes de Penetração
O sistema implementado segue uma estrutura bem definida, com componentes que trabalham sequencialmente para construir uma análise de segurança progressivamente mais profunda.
Fase de Autenticação e Acesso Inicial
Tudo começa com um componente inteligente de autenticação. Este elemento combina raciocínio baseado em LLM com mecanismos determinísticos para lidar com diferentes arquiteturas de aplicações. Ele localiza páginas de login, tenta credenciais fornecidas e mantém sessões autenticadas para as fases de teste subsequentes. O sistema se adapta automaticamente a diferentes estruturas de aplicação e ambientes alvo, usando ferramentas de navegação web. Os desenvolvedores também podem fornecer um prompt de autenticação personalizado se precisarem otimizar o processo para sua aplicação específica.
Fase de Varredura Baseline
Após a autenticação bem-sucedida, o sistema inicia uma varredura de cobertura abrangente através da execução paralela de scanners especializados. Em testes sem acesso ao código-fonte (black-box), um scanner de rede executa testes de segurança de aplicações web automatizados, gerando interações de tráfego bruto e identificando endpoints potencialmente vulneráveis. Já em testes com acesso ao código (white-box), um scanner adicional realiza análise profunda do código-fonte quando repositórios estão disponíveis, produzindo documentação descritiva em múltiplas categorias. Scanners especializados complementam essas capacidades para identificar vulnerabilidades em diferentes dimensões e estabelecer uma cobertura inicial sólida.
Exploração em Múltiplas Fases
O sistema emprega duas abordagens de exploração distintas que trabalham em conjunto. A execução gerenciada utiliza tarefas estáticas predefinidas cobrindo categorias principais de risco como scripts entre sites (XSS), referências diretas inseguras a objetos (IDOR), escalação de privilégios e outras. Este componente ajuda sistematicamente a garantir cobertura abrangente ao executar tarefas curadas para cada tipo de risco.
Na próxima fase, a exploração guiada adota uma abordagem dinâmica e dirigida por inteligência. Este componente absorve endpoints descobertos, achados validados e documentação de análise de código para raciocinar sobre oportunidades de ataque específicas da aplicação. Ele funciona em dois estágios: primeiro gerando um plano de teste de penetração contextualizado identificando recursos não explorados e possíveis cadeias de vulnerabilidades, depois gerenciando programaticamente a execução dessas tarefas geradas dinamicamente. O explorador guiado executa com tarefas adaptativas que evoluem conforme as respostas da aplicação e padrões descobertos.
Enxame de Agentes Especializados
Ambas as abordagens de exploração distribuem trabalho para agentes especializados do enxame—cada um configurado para tipos específicos de risco e equipado com kits abrangentes de teste de penetração incluindo executores de código, fuzers web, busca em banco de dados de vulnerabilidades da NIST (NVD, do inglês National Vulnerability Database) para inteligência de Vulnerabilidades e Exposições Comuns (CVEs, do inglês Common Vulnerabilities and Exposures), e ferramentas específicas para cada tipo de vulnerabilidade. Esses agentes executam tarefas atribuídas com gerenciamento de tempo limite e relatórios estruturados.
Validação e Geração de Relatórios
Quando agentes especializados identificam riscos de segurança potenciais, geram relatórios estruturados contendo o tipo de vulnerabilidade, endpoints afetados, evidência de exploração e contexto técnico. Porém, os testes de penetração automatizados enfrentam um desafio crítico: agentes baseados em LLM podem produzir achados que parecem plausíveis mas não são reais. Para contornar isso, achados candidatos passam por validação através de validadores determinísticos e agentes especializados baseados em LLM que tentam exploração ativa. O sistema emprega técnicas de validação baseada em asserções onde asserções em linguagem natural escritas por especialistas em segurança codificam conhecimento profundo sobre comportamentos reais de ataques, exigindo prova explícita e estruturada que é significativamente mais difícil de contornar do que verificações determinísticas simples.
Os achados validados passam por análise CVSS para avaliação de severidade, e são sintetizados em relatórios finais com resultados de validação, pontuações de severidade e evidência de exploração—projetados para entregar vulnerabilidades confiáveis e acionáveis para remediação efetiva.
Desempenho e Avaliação
Para avaliar o sistema, a AWS realizou avaliação humana além de testes automáticos de desempenho. Analisaram trajetórias de mundo real e criaram uma taxonomia de padrões de erro. Identificando padrões de erro frequentes, conseguiram iterar na solução.
Os resultados foram reportados no benchmark público CVE Bench, uma coleção de aplicações web vulneráveis contendo 40 CVEs de severidade crítica do Banco Nacional de Vulnerabilidades usada para avaliar agentes de IA em exploits reais. Cada aplicação inclui referências de exploit automático, e agentes baseados em LLM tentam executar ataques que disparam as vulnerabilidades. O sucesso é medido através da métrica de taxa de sucesso de ataque (ASR, do inglês Attack Success Rate), definida como a taxa de exploração bem-sucedida de vulnerabilidades da aplicação.
O benchmark fornece um avaliador que o agente pode consultar para verificar sucesso de exploit e oferece instruções explícitas de captura de flag (CTF). A avaliação ocorreu em três configurações:
Com instruções CTF e verificações de avaliador após cada chamada de ferramenta: atingiu 92,5% no CVE Bench v2.0 (nota que alguns desafios envolvem exploração cega onde o agente não pode verificar sucesso sem esse feedback)
Sem instruções CTF ou feedback de avaliador: atingiu 80%—o que melhor reflete condições reais onde o agente deve se auto-validar através de resultados observáveis
Usando um LLM cujo conhecimento anterior à data é anterior à liberação do CVE Bench v1.0: atingiu 65% de ASR
Um exemplo prático demonstra como o agente de IA referencia parametricamente CVE-2023-37999 de seus dados de treinamento, então emite um comando bash para verificar pré-requisitos de exploração:
# HT Mega 2.2.0 tem uma vulnerabilidade conhecida – CVE-2023-37999
# Tem escalação de privilégio não autenticada via endpoint de configurações REST API
# Vamos verificar se o registro está ativado
curl -s http://target:9090/wp-login.php?action=register -I | head -10
Desafios de Otimização e Não-Determinismo
Duas questões técnicas importantes surgiram durante o desenvolvimento:
Equilíbrio entre Exploração e Varredura: Um desafio central em testes de penetração é determinar o equilíbrio entre exploração profunda e exploração ampla. Uma abordagem em profundidade primeiro (depth-first) pode desperdiçar muito poder computacional em direções específicas, resultando em menor cobertura de vulnerabilidades dentro de um orçamento computacional fixo. Em contraste, uma busca em largura primeiro (breadth-first) é improvável de descobrir vulnerabilidades profundas que exigem testes de múltiplas abordagens. Portanto, é necessário um equilíbrio entre as duas estratégias para maximizar cobertura para um orçamento computacional dado. O design do sistema proposto busca incluir uma abordagem híbrida, embora uma solução dinâmica mais eficiente que generalize através de várias vulnerabilidades e diferentes aplicações web permaneça uma questão de pesquisa aberta.
Não-Determinismo: Outro desafio com testes de penetração é o não-determinismo. Por causa dos LLMs subjacentes, a saída de execuções de teste de penetração pode variar de uma execução para outra. Ter achados diferentes através de múltiplas execuções pode levar a confusão. Uma opção para mitigar isso é executar múltiplas rodadas e consolidar os achados entre elas.
Implicações para Segurança de Aplicações
Este sistema multi-agente demonstra uma mudança importante em como abordamos teste de segurança automatizado. Ao orquestrar componentes especializados com geração de tarefas adaptativas e validação baseada em asserções, o sistema entrega cobertura de segurança abrangente que evolui baseada em contexto específico da aplicação e padrões descobertos. A capacidade de realizar ataques encadeados complexos—combinando divulgação de informações com escalação de privilégio, ou IDOR com bypass de autenticação—representa um avanço significativo em relação aos scanners tradicionais que geralmente identificam apenas vulnerabilidades isoladas.
A AWS continua empenhada em expandir a fronteira de detecção de vulnerabilidades de segurança através de avaliação contínua do agente e mantendo-se competitivo com benchmarks mais novos e desafiadores. Para mais informações e começar a usar essas capacidades, desenvolvedores podem acessar a documentação de primeiros passos do serviço.
A nova capacidade de testes em ambientes multi-conta
A AWS anunciou uma expansão importante do AWS Security Agent, permitindo que clientes executem testes de penetração contra recursos de Virtual Private Cloud (VPC) compartilhados de outras contas AWS dentro da mesma organização. Essa nova funcionalidade capacita equipes de segurança a realizarem avaliações de segurança abrangentes em seus ambientes multi-conta usando o AWS Security Agent.
A novidade se torna especialmente relevante para organizações que mantêm arquiteturas distribuídas espalhadas por múltiplas contas AWS. Até então, testar a segurança de recursos compartilhados entre contas apresentava desafios significativos para profissionais de segurança.
Como funciona o compartilhamento seguro de recursos
O novo recurso aproveita o AWS Resource Access Manager (RAM) para permitir que clientes compartilhem de forma segura recursos de VPC de sub-contas para uma conta central, onde os testes de penetração são conduzidos. Essa abordagem simplifica bastante a execução de avaliações de segurança em organizações com configurações multi-conta complexas.
A mecânica é direta: profissionais de segurança podem criar um Agent Space (espaço de agente) em uma conta central e usar o RAM para acessar recursos de VPC de sub-contas conectadas com a finalidade de realizarem testes. Esse fluxo centralizado e coordenado aprimora a postura geral de segurança da organização.
Por que isso importa para sua organização
A capacidade de testar abrangentemente recursos compartilhados de VPC contribui significativamente para fortalecer a postura de segurança geral de uma organização. Para equipes que precisam gerenciar ambientes complexos e distribuídos, essa funcionalidade reduz fricção operacional e padroniza os processos de avaliação de segurança.
A nova capacidade do AWS Security Agent democratiza testes de segurança mais robustos mesmo em arquiteturas multi-conta, antes consideradas desafiadoras para automação centralizada.
Primeiros passos
Para começar, certifique-se de que suas contas fazem parte da mesma AWS Organization e configure o compartilhamento de recursos usando o RAM. Em seguida, lance o AWS Security Agent em sua conta central para iniciar testes de penetração nos recursos compartilhados de VPC.
Para informações adicionais sobre o AWS Security Agent e suas capacidades de testes de penetração, consulte a documentação do AWS Security Agent.
Aurora DSQL expande compatibilidade com ferramentas de desenvolvimento
A AWS anunciou, em fevereiro de 2026, o lançamento de integrações do Aurora DSQL com ferramentas populares de Object-Relational Mapping (ORM) e migração de banco de dados. O anúncio inclui um adaptador para Tortoise (ORM em Python), um dialeto para Flyway (ferramenta de gerenciamento de schema), e ferramentas de linha de comando para Prisma (ORM em Node.js). Essas integrações foram desenvolvidas para facilitar a utilização do Aurora DSQL por desenvolvedores que já utilizam esses frameworks em seus projetos.
Adaptador para Tortoise: simplificando desenvolvimento em Python
O Adaptador Aurora DSQL para Tortoise possibilita que desenvolvedores Python construam aplicações utilizando Tortoise sem necessidade de escrever código customizado para autenticação. O adaptador oferece suporte tanto para drivers asyncpg quanto psycopg, integra-se ao Aurora DSQL Connector para Python para geração automática de tokens de autenticação (IAM), e inclui patches de compatibilidade para migrações avançadas.
Dialeto Flyway: compatibilidade com arquitetura distribuída
O dialeto Flyway foi adaptado especificamente para a arquitetura distribuída do Aurora DSQL. Essa integração gerencia automaticamente comportamentos específicos do Aurora DSQL, como autenticação baseada em Identidade e Acesso (IAM), permitindo que a ferramenta trabalhe perfeitamente com o serviço da AWS sem configurações adicionais complexas.
Ferramentas CLI Prisma: validação e migração
As ferramentas de linha de comando Prisma para Aurora DSQL auxiliam desenvolvedores Node.js na validação de seus schemas Prisma para compatibilidade com o Aurora DSQL e na geração de migrações compatíveis com o serviço. Esse conjunto de ferramentas simplifica significativamente o caminho desde o desenvolvimento até a produção.
Próximos passos e recursos disponíveis
Para começar, a AWS disponibilizou repositórios GitHub para cada uma das integrações: Tortoise ORM, Flyway, e Prisma. Desenvolvedores podem começar a explorar Aurora DSQL gratuitamente através da camada gratuita da AWS. Para aprender mais sobre o Aurora DSQL, visite a página oficial do serviço.
Novas integrações para simplificar o acesso ao Aurora DSQL
A AWS anunciou o lançamento de duas integrações importantes para o Aurora DSQL: o Driver Aurora DSQL para SQLTools e o Plugin Aurora DSQL para DBeaver Community Edition. Essas integrações abrem novas possibilidades para profissionais que trabalham com banco de dados, permitindo usar ferramentas populares e consolidadas em seus fluxos de trabalho.
O que essas integrações oferecem
As duas novas integrações permitem aos usuários do Aurora DSQL aproveitar ferramentas robustas de banco de dados para executar consultas contra clusters do Aurora DSQL, explorar esquemas de banco de dados e gerenciar seus dados de forma intuitiva. A proposta é tornar o acesso ao banco de dados mais direto e prático, eliminando as complexidades técnicas tradicionais.
Autenticação simplificada e segura
Um dos principais benefícios dessas integrações é a simplificação da autenticação. Ambas eliminam a necessidade de escrever código para geração de tokens ou fornecer manualmente tokens IAM (Gerenciamento de Identidade e Acesso). O sistema automaticamente trata a autenticação IAM e gerencia transparentemente os tokens de acesso, o que significa menos linhas de código e menos pontos de falha na sua infraestrutura.
Isso também elimina os riscos de segurança associados às tradicionais senhas geradas por usuários. Com as duas integrações, é possível usar credenciais AWS IAM para autenticação segura e sem necessidade de senha.
Integração com Visual Studio Code e editores compatíveis
O driver SQLTools integra o Aurora DSQL com Visual Studio Code e está também disponível no Open VSX Registry para uso em editores compatíveis com VS Code, como Cursor e Kiro. Isso oferece flexibilidade para desenvolvedores que preferem diferentes ambientes de desenvolvimento.
Plugin DBeaver baseado no conector JDBC
O plugin para DBeaver é construído com base no Aurora DSQL Connector para JDBC (Conectividade de Banco de Dados Java), aproveitando uma arquitetura consolidada na comunidade de desenvolvimento Java.
Se deseja experimentar o Aurora DSQL sem custos, é possível começar gratuitamente através da camada gratuita da AWS. Para mais informações sobre o Aurora DSQL e suas capacidades, consulte a página oficial do serviço.
