User's blog

Author: Make.com Service User

  • Resumo de Segurança AWS: Tudo que Aconteceu em Abril de 2026

    Visão Geral do Mês

    Todo mês, o blog de segurança da AWS consolida os principais lançamentos, posts técnicos, amostras de código e boletins de vulnerabilidades em um único digest. Abril de 2026 foi especialmente movimentado: o tema central foi a segurança de sistemas de IA agêntica, mas o mês também trouxe avanços importantes em proteção de dados, resposta a incidentes e conformidade em escala organizacional. Veja abaixo o que foi publicado e o que merece atenção imediata no seu ambiente.

    Posts do Blog de Segurança AWS

    Os artigos de abril cobriram cinco grandes áreas: identidade e controle de acesso, segurança de IA, governança e conformidade, detecção e resposta a incidentes, e proteção de dados.

    Identidade e Controle de Acesso

    Dois posts exploraram o tema de políticas e controle de acesso com profundidade prática. O primeiro, Controle de acesso com session tags do IAM Identity Center, ensina a combinar permission sets do AWS IAM Identity Center com session tags provenientes do Microsoft Entra ID para implementar Controle de Acesso Baseado em Atributos (ABAC) de forma granular em múltiplas contas AWS.

    O segundo, Dá para fazer isso com uma policy? Entendendo a Referência de Autorização de Serviços da AWS, orienta como usar a AWS Service Authorization Reference para descobrir o que é possível alcançar com políticas IAM, identificar cenários que exigem abordagens alternativas e construir controles de segurança mais eficazes.

    Segurança de IA

    Este foi o bloco mais denso do mês, com cinco publicações dedicadas ao tema.

    O post Padrões de acesso seguro para agentes de IA em recursos AWS usando o Model Context Protocol apresenta três princípios fundamentais: privilégio mínimo, governança de papéis organizacionais e diferenciação entre ações iniciadas por IA e por humanos — tudo no contexto do protocolo MCP.

    Já Quatro princípios de segurança para sistemas de IA agêntica sistematiza as recomendações da AWS em resposta ao NIST: ciclo de vida de desenvolvimento seguro, controles tradicionais adaptados, aplicação determinística de regras externas e autonomia conquistada por meio de avaliação contínua.

    O artigo Projetando confiança e segurança em aplicações com Amazon Bedrock trata da integração de conceitos de IA responsável em aplicações baseadas no Amazon Bedrock, cobrindo detecção de abuso, monitoramento com Amazon CloudWatch, configuração do Bedrock Guardrails e o processo de resposta a abusos.

    O post de maior repercussão do mês foi Construindo defesas de IA em escala: antes das ameaças surgirem. Nele, o CISO da AWS anuncia o Project Glasswing em parceria com a Anthropic, apresentando o Claude Mythos Preview para pesquisa de vulnerabilidades, além da disponibilidade geral do AWS Security Agent para testes de penetração autônomos.

    Governança e Conformidade

    O post Conformidade de tags com Shift-Left usando AWS Organizations e Terraform mostra como validar conformidade de tags ainda durante o desenvolvimento, combinando políticas de tags do AWS Organizations, um módulo Terraform reutilizável e uma abordagem orientada a testes que valida dinamicamente contra políticas organizacionais ativas.

    Detecção e Resposta a Incidentes

    Três publicações cobriram esse domínio. O artigo O que a atualização do Catálogo de Técnicas de Ameaças de março de 2026 significa para seu ambiente AWS, produzido pela equipe CIRT da AWS, detalha três novas técnicas: abuso de refresh token do Amazon Cognito, exclusão de imagens AMI para comprometer a recuperação e modificações em trust policies para persistência e escalada de privilégios.

    Em Um framework para coletar artefatos forenses com segurança em buckets S3, a AWS descreve como realizar coleta forense segura no Amazon S3 usando credenciais temporárias com privilégio mínimo via AWS STS session policies e fluxos automatizados com AWS Step Functions.

    O terceiro post, Transformando logs de segurança para o formato OCSF com uma solução ETL orientada a configuração, apresenta uma solução do AWS ProServe que converte logs personalizados para o formato Open Cybersecurity Schema Framework (OCSF) usando AWS Step Functions, AWS Glue ou Amazon EMR Serverless, com integração ao Amazon Security Lake.

    Vale mencionar ainda o artigo Um guia técnico de segurança multicloud full-stack com AWS Security Hub Extended, que explica como essa extensão simplifica a aquisição e operação de segurança em ambientes multicloud por meio de soluções de parceiros curadas, faturamento unificado e consolidação de findings baseada em OCSF.

    Proteção de Dados

    Três posts abordaram proteção de dados com foco em criptografia avançada.

    O artigo Protegendo seus segredos dos riscos quânticos do futuro orienta como atualizar clientes do AWS Secrets Manager para usar TLS pós-quântico híbrido com ML-KEM, protegendo segredos contra ataques do tipo “harvest-now-decrypt-later” (capturar agora, descriptografar depois), com verificação de conexões via AWS CloudTrail.

    Em Como o AWS KMS e o AWS Encryption SDK superam os limites da criptografia simétrica, a AWS explica como o AWS Key Management Service e o SDK de criptografia usam métodos de chave derivada para gerenciar automaticamente os limites do AES-GCM, eliminando a necessidade de rotação manual de chaves.

    Por fim, Como clonar um cluster AWS CloudHSM entre regiões detalha o uso do comando CopyBackupToRegion para replicar clusters do AWS CloudHSM para outra região e sincronizar chaves — inclusive chaves não exportáveis — para fins de recuperação de desastres.

    Boletins de Segurança de Abril

    A AWS divulgou investigações de vulnerabilidades em vários produtos e serviços ao longo do mês. Abaixo estão os boletins publicados — verifique se algum deles afeta componentes do seu ambiente e aplique os patches recomendados:

    Amostras de Código AWS (AWS Samples)

    Abril trouxe 16 novos repositórios prontos para uso, cobrindo identidade, governança, conformidade, detecção e resposta, segurança de IA, proteção de dados e infraestrutura. Veja os destaques por categoria:

    Identidade

    Governança

    Conformidade

    • Compliance Lens — Solução serverless que analisa snapshots do AWS Config em toda uma organização AWS, compara com conjuntos de regras de conformidade e visualiza o posicionamento de conformidade via Amazon QuickSight.
    • Configuração Terraform para o AWS Security Agent — Provisionamento de recursos do AWS Security Agent usando o provider Terraform AWSCC, automatizando criação de espaço de agente, roles IAM, registro de domínio alvo e configuração de testes de penetração.

    Detecção e Resposta a Incidentes

    Proteção de Dados

    Infraestrutura e Segurança de IA

    O que Fica de Lição do Mês

    Abril de 2026 deixa claro que proteger cargas de trabalho de IA exige o mesmo rigor aplicado à infraestrutura tradicional — e, em alguns aspectos, ainda mais atenção. Os posts e amostras deste mês oferecem padrões concretos para aplicar privilégio mínimo em sistemas agênticos, automatizar governança em escala organizacional e preparar implementações criptográficas para os requisitos pós-quânticos que se aproximam.

    Os boletins de segurança cobrem vulnerabilidades em camadas de computação, rede e ferramentas de desenvolvimento — reforçando a necessidade de aplicar patches de forma consistente e sem atraso. Cada recurso listado aqui inclui etapas de implantação ou código executável para que você possa validar a abordagem no seu próprio ambiente antes de adotá-la em produção.

    Fonte

    ICYMI: April 2026 @AWS Security (https://aws.amazon.com/blogs/security/icymi-april-2026-aws-security/)

  • Amazon SageMaker Unified Studio ganha recursos de gerenciamento de identidade e usuários

    Mais controle para administradores no SageMaker Unified Studio

    A AWS anunciou novos recursos de administração no Amazon SageMaker Unified Studio que ampliam o controle sobre configuração de identidade e gerenciamento de usuários. As novidades atendem tanto domínios do tipo IAM quanto domínios do tipo Identity Center, tornando a gestão de times mais flexível e centralizada.

    O que muda nos domínios IAM do SageMaker

    Para quem utiliza domínios IAM no SageMaker Unified Studio, agora é possível integrar o AWS IAM Identity Center para permitir que usuários acessem a plataforma via single sign-on (autenticação única). Com essa configuração, os administradores podem adicionar como membros de projetos:

    • Funções IAM (IAM roles)
    • Usuários IAM (IAM users)
    • Usuários do IAM Identity Center
    • Grupos do IAM Identity Center

    Isso significa que equipes conseguem colaborar nos dados e recursos de um projeto mesmo que cada membro se autentique de uma forma diferente. A configuração da integração com o IAM Identity Center é feita diretamente pelo portal de administração do SageMaker Unified Studio.

    Outro recurso relevante para domínios IAM é a nova página de gerenciamento de usuários do domínio, que oferece uma visão consolidada de todos os usuários ativos. A partir dessa tela única, os administradores conseguem gerenciar acessos e atualizar permissões sem precisar navegar por múltiplas interfaces.

    O que muda nos domínios Identity Center do SageMaker

    Nos domínios Identity Center, a novidade é a possibilidade de usuários acessarem o portal do SageMaker Unified Studio por meio de federação via função IAM. A plataforma passa a criar uma sessão de usuário única para cada pessoa que acessa de forma federada — o que resolve um problema prático importante: quando múltiplos usuários compartilham a mesma função IAM, eles não sobrescrevem mais o trabalho uns dos outros.

    Além disso, os administradores agora conseguem auditar ações individuais mesmo em cenários onde vários usuários compartilham uma única função IAM, o que melhora significativamente a rastreabilidade e a governança.

    Flexibilidade para equipes com diferentes métodos de autenticação

    Com essas atualizações, as equipes podem utilizar tanto identidade IAM quanto identidade corporativa via IAM Identity Center nos dois tipos de domínio do SageMaker Unified Studio. O resultado prático é maior flexibilidade para colaboração, independentemente de como cada membro do time realiza sua autenticação.

    Disponibilidade regional

    Os novos recursos já estão disponíveis nas seguintes regiões AWS: Ásia-Pacífico (Mumbai, Seul, Singapura, Sydney e Tóquio), Canadá (Central), Europa (Frankfurt, Irlanda, Londres, Paris e Estocolmo), América do Sul (São Paulo), Leste dos EUA (Virgínia do Norte e Ohio) e Oeste dos EUA (Oregon).

    Para aprofundar o entendimento sobre as configurações disponíveis, a AWS disponibiliza a documentação oficial do SageMaker Unified Studio.

    Fonte

    Amazon SageMaker Unified Studio adds identity and user management features (https://aws.amazon.com/about-aws/whats-new/2026/05/smus-identity-user-management/)

  • AWS Capabilities by Region agora suporta notificações de disponibilidade

    Novidade no AWS Builder Center

    A AWS anunciou a chegada das notificações de disponibilidade para o AWS Capabilities by Region, ferramenta disponível dentro do AWS Builder Center. O recurso funciona como um sistema de assinaturas que dispara alertas automáticos sempre que um serviço ou funcionalidade da AWS passa a estar disponível em uma determinada região.

    O que são as notificações de disponibilidade?

    Quem trabalha com planejamento de infraestrutura em múltiplas regiões sabe como é trabalhoso monitorar manualmente quando cada serviço chega a cada região. A novidade resolve exatamente esse problema: em vez de verificar periodicamente se um recurso está disponível onde você precisa, o próprio sistema avisa quando isso acontece.

    Com essa funcionalidade, é possível acompanhar a disponibilidade de mais de 1.500 serviços e funcionalidades distribuídos pelas 37 regiões da AWS. Isso acelera diretamente as decisões de planejamento e implantação de infraestrutura.

    Como funciona a assinatura

    A inscrição é feita diretamente pela interface do AWS Builder Center, no nível do serviço. Ao assinar um serviço, a cobertura já inclui automaticamente todas as funcionalidades associadas a ele nas regiões selecionadas — sem necessidade de configurar cada feature individualmente.

    As notificações chegam por dois canais:

    • Alertas em tempo real dentro do próprio AWS Builder Center
    • Resumo semanal por e-mail consolidando as novidades do período

    As preferências de assinatura e notificação podem ser gerenciadas em Configurações > Notificações dentro do AWS Builder Center.

    Casos de uso práticos

    A AWS destaca alguns cenários em que esse recurso é especialmente útil:

    • Monitorar o lançamento de uma funcionalidade específica em uma região-alvo
    • Acompanhar a paridade de serviços entre diferentes regiões da AWS
    • Se preparar para migrações ou expansões regionais

    Um exemplo concreto mencionado pela AWS: um arquiteto de soluções que está expandindo uma aplicação de Inteligência Artificial (IA) generativa para novas regiões pode assinar o Amazon Bedrock e receber atualizações automáticas conforme funcionalidades como Knowledge Bases, Guardrails e outras se tornarem disponíveis naquelas regiões.

    Disponibilidade e acesso

    O recurso está disponível sem custo adicional para todos os usuários globais autenticados com um Builder ID. Para ativar as notificações, basta acessar o AWS Capabilities by Region no AWS Builder Center.

    Fonte

    AWS Capabilities by Region now supports availability notifications (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-regional-planning-tool-notification)

  • Instâncias Amazon EC2 G7e chegam à região Europa (Londres)

    Novas instâncias G7e disponíveis em Londres

    A AWS anunciou a disponibilidade das instâncias Amazon EC2 G7e na região Europa (Londres). Aceleradas pelas GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition, essas instâncias chegam com desempenho de inferência até 2,3 vezes superior em comparação com as instâncias G6e — um salto relevante para equipes que trabalham com cargas de trabalho de Inteligência Artificial.

    Para quais workloads as G7e são indicadas?

    As instâncias G7e foram projetadas para atender a uma variedade de casos de uso modernos e exigentes. Entre os principais, a AWS destaca:

    • Implantação de Modelos de Linguagem de Grande Escala (LLMs)
    • Modelos de IA agêntica
    • Modelos de IA generativa multimodal
    • Modelos de IA física

    Além disso, as G7e se destacam como a opção de maior desempenho para cargas de trabalho de computação espacial e para cenários que combinam processamento gráfico e de IA simultaneamente.

    Especificações técnicas

    Do ponto de vista de hardware, as instâncias G7e entregam uma configuração robusta:

    • Até 8 GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition
    • 96 GB de memória por GPU
    • Processadores Intel Xeon de 5ª Geração
    • Suporte a até 192 CPUs virtuais (vCPUs)
    • Até 1.600 Gbps de largura de banda de rede

    As G7e também suportam o NVIDIA GPUDirect Peer to Peer (P2P), tecnologia que aumenta o desempenho em workloads que utilizam múltiplas GPUs em paralelo. Para configurações multi-GPU, há ainda suporte ao NVIDIA GPUDirect Acesso Direto à Memória Remota (RDMA) com EFA em EC2 UltraClusters, o que reduz a latência em workloads multi-nó de pequena escala.

    Regiões disponíveis e opções de compra

    As instâncias G7e já estão disponíveis nas seguintes regiões da AWS:

    • US West (Oregon)
    • US East (Norte da Virgínia e Ohio)
    • Europa (Espanha e Londres)
    • Ásia-Pacífico (Tóquio e Seul)

    Em termos de modelo de aquisição, as G7e podem ser contratadas como Instâncias Sob Demanda, Instâncias Spot ou por meio dos Savings Plans da AWS.

    Como começar

    Para provisionar as instâncias G7e, é possível utilizar o Console de Gerenciamento da AWS, a Interface de Linha de Comando da AWS (CLI) ou os SDKs da AWS. Para conhecer todos os detalhes técnicos, a AWS disponibiliza a página oficial das instâncias G7e.

    Fonte

    Amazon EC2 G7e instances now available in Europe (London) region (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-ec2-g7e-london-region/)

  • Amazon Bedrock AgentCore Memory agora suporta metadados para memória de longo prazo

    O que foi anunciado

    A AWS anunciou que o Amazon Bedrock AgentCore Memory passou a suportar metadados nos registros de Memória de Longo Prazo (LTM). Com essa novidade, agentes de inteligência artificial conseguem classificar, filtrar e recuperar memórias utilizando atributos estruturados em conjunto com a busca semântica já existente no serviço.

    Como os metadados funcionam

    A configuração de metadados gira em torno de um esquema definido diretamente no recurso de memória. Nesse esquema, é possível declarar até dez chaves indexadas por recurso, com suporte aos tipos STRING, NUMBER e STRING_LIST. Cada chave pode ter um nome, um tipo e, opcionalmente, uma lista de valores permitidos.

    Além das definições de chave, o esquema inclui instruções de extração que orientam o modelo de linguagem (LLM) sobre como gerar os metadados a partir do conteúdo das conversas. Ou seja, o próprio modelo lê os eventos de entrada e decide como aplicar os metadados aos registros de memória resultantes — sem necessidade de intervenção manual em cada interação.

    Duas formas de associar metadados

    Os metadados podem chegar aos registros de duas maneiras distintas:

    • Anexados manualmente na ingestão: o desenvolvedor define e passa os metadados junto com o evento no momento em que ele é registrado.
    • Inferidos automaticamente pelo LLM: com base nas instruções de extração configuradas no recurso de memória, o modelo processa os eventos e determina automaticamente quais metadados aplicar.

    Por que isso importa na prática

    Antes desse recurso, a recuperação de memórias dependia exclusivamente da busca semântica — útil, mas limitada quando o agente precisa de precisão cirúrgica. Com os metadados estruturados, é possível filtrar registros por atributos como número de ticket, prioridade ou data, eliminando contextos irrelevantes e tornando as respostas do agente mais precisas e relevantes.

    Pense em um agente de suporte ao cliente: ao recuperar o histórico de um atendimento específico, ele pode filtrar diretamente pelo número do chamado em vez de vasculhar semanticamente todas as interações passadas. Isso reduz ruído e melhora a qualidade das respostas geradas.

    Disponibilidade

    O suporte a metadados no Amazon Bedrock AgentCore Memory já está disponível em todas as regiões AWS onde o serviço é suportado. Para começar a explorar o recurso, a AWS disponibilizou a documentação oficial do Amazon Bedrock AgentCore Memory com os detalhes de configuração.

    Fonte

    Amazon Bedrock AgentCore Memory announces metadata for long-term memory (https://aws.amazon.com/about-aws/whats-new/2026/05/agentcore-longterm-memory-metadata)

  • Instâncias Amazon EC2 P6-B300 chegam à Região US East (N. Virginia)

    Mais uma região recebe as instâncias P6-B300

    A AWS anunciou, em 6 de maio de 2026, que as instâncias Amazon EC2 P6-B300 passaram a estar disponíveis na região US East (N. Virginia). Com isso, essa família de instâncias de alta performance para cargas de trabalho de Inteligência Artificial (IA) amplia ainda mais sua cobertura geográfica dentro da infraestrutura da AWS.

    O que são as instâncias P6-B300?

    As instâncias P6-B300 são equipadas com 8 GPUs NVIDIA Blackwell Ultra e foram projetadas para atender às demandas mais intensas de treinamento e inferência de modelos de IA de grande escala. Confira as especificações técnicas principais:

    • 2,1 TB de memória de GPU de alta largura de banda
    • 6,4 Tbps de rede EFA (Elastic Fabric Adapter)
    • 300 Gbps de throughput dedicado ENA (Elastic Network Adapter)
    • 4 TB de memória de sistema

    Como a P6-B300 se compara à P6-B200?

    Em relação à geração anterior, a P6-B200, a nova P6-B300 entrega ganhos expressivos em todas as frentes críticas para workloads de IA:

    • 2x mais largura de banda de rede
    • 1,5x mais memória de GPU
    • 1,5x mais TFLOPS de GPU (medido em FP4, sem esparsidade)

    Esses avanços se traduzem diretamente em tempos de treinamento mais rápidos e maior throughput de tokens para aplicações de IA — dois fatores decisivos para equipes que trabalham com modelos de fundação (FMs) e Modelos de Linguagem de Grande Escala (LLMs) com trilhões de parâmetros.

    Para quais casos de uso as P6-B300 são indicadas?

    Segundo a AWS, as instâncias P6-B300 são especialmente adequadas para:

    • Treinamento de modelos de fundação (FMs) de grande porte
    • Implantação de LLMs com técnicas sofisticadas de inferência
    • Workloads de IA que exigem alta capacidade de memória e largura de banda de rede elevada

    Disponibilidade e tamanho de instância

    As instâncias P6-B300 estão disponíveis exclusivamente no tamanho p6-b300.48xlarge e podem ser provisionadas nas seguintes regiões da AWS:

    • US West (Oregon)
    • AWS GovCloud (US-East)
    • US East (N. Virginia) — novidade desta semana

    Para conhecer todos os detalhes técnicos e começar a usar as instâncias P6-B300, a AWS disponibiliza a documentação completa em Amazon EC2 P6 — página oficial das instâncias.

    Fonte

    Amazon EC2 P6-B300 instances are now available in the US East (N. Virginia) Region (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-ec2-p6-b300-us-east)

  • Novo guia de conformidade disponível: ISO/IEC 42001:2023 na AWS

    A AWS disponibiliza guia prático para conformidade com a ISO/IEC 42001:2023

    A AWS acaba de lançar um novo guia de conformidade dedicado à norma ISO/IEC 42001:2023 — um padrão internacional que define requisitos para a criação e operação de um Sistema de Gestão de Inteligência Artificial, conhecido pela sigla em inglês AIMS (Artificial Intelligence Management System). O material foi desenvolvido para ajudar organizações que utilizam a nuvem AWS a estruturar sua governança de IA de forma alinhada a um dos frameworks mais reconhecidos globalmente nessa área.

    Com o crescimento acelerado do uso de cargas de trabalho de IA e IA generativa na nuvem, adotar padrões como a ISO/IEC 42001:2023 tornou-se um passo relevante para fortalecer a governança, o gerenciamento de riscos e as práticas de IA responsável dentro das organizações. O novo guia da AWS chega justamente para preencher essa lacuna prática: traduzir os requisitos da norma em ações concretas dentro do ambiente AWS.

    Para quem é este guia?

    O documento foi pensado para um público técnico e estratégico ao mesmo tempo. Entre os perfis contemplados estão:

    • Arquitetos de nuvem
    • Engenheiros de IA/ML (Machine Learning)
    • Equipes de segurança
    • Líderes de conformidade
    • Profissionais de DevOps

    Em outras palavras, qualquer pessoa envolvida na implementação, operação ou auditoria de sistemas de IA na AWS pode se beneficiar do conteúdo.

    O que o guia cobre?

    O material da AWS oferece uma visão abrangente de como integrar os serviços da plataforma a um AIMS em conformidade com a ISO 42001:2023. A seguir, os principais blocos de conteúdo presentes no guia:

    Visão geral da norma ISO/IEC 42001:2023

    O guia explica o que é a ISO/IEC 42001:2023, como ela se relaciona com a família mais ampla de padrões ISO voltados para IA, e o que são seus Anexos. Essa introdução é especialmente útil para equipes que ainda estão se familiarizando com o framework.

    Integração com a arquitetura de segurança da AWS e o Modelo de Responsabilidade Compartilhada

    Um ponto central do guia é a aplicação do Modelo de Responsabilidade Compartilhada da AWS no contexto de cargas de trabalho de IA. Embora a AWS forneça uma infraestrutura de nuvem segura e em conformidade, com capacidades nativas de IA responsável, as organizações continuam responsáveis por definir o escopo do seu AIMS, implementar os controles necessários e demonstrar conformidade durante as auditorias de certificação.

    Contexto e escopo para estabelecer um AIMS na AWS

    O guia orienta sobre como definir os limites dos sistemas de IA dentro do ambiente AWS — uma etapa fundamental para qualquer organização que queira estabelecer formalmente seu AIMS.

    Mapeamento das cláusulas 4 a 10 da ISO 42001:2023 para serviços AWS

    Esta é uma das partes mais práticas do documento. O guia mapeia cada cláusula da norma — que abrange contexto organizacional, liderança, planejamento, suporte, operação, avaliação de desempenho e melhoria — para serviços e capacidades arquiteturais específicos da AWS. Isso facilita muito a vida de quem precisa implementar os controles no dia a dia.

    Orientações para os controles do Anexo A (A.2 a A.10)

    O guia também detalha como implementar os controles específicos do Anexo A da norma, que incluem temas como:

    • Políticas de IA
    • Organização interna
    • Recursos para sistemas de IA
    • Avaliações de impacto
    • Gestão do ciclo de vida de sistemas de IA
    • Governança de dados
    • Transparência para partes interessadas
    • Uso de sistemas de IA
    • Relacionamento com terceiros e clientes

    Coleta de evidências e preparação para auditorias

    O material traz recomendações práticas para coleta de evidências, documentação e preparação para auditorias de certificação utilizando ferramentas nativas da AWS. O objetivo é ajudar as equipes a manterem visibilidade sobre seus sistemas de IA, melhorarem a consistência operacional e chegarem prontas para uma auditoria.

    Automação e infraestrutura como código para conformidade com IA

    Por fim, o guia apresenta boas práticas para operacionalizar as atividades de conformidade de IA por meio de automação e infraestrutura como código (IaC — Infrastructure as Code), reduzindo o esforço manual e aumentando a rastreabilidade.

    Como usar o guia na prática

    A AWS recomenda que as organizações utilizem o guia para mapear as cláusulas da ISO 42001 e os controles do Anexo A para o seu ambiente AWS, automatizar a coleta de evidências e reduzir o esforço envolvido na preparação para uma auditoria de certificação.

    O Guia de Conformidade ISO/IEC 42001:2023 na AWS está disponível para download gratuitamente. Para organizações que precisam de suporte adicional, a AWS também disponibiliza o AWS Security Assurance Services como canal de contato para assistência especializada.

    Por que isso importa para o mercado brasileiro?

    Para as equipes brasileiras que trabalham com IA na nuvem, este guia representa um recurso valioso — especialmente em um momento em que a governança de IA começa a ganhar atenção regulatória e estratégica também no Brasil. Ter um material estruturado que conecta um padrão internacional reconhecido como a ISO/IEC 42001:2023 aos serviços concretos da AWS facilita enormemente a jornada de conformidade, seja para obter uma certificação formal ou simplesmente para amadurecer as práticas internas de IA responsável.

    Fonte

    New compliance guide available: ISO/IEC 42001:2023 on AWS (https://aws.amazon.com/blogs/security/new-compliance-guide-available-iso-iec-420012023-on-aws/)

  • MLflow v3.10 chega ao Amazon SageMaker AI com melhorias para IA generativa

    O que muda com o MLflow 3.10 no SageMaker

    A AWS anunciou que os Amazon SageMaker AI MLflow Apps passam a suportar o MLflow na versão 3.10. A atualização expande as capacidades de desenvolvimento de IA generativa e torna o rastreamento de experimentos mais completo e integrado ao ciclo de produção.

    A nova versão se apoia nas bases estabelecidas pelo MLflow 3.0 — especialmente nas funcionalidades de rastreamento e observabilidade — e avança com foco em fluxos de trabalho agênticos e aplicações de IA generativa.

    Novidades do MLflow 3.10

    IA generativa e rastreamento de fluxos complexos

    Um dos destaques desta versão é o rastreamento aprimorado para fluxos de trabalho com múltiplas interações (multi-turn workflows), algo comum em aplicações que utilizam agentes de linguagem. A integração com frameworks e bibliotecas populares de Modelos de Linguagem de Grande Escala (LLM) também foi aprimorada, assim como o registro de interações e invocações de modelos generativos.

    Nova API de avaliação para IA generativa

    A avaliação de modelos recebeu uma atualização significativa com a chegada da API mlflow.genai.evaluation(). Ela oferece uma interface programática para medir e acompanhar sistematicamente a qualidade de aplicações de IA generativa ao longo de todo o ciclo de desenvolvimento até a produção. A API inclui métricas integradas que cobrem relevância, fidelidade, correção e segurança — todas compatíveis com os fluxos de trabalho do SageMaker AI.

    Observabilidade e dashboards

    As melhorias de observabilidade incluem filtragem e busca de rastreamentos com maior granularidade, além de captura mais rica de metadados para depuração e análise de causa raiz. Os dashboards de desempenho pré-configurados exibem métricas de carga de trabalho — distribuições de latência, contagem de requisições, pontuações de qualidade e uso de tokens — sem necessidade de configuração manual de gráficos. Isso dá às equipes em produção uma visão clara dos custos operacionais.

    Além disso, os workspaces do MLflow oferecem uma forma estruturada de organizar artefatos entre times e projetos, facilitando a governança em escala.

    Como começar com o SageMaker AI MLflow App v3.10

    Para novos usuários, criar um SageMaker AI MLflow App é direto: basta acessar o console do SageMaker Studio, o Interface de Linha de Comando da AWS (AWS CLI) ou a API. A configuração padrão já provisiona automaticamente o MLflow 3.10, dando acesso imediato a todos os novos recursos.

    Pré-requisitos

    Para começar, são necessários:

    Com o domínio em mãos, basta acessar o console do Amazon SageMaker AI Studio, selecionar a aplicação MLflow e clicar em Create MLflow App, informando um nome para a aplicação. O papel do Gerenciamento de Identidade e Acesso da AWS (IAM) e o bucket do Amazon Simple Storage Service (Amazon S3) já vêm pré-configurados com os padrões do domínio do SageMaker AI Studio, sendo necessário ajustá-los apenas em configurações avançadas, se necessário.

    Após a criação, o sistema fornece um Nome de Recurso da Amazon (ARN) do MLflow App, que será usado para conectar o ambiente de desenvolvimento ao rastreador.

    Instalação dos pacotes

    Para começar a rastrear experimentos, é necessário instalar o MLflow e o plugin SageMaker MLflow no ambiente de trabalho. Os ambientes suportados incluem o SageMaker Studio managed Jupyter Lab, o SageMaker Studio Code Editor, um ambiente de desenvolvimento integrado (IDE) local ou qualquer outro ambiente compatível com os SageMaker AI MLflow Apps.

    A instalação via pip é feita com o seguinte comando:

    pip install mlflow==3.10.1 sagemaker-mlflow==0.3.0

    Conectando ao SageMaker AI MLflow App

    Para conectar o código ao app recém-criado e começar a registrar experimentos, parâmetros e modelos, basta substituir o Nome de Recurso da Amazon (ARN) pelo ARN do seu MLflow App no trecho abaixo:

    import mlflow

# Connect to your SageMaker MLflow App
mlflow_app_arn = "<your-mlflow-app-arn>"
mlflow.set_tracking_uri(mlflow_app_arn)

# Set your experiment
mlflow.set_experiment("your_genai_experiment")

# Your existing code continues to work with enhanced capabilities
# New features are automatically available

    Migração de ambientes existentes

    Quem já possui um MLflow Tracking Server ou App hospedado no SageMaker ou em outro ambiente pode migrar para um novo app na versão 3.10 seguindo as instruções do post Migrate MLflow tracking servers to Amazon SageMaker AI with serverless MLflow.

    Disponibilidade e próximos passos

    O MLflow v3.10 também está disponível no Amazon SageMaker AI serverless model customization e no SageMaker Unified Studio, ampliando as opções de uso em diferentes fluxos de trabalho.

    Para começar, basta acessar o Amazon SageMaker AI Studio e criar o primeiro MLflow App. Feedbacks podem ser enviados pelo AWS re:Post para SageMaker ou pelos canais habituais de suporte AWS.

    Fonte

    Streamlining generative AI development with MLflow v3.10 on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/streamlining-generative-ai-development-with-mlflow-v3-10-on-amazon-sagemaker-ai/)

  • Como proteger agentes de IA com Amazon Bedrock AgentCore Identity no Amazon ECS

    Agentes de IA em produção precisam de identidade segura

    Colocar agentes de IA em produção vai muito além de fazer o modelo responder corretamente. Um dos desafios mais críticos é garantir que o agente acesse serviços externos de forma segura e com o escopo certo. A AWS endereça exatamente esse problema com o Amazon Bedrock AgentCore Identity, um serviço disponível de forma independente que gerencia como agentes de IA acessam recursos externos — seja rodando no Amazon ECS, no Amazon EKS, no AWS Lambda ou até em ambientes on-premises.

    Um post anterior cobriu o gerenciamento de credenciais com o AgentCore Identity. Agora, a AWS foi além e publicou uma implementação completa de como usar o serviço em ambientes como o ECS, respondendo duas perguntas práticas: como construir um endpoint de Session Binding gerenciado pela própria aplicação, e como controlar o ciclo de vida dos tokens de acesso do workload.

    OAuth 2.0 e OIDC: a base da solução

    A solução utiliza dois protocolos complementares: OAuth 2.0 (RFC 6749) e Protocolo de Conexão OpenID (OIDC). O OIDC cuida da autenticação — ou seja, confirma quem é o usuário. O OAuth 2.0 cuida da autorização — ou seja, o que esse usuário pode fazer. O foco aqui é no fluxo Authorization Code Grant, indicado para workloads que precisam agir em nome de usuários reais.

    Nesse fluxo, o usuário se autentica com um provedor de identidade e concede permissão para o agente acessar recursos específicos em seu nome. A aplicação troca o código de autorização resultante por um token de acesso com escopo definido, que o AgentCore Identity armazena no seu cofre de tokens. Como cada token está vinculado a uma identidade de usuário específica com consentimento explícito, a solução mantém uma cadeia auditável desde a autenticação até a ação do agente.

    O Authorization Code Grant é especialmente adequado para workloads agênticos porque oferece três garantias importantes:

    • Consentimento do usuário antes que o agente possa agir
    • Session binding que verifica se o usuário que iniciou a requisição é o mesmo que concedeu o consentimento
    • Delegação com escopo que limita o agente apenas às permissões aprovadas pelo usuário

    Callback URL vs. Session Binding URL

    Um ponto que costuma gerar confusão são as duas URLs envolvidas no fluxo:

    • Callback URL: gerada automaticamente ao criar um cliente OAuth no AgentCore Identity. Aponta para o próprio AgentCore Identity e precisa ser registrada no servidor de autorização como destino do redirecionamento após a autenticação do usuário.
    • Session Binding URL: aponta para um serviço gerenciado pelo cliente que completa o session binding entre o usuário autenticado e o fluxo OAuth. Esse endpoint é implementado e hospedado pelo próprio cliente.

    Arquitetura da solução no Amazon ECS

    A solução implanta dois serviços no Amazon ECS atrás de um Application Load Balancer (ALB). O primeiro é o Agentic Workload, que executa o agente de IA e processa as requisições dos usuários. O segundo é o Session Binding Service, responsável por processar os callbacks OAuth e vincular as sessões de usuário aos tokens de acesso de terceiros. O código-fonte completo e os pré-requisitos estão disponíveis no repositório GitHub que acompanha o post.

    O walkthrough usa o Microsoft Entra ID como provedor de identidade, mas qualquer provedor compatível com OIDC funciona. A arquitetura inclui os seguintes componentes de suporte:

    • Tráfego criptografado com HTTPS via AWS Certificate Manager
    • Roteamento DNS com Amazon Route 53
    • Logs capturados pelo Amazon CloudWatch e armazenados em bucket S3
    • Imagens de container no Amazon ECR
    • Regras básicas do AWS WAF no load balancer para proteção contra exploits comuns
    • Chave gerenciada pelo cliente no AWS KMS para criptografia de dados

    O fluxo completo do Authorization Code Grant

    O diagrama de sequência da solução mostra como a identidade de workload do AgentCore Identity, os tokens de acesso de workload e o provedor de credenciais OAuth 2.0 trabalham juntos para entregar tokens OAuth ao agente em nome do usuário. O fluxo parte do pressuposto de que o usuário ainda não autorizou o agente, ou seja, não há token válido no Token Vault do AgentCore Identity.

    O fluxo funciona assim:

    • O usuário autenticado envia uma requisição ao workload agêntico.
    • O workload extrai o ID do usuário do campo sub no JWT assinado pelo ALB (header x-amzn-oidc-data).
    • O workload chama a API GetWorkloadAccessTokenForUserId, passando o userId e o workloadName, para obter um token de acesso de workload com escopo para aquele usuário.
    • Em seguida, chama a API GetResourceOauth2Token, passando o token de workload, o nome do provedor OAuth 2.0, a Session Binding URL (parâmetro callbackUrl) e os escopos necessários.
    • Como não há token válido, o AgentCore Identity cria um sessionURI que rastreia o estado do fluxo de autorização e retorna uma URL de autorização para o workload.
    • O workload apresenta essa URL ao usuário, que clica e concede permissão na tela de consentimento do provedor.
    • O servidor de autorização envia o código de autorização ao AgentCore Identity, que redireciona o usuário para o Session Binding Service via Session Binding URL com o sessionURI anexado.
    • O Session Binding Service chama a API CompleteResourceTokenAuth com o sessionURI e o ID do usuário extraído do JWT, vinculando a autorização à sessão correta.
    • O AgentCore Identity troca o código de autorização com o servidor de autorização, recebe o token OAuth2, armazena no Token Vault e retorna sucesso ao Session Binding Service.

    Em requisições subsequentes, o comportamento depende das credenciais emitidas pelo servidor de autorização. Quando há um refresh token disponível — como no GitHub com expiração de token habilitada — o AgentCore Identity o usa automaticamente para renovar o access token sem precisar envolver o usuário novamente. Se não houver refresh token e o access token expirar, o usuário será solicitado a autorizar novamente. Tokens revogados pelo provedor podem ser tratados com o parâmetro forceAuthentication: true, que força um novo fluxo de autenticação.

    Por que o session binding é crítico para segurança

    O session binding protege contra dois tipos de ataque:

    • Falsificação de Requisição entre Sites (CSRF): um atacante tenta vincular seu próprio token OAuth à identidade da vítima, fazendo o agente da vítima acessar recursos do atacante sem que ela perceba — o que possibilita exfiltração de dados e injeção de conteúdo.
    • Browser Swapping Attack (ataque de troca de navegador): um atacante engana a vítima para que ela dê consentimento em nome do atacante, vinculando o token OAuth da vítima à identidade do atacante e concedendo acesso direto aos recursos da vítima.

    O session binding previne ambos ao garantir que o ID do usuário no workload agêntico seja o mesmo no Session Binding Service, com ambas as identidades verificadas criptograficamente pela cadeia de autenticação. O AgentCore Identity também suporta o parâmetro opcional customState na API GetResourceOauth2Token para passar um nonce aleatório criptograficamente seguro, protegendo o endpoint de callback contra ataques CSRF conforme recomendado pela especificação OAuth 2.0.

    Por que usar GetWorkloadAccessTokenForUserId com ALB e Microsoft Entra ID

    A API recomendada para obter um token de acesso de workload é a GetWorkloadAccessTokenForJWT, mas essa solução usa a GetWorkloadAccessTokenForUserId. O motivo é uma incompatibilidade técnica entre o fluxo OIDC do ALB e o Microsoft Entra ID.

    A GetWorkloadAccessTokenForJWT exige um JWT dinamicamente validável, com assinatura verificável em runtime e claim aud correspondente à aplicação. Para obter esse token do Entra ID, é necessário incluir o Application ID no escopo da requisição OIDC — veja a documentação do AgentCore para Microsoft Inbound. O problema é que isso é incompatível com o fluxo OIDC do ALB.

    Como parte do handshake OIDC (descrito na documentação de OIDC do ALB), o ALB envia o access token para o endpoint UserInfo do Entra para recuperar os claims do usuário autenticado. Esse endpoint UserInfo fica no Microsoft Graph (https://graph.microsoft.com/oidc/userinfo) e só aceita tokens com escopo para o Microsoft Graph. Quando o Application ID é incluído no escopo, o access token resultante tem a aplicação como audiência — o endpoint UserInfo rejeita com 401 e o ALB retorna 561. Se o Application ID for removido do escopo, o Entra define a audiência do access token como Microsoft Graph, o handshake do ALB funciona, mas o JWT resultante não pode ser validado dinamicamente pelo AgentCore e é inutilizável com a GetWorkloadAccessTokenForJWT.

    A solução adotada: o ALB completa o handshake usando o token com escopo para o Graph e injeta um JWT assinado pelo próprio ALB no header x-amzn-oidc-data com os claims do usuário, incluindo o sub. Esse JWT é validado usando as chaves de assinatura publicadas pela AWS, o sub é extraído e passado para a GetWorkloadAccessTokenForUserId.

    Implementação: os principais trechos de código

    O código completo está disponível no repositório GitHub. Abaixo estão os trechos mais relevantes.

    Obtendo o token de acesso de workload

    O servidor extrai o ID do usuário do claim sub do JWT e solicita um token de acesso de workload ao AgentCore Identity. Em seguida, usa esse token, o ID da sessão e a mensagem para invocar o agente em nome do usuário:

    @router.post("/invocations")
async def invoke_agent(
    request: InvocationRequest,
    user_id: str = Depends(get_current_user),
    settings: Settings = Depends(get_settings),
    agent_service: AgentService = Depends(get_agent_service),
) -> StreamingResponse:
    """Invoke agent with streaming response."""
    try:
        agentcore = boto3.client("bedrock-agentcore", region_name=settings.identity_aws_region)
        response = agentcore.get_workload_access_token_for_user_id(
            workloadName=settings.workload_identity_name,
            userId=user_id
        )
        workload_access_token = response["workloadAccessToken"]
        return StreamingResponse(
            content=agent_service.stream_response(
                user_message=request.user_message,
                session_id=request.session_id,
                user_id=user_id,
                workload_access_token=workload_access_token,
            ),
            media_type="text/event-stream",
        )

    Solicitando o token de acesso OAuth

    O servidor usa o decorator require_access_token do AgentCore SDK para recuperar o token OAuth 2.0 (veja como obter um token de acesso OAuth 2.0). A implementação modifica o decorator para aceitar o token de workload como parâmetro explícito, dando controle direto sobre o ciclo de vida do token enquanto preserva a lógica de recuperação e tratamento de erros do SDK:

    def requires_access_token(
    *,
    provider_name: str,
    scopes: list[str],
    auth_flow: Literal["M2M", "USER_FEDERATION"],
    workload_access_token: str | None = None,
    session_binding_url: str | None = None,
    on_auth_url: Callable[[str], Any] | None = None,
    force_authentication: bool = False,
    token_poller: TokenPoller | None = None,
    custom_state: str | None = None,
    custom_parameters: dict[str, str] | None = None,
    into: str = "access_token",
    region: str | None = None,
) -> Callable[[Callable[..., Any]], Callable[..., Any]]:
    def decorator(func: Callable[..., Any]) -> Callable[..., Any]:
        client = IdentityClient(region)
        @wraps(func)
        async def wrapper(*args: Any, **kwargs: Any) -> Any:
            try:
                if not workload_access_token:
                    raise ValueError("workload_access_token is required")
                token = await client.get_token(
                    provider_name=provider_name,
                    agent_identity_token=workload_access_token,
                    scopes=scopes,
                    auth_flow=auth_flow,
                    callback_url=session_binding_url,
                    on_auth_url=on_auth_url,
                    force_authentication=force_authentication,
                    token_poller=token_poller,
                    custom_state=custom_state,
                    custom_parameters=custom_parameters,
                )
                kwargs[into] = token
                return await func(*args, **kwargs)
            except Exception:
                logger.exception("Error in requires_access_token decorator")
                raise
        return wrapper
    return decorator

    Três decisões de design importantes

    A implementação das ferramentas do agente destaca três escolhas de design relevantes:

    • Pydantic BaseModel como tipos de retorno: as classes GitHubUser e GitHubProject são subclasses de BaseModel. O Strands deriva automaticamente descrições de ferramentas a partir do schema e das docstrings, dando ao modelo de linguagem contexto estruturado sobre cada ferramenta.
    • Tratamento de erros consistente com o tipo: quando não há token e o AgentCore Identity retorna uma URL de autorização, o callback on_auth_url lança um AuthorizationRequiredError em vez de retornar uma string — uma ferramenta que declara GitHubUser como tipo de retorno não pode retornar uma URL. A camada de streaming do agente captura a exceção e apresenta a URL ao usuário.
    • Escopos por ferramenta: cada ferramenta declara apenas os escopos OAuth que precisa, mantendo o consentimento alinhado ao princípio do menor privilégio.

    Completando o session binding

    No Session Binding Service, quando o usuário autoriza o acesso no GitHub, o GitHub redireciona para {session_binding_url}?session_id={session_id}, onde session_id corresponde ao sessionURI que o AgentCore Identity incluiu na URL de autorização original:

    @router.get("/session-binding", response_class=HTMLResponse)
async def oauth_session_binding(
    session_id: str = Query(..., description="Session URI from AgentCore Identity"),
    user_id: str = Depends(get_current_user),
    settings: Settings = Depends(get_settings),
) -> HTMLResponse:
    """Handle OAuth2 session binding from external providers."""
    client = boto3.client("bedrock-agentcore", region_name=settings.identity_region)
    try:
        client.complete_resource_token_auth(
            sessionUri=session_id,
            userIdentifier={"userId": user_id},
        )

    O serviço extrai o ID do usuário do claim sub no header x-amzn-oidc-data, garantindo identidade consistente ao longo de todo o fluxo. Em seguida, chama complete_resource_token_auth com o sessionURI e o ID do usuário, vinculando o token de acesso resultante à sessão correta.

    Limpeza dos recursos

    Para evitar cobranças desnecessárias, é recomendável excluir os recursos criados pela solução quando não forem mais necessários. As instruções estão disponíveis no guia de limpeza dos recursos.

    Próximos passos

    O padrão apresentado funciona em diferentes plataformas de computação — ECS, EKS, Lambda ou fora da AWS — e se estende além do GitHub para outros serviços compatíveis com OAuth 2.0, como Jira, Salesforce ou Google Calendar. Para aprofundar:

    Fonte

    Secure AI agents with Amazon Bedrock AgentCore Identity on Amazon ECS (https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-amazon-bedrock-agentcore-identity-on-amazon-ecs/)

  • Ações em Nível de SO no Amazon Bedrock AgentCore Browser

    O problema: a fronteira invisível da automação web

    Agentes de IA que automatizam fluxos de trabalho em navegadores operam dentro da camada web — o Modelo de Objeto de Documento (DOM) exposto pelo Playwright e pelo Protocolo Chrome DevTools (CDP). O AgentCore Browser já fornecia um ambiente de navegador seguro e isolado para isso, funcionando bem na grande maioria dos cenários: navegar páginas, preencher formulários, clicar em elementos e extrair conteúdo.

    Mas essa camada web tem um limite rígido. Qualquer coisa que o sistema operacional renderiza — caixas de diálogo nativas, prompts de segurança, seletores de certificado, menus de contexto, até as configurações do próprio Chrome — fica completamente fora do DOM. O CDP não consegue enxergar esses elementos, e o Playwright não consegue interagir com eles.

    Os exemplos práticos deixam o problema bem claro:

    • Quando uma aplicação web chama window.print() e um diálogo de impressão do sistema aparece, o Playwright não tem DOM para interagir.
    • Quando um fluxo de trabalho exige um atalho de teclado ou um menu de contexto acionado com o botão direito, o CDP não tem mecanismo para emitir esses comandos no nível do SO.
    • Quando uma sessão encontra um diálogo de privacidade do macOS, um prompt do Windows Security ou um seletor de certificado, esses elementos são invisíveis para a camada de automação web.

    Esses cenários costumam aparecer em produção — acionados por estados específicos da aplicação, configurações do SO ou permissões de usuário — e não em ambientes de teste, onde o conteúdo web é previsível o suficiente para ser validado. O problema se agrava ainda mais para agentes com visão computacional: a arquitetura captura um screenshot, envia para um modelo, recebe coordenadas ou instruções de volta e executa. Esse ciclo funciona bem para conteúdo web, mas quebra no momento em que uma interface nativa aparece. O agente consegue ver o que precisa fazer, mas não tem como agir.

    A solução: OS Level Actions para o AgentCore Browser

    A AWS anunciou as OS Level Actions para o AgentCore Browser. Essa nova capacidade desbloqueia esses cenários ao expor controle direto do SO por meio da API InvokeBrowser, permitindo que agentes interajam com qualquer conteúdo visível na tela — não apenas o que está acessível pela camada web do navegador.

    Ao combinar screenshots do desktop completo com controle de mouse e teclado no nível do SO, os agentes passam a conseguir observar interfaces nativas, raciocinar sobre elas e agir dentro da mesma sessão.

    Como as OS Level Actions funcionam

    As OS Level Actions estão disponíveis para configurações de navegador novas e existentes, sem necessidade de configuração adicional. Após uma sessão estar ativa, as ações são disparadas pela API InvokeBrowser. Cada chamada carrega exatamente uma ação, identificada pelo seu tipo e argumentos, e retorna um status SUCCESS ou FAILED. A sessão ativa é identificada pelo cabeçalho x-amzn-browser-session-id, que vincula cada ação em nível de SO à sessão de navegador correta.

    O padrão de interação esperado é um ciclo de ação → screenshot → reação:

    • O agente envia uma ação — clique de mouse, tecla pressionada ou atalho — usando o InvokeBrowser.
    • O AgentCore executa a ação no desktop completo do SO e retorna SUCCESS ou FAILED.
    • O agente solicita um screenshot para observar o estado atual da tela.
    • O AgentCore captura o desktop completo — incluindo caixas de diálogo nativas, modais do SO e elementos fora da janela do navegador — e retorna uma imagem PNG codificada em base64.
    • O agente raciocina sobre o screenshot, enviando-o a um modelo de visão para determinar o que aconteceu e o que fazer a seguir.
    • O agente envia a próxima ação com base no que observou, continuando o ciclo.

    Ações suportadas

    As OS Level Actions são organizadas em três categorias: controle de mouse, entrada de teclado e captura visual. Ao todo, são oito ações com seus respectivos campos e restrições.

    Ações de mouse

    As ações de mouse cobrem toda a gama de interações com o ponteiro: clicar, mover, arrastar e rolar.

    • mouseClick: os campos de coordenadas são opcionais. Se omitidos, o clique ocorre na posição atual do cursor, com botão esquerdo e clique único. O parâmetro clickCount aceita valores de 1 a 10.
    • mouseMove: move o cursor para as coordenadas especificadas.
    • mouseDrag: exige as quatro coordenadas (início e fim). O botão padrão é o esquerdo.
    • mouseScroll: aceita posição e valores delta para ambos os eixos. deltaY negativo rola para baixo; o intervalo aceito vai de -1000 a 1000.

    Um menu de contexto acionado com o botão direito, por exemplo, é um único mouseClick com o botão definido como RIGHT nas coordenadas alvo. Vale observar que alguns itens de menu de contexto podem não funcionar como esperado por conta do ambiente virtualizado em que a sessão de navegador roda.

    Ações de teclado

    As três ações de teclado cobrem diferentes níveis de entrada:

    • keyType: para digitar texto. Envia caracteres diretamente e aceita strings de até 10.000 caracteres.
    • keyPress: para teclas individuais que precisam ser pressionadas repetidamente — como tab para avançar por campos de formulário ou escape para fechar um modal. O parâmetro presses aceita de 1 a 100, com padrão 1.
    • keyShortcut: para combinações de teclas — passe um array com os nomes das teclas e o AgentCore as pressiona simultaneamente. Aceita até cinco teclas. Os nomes das teclas devem ser em minúsculas.

    As teclas suportadas incluem caracteres únicos (a–z, 0–9) e teclas nomeadas como enter, tab, space, backspace, delete, escape, ctrl, alt e shift. Para selecionar todo o texto, por exemplo, usa-se keyShortcut com ["ctrl", "a"]:

    {
  "action": {
    "keyShortcut": {
      "keys": ["ctrl", "a"]
    }
  }
}

    Screenshot

    A ação de screenshot captura o desktop completo do SO e retorna uma imagem PNG codificada em base64 na resposta. É a única ação que retorna dados — as demais retornam apenas um status (SUCCESS ou FAILED) e um campo de erro em caso de falha.

    {
  "action": {
    "screenshot": {
      "format": "PNG"
    }
  }
}

    Como começar: passo a passo prático

    Os exemplos a seguir percorrem o ciclo ação → screenshot → reação, acompanhando o notebook de referência. Para o notebook completo com as oito ações demonstradas de ponta a ponta, vale começar por lá.

    Configurar clientes e criar um navegador

    São necessários dois clientes: um de plano de controle (bedrock-agentcore-control) para gerenciar recursos de navegador, e um de plano de dados (bedrock-agentcore) para disparar ações durante uma sessão.

    import boto3
import time

browser_boto3 = boto3.client('bedrock-agentcore-control', region_name='us-west-2')
BROWSER_NAME = "browser_with_os_actions"

    Antes de iniciar uma sessão, é necessário um perfil de execução do Gerenciamento de Identidade e Acesso da AWS (IAM) e um recurso de navegador. O perfil de execução requer as permissões bedrock-agentcore:InvokeBrowser, bedrock-agentcore:StartBrowserSession e bedrock-agentcore:StopBrowserSession. O notebook de referência inclui um helper que cria esse perfil automaticamente:

    from helpers.utils import create_agentcore_execution_role, SAMPLE_ROLE_NAME

execution_role_arn = create_agentcore_execution_role(SAMPLE_ROLE_NAME)

    Com o perfil criado, cria-se um navegador personalizado:

    created_browser = browser_boto3.create_browser(
    name=BROWSER_NAME,
    executionRoleArn=execution_role_arn,
    networkConfiguration={
        'networkMode': 'PUBLIC'
    }
)
browser_id = created_browser['browserId']
print(f"Browser ID: {browser_id}")

    Iniciar uma sessão de navegador

    Com o recurso de navegador criado, inicia-se uma sessão. O viewPort define a resolução da tela — isso determina o espaço de coordenadas para ações de mouse e as dimensões dos screenshots capturados. O sessionTimeoutSeconds controla por quanto tempo a sessão permanece ativa antes de ser encerrada automaticamente.

    from helpers.browser import get_credentials, invoke, start_session, stop_session

creds, default_region = get_credentials()
BEDROCK_AGENTCORE_DP_ENDPOINT = f"https://bedrock-agentcore.{default_region}.amazonaws.com/"

sid = start_session(BEDROCK_AGENTCORE_DP_ENDPOINT, browser_id, region=default_region, credentials=creds)

# Aguarda a inicialização da sessão — ajuste conforme necessário para seu ambiente
time.sleep(3)

    Invocar uma ação em nível de SO

    Com a sessão em execução, as ações em nível de SO são disparadas pelo helper invoke. Cada chamada recebe uma única ação — neste caso, um clique esquerdo nas coordenadas (600, 370) da tela:

    r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"mouseClick": {"x": 600, "y": 370, "button": "LEFT"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
print(f"Mouse click status: {r.status_code}, action: {r.json()['result']}")

    A resposta indica se a ação foi bem-sucedida ou falhou. As coordenadas mapeiam para pixels da tela — se o viewport da sessão for 1920×1080, os valores válidos de x vão de 0 a 1919 e de y de 0 a 1079. Coordenadas fora das dimensões da tela retornam uma ValidationException.

    Capturar um screenshot

    Após cada ação, o agente precisa observar o que aconteceu. A ação de screenshot captura o desktop completo e retorna a imagem como PNG codificado em base64:

    import base64
from IPython.display import Image, display

r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"screenshot": {"format": "PNG"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
img_bytes = base64.b64decode(r.json()['result']['screenshot']['data'])
display(Image(img_bytes))

    Essa é a etapa de observação no ciclo. O agente envia o screenshot para um modelo de visão, que raciocina sobre o que está na tela e retorna a próxima ação a ser tomada. O ciclo se repete até o fluxo de trabalho ser concluído.

    Juntando tudo: descartando um diálogo de impressão

    Aqui está o ciclo ação → screenshot → reação na prática. Suponha que o agente navegue até uma página que aciona window.print() e um diálogo de impressão nativo apareça. O agente não consegue interagir com ele via CDP, mas consegue com as OS Level Actions.

    Primeiro, o agente captura um screenshot para ver o estado atual da tela:

    r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"screenshot": {"format": "PNG"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
# Envia o screenshot para um modelo de visão para identificar o diálogo e localizar o botão Cancelar.
# A integração com o modelo de visão depende da arquitetura do seu agente — veja a API
# InvokeModel do Bedrock para enviar imagens ao Claude ou outros modelos.
# O modelo retorna coordenadas, ex.: {"x": 410, "y": 535}

    O modelo de visão identifica o diálogo de impressão e retorna as coordenadas do botão Cancelar. O agente o seleciona:

    r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"mouseClick": {"x": 410, "y": 535, "button": "LEFT"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
print(f"Click status: {r.status_code}, action: {r.json()['result']}")

    O agente captura outro screenshot para confirmar que o diálogo foi fechado, e o fluxo de trabalho continua.

    Encerrar a sessão e limpar recursos

    Quando o fluxo de trabalho termina, encerra-se a sessão e limpam-se os recursos:

    stop_session(BEDROCK_AGENTCORE_DP_ENDPOINT, sid, browser_id, region=default_region, credentials=creds)

    Para deletar o recurso de navegador e o perfil IAM:

    browser_boto3.delete_browser(browserId=browser_id)
print(f"Browser {browser_id} deleted")

from helpers.utils import delete_agentcore_execution_role, SAMPLE_ROLE_NAME
delete_agentcore_execution_role(SAMPLE_ROLE_NAME)

    O notebook de referência percorre as oito ações suportadas com uma sessão de navegador ao vivo, incluindo arrastar com o mouse, rolar, entrada de teclado e combinações de atalhos.

    Conclusão

    Quando a AWS lançou o Amazon Bedrock AgentCore Browser, ele ofereceu aos agentes de IA um ambiente de navegador totalmente gerenciado e baseado em nuvem para interagir com sites — navegando páginas, extraindo conteúdo e automatizando fluxos de trabalho em escala por meio do Playwright e do CDP.

    As OS Level Actions estendem essa capacidade além da camada web para elementos de interface visíveis na tela. Caixas de diálogo nativas, prompts de segurança, atalhos de teclado e elementos do próprio navegador deixam de ser bloqueadores. Os agentes agora conseguem observar, raciocinar e agir sobre o desktop completo do SO dentro da mesma sessão.

    Combinadas com as capacidades existentes do AgentCore Browser — como entendimento visual e integração com frameworks como Playwright e Amazon Nova Act — as OS Level Actions fecham a última lacuna na cobertura de automação de navegadores.

    Para começar a construir:

    Fonte

    Introducing OS Level Actions in Amazon Bedrock AgentCore Browser (https://aws.amazon.com/blogs/machine-learning/introducing-os-level-actions-in-amazon-bedrock-agentcore-browser/)