A AWS anunciou o Amazon GuardDuty AI Protection, uma expansão do serviço Amazon GuardDuty que estende a detecção de ameaças para cargas de trabalho de inteligência artificial — com suporte inicial ao Amazon Bedrock e ao Amazon SageMaker.
O movimento faz sentido: à medida que as organizações adotam IA em ritmo acelerado, as equipes de segurança frequentemente não têm visibilidade adequada sobre ameaças específicas a esses ambientes. O GuardDuty AI Protection chega para preencher exatamente essa lacuna.
Quais ameaças ele detecta
O serviço monitora continuamente as cargas de trabalho de IA e é capaz de identificar três categorias principais de atividade suspeita:
Padrões anômalos de invocação de modelos: comportamentos fora do normal no uso dos modelos de IA, que podem indicar acesso não autorizado ou uso indevido.
Ataques de consumo de recursos (cost harvesting): quando agentes maliciosos forçam os recursos de IA a consumir tempo excessivo de GPU e tokens, gerando custos elevados para a conta da vítima.
Tentativas de prompt injection: ataques que tentam manipular o comportamento dos modelos por meio de entradas maliciosas, detectados por meio da integração com o Amazon Bedrock Guardrails.
Para isso, o GuardDuty AI Protection analisa eventos de gerenciamento e de dados do CloudTrail provenientes dos serviços de IA da AWS, sem exigir configuração manual ou ferramentas personalizadas por parte da equipe de segurança.
Integração com o AWS Security Hub
Os alertas gerados pelo GuardDuty AI Protection fluem diretamente para o AWS Security Hub, centralizando a visão dos ativos e ameaças de IA em um único painel. Isso facilita a priorização e a resposta a incidentes, sem que as equipes precisem alternar entre consoles diferentes.
Como habilitar
A ativação do recurso pode ser feita em poucos passos diretamente no console do GuardDuty ou do Security Hub. Para organizações que utilizam o AWS Organizations, é possível habilitar o GuardDuty AI Protection de forma centralizada para todas as contas da organização de uma só vez.
Disponibilidade e preços
O GuardDuty AI Protection está disponível para clientes do Amazon GuardDuty com um período de teste gratuito de 30 dias. Para consultar os detalhes de precificação após o período de teste, acesse a página de preços do Amazon GuardDuty.
A cada mês, a AWS consolida as principais publicações de segurança num post de resumo — ideal para quem não consegue acompanhar tudo em tempo real. O digest de junho de 2026 cobre identidade e gerenciamento de acesso, inteligência de ameaças, segurança de rede, ferramentas de segurança com IA e governança multi-conta. A seguir, a CloudTroop traz os destaques organizados por tema.
Identidade e Controle de Acesso
Segurança de agentes de IA multi-tenant com Amazon Bedrock AgentCore
A AWS anunciou melhorias significativas no Cognito: alta performance de throughput, chaves gerenciadas pelo cliente para criptografia de dados em repouso e replicação multi-região para continuidade de negócios — tudo construído sobre uma nova infraestrutura de armazenamento migrada com zero downtime. O post Amazon Cognito libera capacidades avançadas com infraestrutura de nova geração detalha essas mudanças.
Visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced
O artigo Ganhando visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced explica como configurar os logs de fluxo de ataque do AWS Shield Advanced para capturar metadados de tráfego durante eventos de Ataque Distribuído de Negação de Serviço (DDoS), identificar origens, verificar mitigações e alimentar pipelines de análise existentes.
Subdomain takeover: como detectar e prevenir
O post Destaque de tática de ameaça: Subdomain takeover aborda uma das táticas mais subestimadas: a tomada de subdomínios abandonados. A publicação mostra como usar regras personalizadas do AWS Config para identificar registros CNAME de DNS “pendurados” que apontam para recursos deletados em namespaces globais compartilhados.
Prevenção de exfiltração de dados com controles de egresso
AWS Continuum: segurança na velocidade das máquinas
A AWS apresentou o AWS Continuum, uma plataforma nativa de IA para vulnerabilidades de código que cobre o ciclo completo — da descoberta e priorização até a validação e remediação — tudo em velocidade de máquina. O artigo Apresentando o AWS Continuum: segurança na velocidade das máquinas detalha como a plataforma funciona.
Investigações de segurança com Kiro CLI
O post Acelerando investigações de segurança com Kiro CLI mostra como usar o Kiro CLI para conduzir investigações seguindo o framework do Guia de Resposta a Incidentes de Segurança da AWS — desde a triagem de achados do Amazon GuardDuty até contenção e preservação de evidências.
Atualização do Catálogo de Técnicas de Ameaça de junho de 2026
A AWS publicou investigações sobre vulnerabilidades de segurança reportadas que afetam serviços, softwares e produtos Amazon e AWS. Abaixo, a lista dos boletins divulgados em junho:
Junho trouxe 10 novos repositórios de amostras cobrindo segurança de IA, identidade, segurança de infraestrutura, governança e observabilidade. Todos disponíveis para que você implante e valide no seu próprio ambiente antes de adotar em produção.
Gerenciamento de Postura de Segurança de IA (AI SPM) na AWS: descubra, avalie e proteja agentes de IA no seu ambiente usando serviços nativos AWS em três pilares: observar, governar e defender — com regras mapeadas para OWASP LLM Top 10, NIST AI RMF e MITRE ATLAS.
Bedrock Ops Lens: implante um dashboard de observabilidade do Amazon Bedrock na sua própria conta para atribuição de custos por conta, por modelo e por tag, rastreamento de cotas, monitoramento de latência e gerenciamento do ciclo de vida de modelos — com servidor MCP para acesso via IDE.
Aplicação de demonstração do AWS Agent Registry: use o AWS Agent Registry para publicar, revisar, aprovar e descobrir agentes de IA, servidores MCP e habilidades de agentes por meio de um catálogo centralizado com fluxos de trabalho de governança.
OpenAI Codex via Amazon Bedrock — Governança de uso com LiteLLM: governe, administre e monitore centralmente o acesso ao OpenAI Codex para equipes de engenharia usando o Amazon Bedrock como backend de inferência, com orçamentos por usuário, limites de taxa e trilhas de auditoria via LiteLLM.
Governança de Dados Agêntica — a escada de contexto: meça como camadas de contexto de governança — dicionários de dados, métricas semânticas e habilidades de execução — melhoram a precisão de agentes de dados por meio de uma escada de ablação de quatro níveis no benchmark BIRD.
Conclusão
Junho de 2026 foi um mês denso em conteúdo prático para segurança AWS em escala organizacional. Os destaques vão desde roteiros de maturidade e restrições de acesso ao console até registros de agentes de IA e plataformas de gerenciamento de postura. Os posts e amostras apresentam padrões para visibilidade sobre DDoS com flow logs, isolamento de agentes multi-tenant com políticas baseadas em recursos, controles de egresso para prevenção de exfiltração de dados e frameworks de governança para assistentes de codificação com IA. Cada recurso inclui passos de implantação ou código executável para que você possa validar no seu próprio ambiente antes de adotar.
Para receber as publicações assim que saírem, assine o feed RSS do AWS Security Blog e volte mensalmente para o digest consolidado.
A AWS anunciou que o AWS IAM Identity Center agora está dentro do escopo da certificação FedRAMP Classe C. O serviço passou a atender a esse requisito nas seguintes regiões dos Estados Unidos: US East (Ohio), US East (N. Virginia), US West (N. California) e US West (Oregon).
O que muda na prática
Com essa certificação, organizações que precisam estar em conformidade com o FedRAMP Classe C podem utilizar o IAM Identity Center para gerenciar o acesso da força de trabalho a contas AWS e aplicações sujeitas a esse nível de compliance. Ou seja, o serviço agora é uma opção válida também para ambientes com exigências regulatórias mais rigorosas dentro do contexto do governo americano.
Vale lembrar que o IAM Identity Center já é o serviço recomendado pela AWS para gerenciar o acesso de colaboradores a contas e aplicações AWS — e essa certificação reforça ainda mais seu uso em cenários regulados.
O que é o FedRAMP
O Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, certificação e monitoramento contínuo de produtos e serviços em nuvem. Em outras palavras, é o mecanismo que o governo americano usa para garantir que soluções de nuvem atendam a critérios rigorosos de segurança antes de serem adotadas por agências federais.
O desafio de colocar modelos generativos em produção
Quem já tentou colocar um modelo de IA generativa em produção sabe bem o problema: encontrar a combinação certa de tipo de instância, contêiner de serviço e estratégia de otimização é um processo que pode consumir dias ou semanas de iteração manual. Benchmarks, ajustes, mais benchmarks — o ciclo é longo e exige conhecimento técnico especializado.
Para resolver isso, a Amazon SageMaker AI lançou em abril de 2026 o recurso de recomendações de inferência, que permite obter configurações prontas para produção de forma programática via APIs. O recurso comprime esse ciclo para minutos em cargas de trabalho comuns, e algumas horas para cargas personalizadas.
Agora, a AWS dá um passo além: a mesma funcionalidade ganhou uma interface visual completa dentro do Amazon SageMaker AI Studio, com uma experiência de baixo código/sem código (LCNC — Low-Code No-Code). O objetivo é claro — democratizar o acesso a configurações validadas de inferência para equipes que não têm expertise profunda em infraestrutura de ML.
O que muda com a nova interface
A API de recomendações já existia e funcionava bem para quem sabia quais parâmetros configurar e como interpretar os resultados brutos de benchmark. A interface visual remove essa barreira. Ela guia o usuário por perfis de uso predefinidos, comparações visuais dos resultados e implantação com um clique — sem escrever uma linha de código.
Isso significa que engenheiros de Machine Learning (ML) podem validar o próximo deployment enquanto líderes técnicos avaliam os trade-offs entre custo e desempenho, tudo dentro da mesma experiência no Studio. Usuários avançados continuam tendo acesso às APIs para configurações mais granulares.
A nova interface fica disponível no painel lateral do Studio, em Jobs → Inference optimization, e oferece um fluxo guiado de ponta a ponta cobrindo configuração da carga de trabalho, otimização, seleção de modelo e implantação.
Como funciona o fluxo de otimização
Perfis de caso de uso predefinidos
O primeiro passo é definir a configuração da carga de trabalho. Em vez de especificar manualmente distribuições de tokens e concorrência, o usuário seleciona um perfil predefinido que representa um padrão de tráfego comum:
Interact: modela cargas de trabalho estilo chat, com entradas curtas e saídas moderadas.
Generate: otimizado para geração de conteúdo com saídas mais longas.
Summarize: voltado para sumarização de documentos, com alta proporção entre entrada e saída.
Custom: para quando nenhum dos perfis anteriores se encaixa — permite trazer seu próprio dataset e configurar concorrência, tamanho de tokens e dados de avaliação manualmente.
O perfil selecionado define os parâmetros do benchmark automaticamente, sem que o usuário precise raciocinar sobre eles diretamente.
Objetivos de otimização
Junto ao perfil de caso de uso, o usuário escolhe o objetivo de otimização — o que diz ao SageMaker AI o que priorizar:
Minimize latency (Minimizar latência): busca o menor tempo de resposta possível, ideal para aplicações interativas onde o usuário aguarda cada token.
Maximize throughput (Maximizar throughput): serve o maior número de tokens por segundo, mais adequado para cargas em lote ou alto volume.
Minimize cost (Minimizar custo): encontra a configuração mais eficiente em custo para o tráfego esperado.
O objetivo escolhido influencia tanto as técnicas que o SageMaker AI aplica quanto a forma como ele classifica as recomendações resultantes.
Fontes de modelo suportadas
A interface aceita modelos de diferentes origens. É possível buscar um modelo fundacional (FM — Foundation Model) diretamente do catálogo do Amazon SageMaker JumpStart, apontar para um artefato de modelo próprio no Amazon Simple Storage Service (Amazon S3), reutilizar um pacote registrado no Model Registry ou selecionar um modelo SageMaker existente de um deployment ou job de treinamento anterior.
Passo a passo: obtendo recomendações pelo console
Pré-requisitos
Para seguir o fluxo, são necessários: uma conta AWS com um domínio do Amazon SageMaker AI Studio, permissões de AWS Identity and Access Management (IAM) para operações de otimização de inferência no SageMaker AI, e uma role de execução IAM com acesso aos artefatos do modelo no Amazon S3.
Em relação a custos, não há cobrança adicional para gerar as recomendações. Os custos padrão de computação se aplicam aos jobs de otimização e aos endpoints provisionados durante o benchmarking.
Passo 1: Criar um job de otimização
No painel lateral do Studio, acesse Jobs → Inference optimization e clique em Create (ou Optimize inference). Com o job criado, o próximo passo é informar ao SageMaker AI o que você quer otimizar.
Passo 2: Configurar a estratégia
Cada caso de uso tem requisitos diferentes — alguns têm um orçamento de latência muito restrito, outros têm um orçamento de custo rígido. Dependendo do cenário, selecione um dos perfis de caso de uso (Interact, Generate, Summarize ou Custom) e um objetivo de otimização (Minimize cost, Minimize latency ou Maximize throughput).
Se o perfil Custom for selecionado, campos adicionais aparecem: é possível colar o URI do S3 com o dataset de avaliação em formato JSONL, especificar o número de requisições simultâneas para simular a concorrência e definir o tamanho máximo de tokens de saída.
Passo 3: Selecionar o modelo e o hardware
Usando o botão Select na seção Model, uma janela abre com abas para cada fonte de modelo (JumpStart, S3, Logged e Deployable). Se a opção S3 for escolhida, é necessário fornecer um nome e o caminho URI do artefato do modelo.
Com o modelo selecionado, é possível deixar o SageMaker AI escolher o hardware automaticamente ou restringir a busca a tipos de instância específicos. A seleção de hardware é opcional. Para os objetivos de minimizar latência ou maximizar throughput, é possível expandir a seção Compute e selecionar tipos de instância específicos (por exemplo, ml.g6e.2xl ou g7e.2xl) para avaliação. Se nenhum for especificado, o SageMaker AI seleciona instâncias compatíveis com base nos requisitos do modelo. Para o objetivo de minimizar custo, o SageMaker AI seleciona automaticamente a instância recomendada. Se houver capacidade reservada por meio de um flexible training plan, ela aparece na lista de fontes.
Passo 4: Executar e monitorar
Ao clicar em Optimize, o job é submetido e a página de detalhes exibe a transição de status de Running para Completed. Perfis predefinidos como Interact podem retornar recomendações rapidamente por já serem comparados a configurações pré-validadas, enquanto benchmarks customizados podem levar mais tempo dependendo do tamanho do modelo, tipos de instância e dataset.
A página de detalhes tem três abas: Overview (recomendações ranqueadas com métricas de desempenho, disponíveis após a conclusão do job), Settings (configuração submetida, incluindo caso de uso, objetivo e seleções de hardware) e Details (metadados do job, timestamps e artefatos de saída).
Passo 5: Revisar recomendações e fazer o deploy
A aba Overview exibe os pacotes de inferência ranqueados. Cada pacote mostra a configuração otimizada, métricas de desempenho — tempo até o primeiro token (TTFT — Time To First Token), latência entre tokens (ITL — Inter-Token Latency), throughput e custo — e um botão Deploy.
Ao clicar em Deploy, uma janela pré-preenche o nome do endpoint e o tipo de instância. É possível fazer o deploy em um novo endpoint ou atualizar um existente. O SageMaker AI então executa três etapas em sequência: registra o modelo otimizado, configura o endpoint e provisiona o endpoint. Após o endpoint atingir o status In Service, ele já pode ser invocado imediatamente.
Gerenciamento dos jobs de otimização
A página de listagem em Jobs → Inference optimization oferece gerenciamento centralizado dos jobs. É possível usar a barra de busca para filtrar por nome, parar um job em execução via menu Actions → Stop, excluir jobs antigos e acessar a página de detalhes de qualquer job.
Como a otimização funciona por baixo dos panos
A experiência no console e a API utilizam a mesma infraestrutura de recomendações e benchmarking. O SageMaker AI primeiro analisa a arquitetura do modelo e os requisitos de memória para reduzir o espaço de configurações e identificar opções viáveis. Em seguida, aplica otimizações alinhadas ao objetivo: speculative decoding para throughput ou kernel tuning para latência, dependendo do objetivo selecionado. O SageMaker AI faz benchmark de cada configuração em infraestrutura real de GPU usando o NVIDIA AIPerf com intervalos de confiança de múltiplas execuções. Por fim, pontua os resultados contra o objetivo de otimização e retorna configurações prontas para produção, ranqueadas do melhor para o pior.
O comportamento varia conforme o objetivo:
Minimize cost: o SageMaker AI cria um endpoint com o tipo de instância recomendado e executa jobs de benchmark contra ele. O status In Service pode ser acompanhado em Deployments → Endpoints, e os runs de benchmark em Training → Training Jobs.
Minimize latency: se a arquitetura do modelo e o tipo de instância suportarem, o SageMaker AI usa um deployment com kernel ajustado. Caso contrário, cria um ou mais endpoints padrão, cada um correspondendo a um tipo de instância, e executa jobs de benchmark como training jobs para cada combinação.
Maximize throughput: se a arquitetura e o tipo de instância suportarem speculative decoding, um training job é executado primeiro para treinar o modelo draft antes dos endpoints serem implantados. O SageMaker AI então executa jobs de benchmark como training jobs para cada combinação.
Vale destacar que o job de otimização deleta automaticamente os endpoints criados durante o processo após sua conclusão.
Boas práticas de uso
A AWS recomenda reexecutar os jobs de otimização em algumas situações: após fine-tuning ou atualização do modelo, quando novos tipos de instância ficarem disponíveis na região AWS utilizada, quando os padrões de tráfego mudarem significativamente e após upgrades de contêiner de serving ou de framework. Também é recomendado executar os jobs em uma cadência regular — por exemplo, a cada algumas semanas — já que a equipe do Amazon SageMaker AI adiciona continuamente novas descobertas ao serviço.
A AWS anunciou a disponibilidade geral dos modelos OpenAI GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. A novidade traz para a plataforma a família de modelos mais avançada da OpenAI até o momento, integrada ao motor de inferência de nova geração do Bedrock — projetado com foco em alto desempenho, segurança e confiabilidade.
O GPT-5.6 estabelece um novo patamar de inteligência e eficiência, permitindo resolver problemas mais complexos com maior inteligência por token. Os três modelos da família cobrem diferentes níveis de capacidade e custo, todos acessíveis pela Responses API no Amazon Bedrock.
Os três modelos da família GPT-5.6
Cada modelo da família foi pensado para um perfil de uso diferente:
Sol — o modelo carro-chefe, voltado para raciocínio avançado. Entrega resultados de ponta nos benchmarks de codificação agêntica (agentic coding), sendo a escolha para tarefas que exigem máxima capacidade.
Terra — o modelo de desempenho equilibrado. Oferece performance equivalente ao GPT-5.5 pela metade do custo, sendo uma opção estratégica para quem precisa de qualidade sem abrir mão da eficiência financeira.
Luna — o modelo de inferência rápida e econômica. Traz o menor preço da família, ideal para casos de uso que demandam velocidade e escala com custo controlado.
Casos de uso destacados
Com o GPT-5.6 no Bedrock, as equipes podem construir agentes autônomos de codificação, executar análises de longo prazo em genômica e biologia, e conduzir pesquisas avançadas em cibersegurança. São aplicações que exigem tanto capacidade de raciocínio quanto eficiência operacional — e a família GPT-5.6 foi desenhada justamente para cobrir esse espectro.
Prompt caching e controle de custos
Um recurso importante anunciado junto com a família é o prompt caching com pontos de quebra de cache explícitos. Na prática, isso significa que contextos repetidos ao longo de fluxos de trabalho agênticos são cobrados com 90% de desconto — evitando que o custo se multiplique à medida que os agentes escalam. Para arquiteturas que reutilizam muito contexto, esse recurso pode representar uma economia significativa.
A precificação dos modelos segue as mesmas tarifas praticadas diretamente pela OpenAI, e o consumo é contabilizado nos compromissos de gastos da AWS do cliente.
Disponibilidade por região
A disponibilidade atual dos modelos nas regiões da AWS é a seguinte:
GPT-5.6 Sol: US East (N. Virginia) e US East (Ohio)
GPT-5.6 Terra e Luna: US East (N. Virginia), US East (Ohio) e US West (Oregon)
Como começar
Para experimentar os modelos, é possível acessar o Console do Amazon Bedrock ou utilizar a Responses API pelo endpoint bedrock-mantle. Para mais detalhes técnicos, a documentação do Amazon Bedrock cobre os modelos da OpenAI disponíveis na plataforma. Quem preferir uma visão mais aprofundada do lançamento pode conferir o post de lançamento no blog oficial.
O HITRUST i1 é a certificação mais amplamente exigida no setor de saúde. A avaliação cobre 182 controles selecionados no nível de implementação (Implemented) e aparece com frequência em contratos com fornecedores, Acordos de Parceiro de Negócios (BAAs) e exigências de planos de saúde, sistemas hospitalares e associados de negócios como condição para estabelecer parcerias.
Em outras palavras: para quem atua no ecossistema de saúde nos Estados Unidos — ou para empresas brasileiras que prestam serviços a clientes norte-americanos nesse setor — essa certificação pode ser um requisito contratual real.
O que o guia cobre
O material foi desenhado para preencher a lacuna entre entender o que o HITRUST i1 exige e saber como implementar esses requisitos na AWS. Ele conduz arquitetos de nuvem, engenheiros de segurança, responsáveis por conformidade e equipes de preparação para avaliação por todo o ciclo de um engajamento i1 — desde a definição do escopo da avaliação até a implementação de controles em cada domínio técnico.
Os 11 domínios de controle técnico abordados no guia são:
Controle de acesso
Proteção de endpoints
Gerenciamento de configuração
Gerenciamento de vulnerabilidades
Proteção de rede
Proteção de transmissão
Gerenciamento de incidentes
Proteção de dados e privacidade
Registro de auditoria e monitoramento
Gerenciamento de senhas
Continuidade de negócios e recuperação de desastres
Cenário ilustrativo com AWS Landing Zone Accelerator
Para tornar os conceitos mais concretos, o guia utiliza um cenário fictício — mas realista — de uma plataforma de saúde conectada implantada no AWS Landing Zone Accelerator. Vale reforçar: o cenário existe para fins didáticos e não sugere que a mesma arquitetura ou as mesmas escolhas de controle se aplicam universalmente. O escopo do HITRUST i1 é, por natureza, específico para cada organização.
O limite da avaliação, os controles aplicáveis e os requisitos de evidência são definidos pelo escopo de sistema de cada organização e gerenciados pelo portal HITRUST MyCSF. A recomendação é tratar o guia como ponto de partida e trabalhar com um Avaliador Externo Autorizado HITRUST para validar o que se aplica ao ambiente específico de cada empresa. O documento não constitui uma consultoria de certificação de conformidade.
A documentação de garantia HITRUST da AWS e a Matriz de Responsabilidade do Cliente estão disponíveis pelo AWS Artifact. Para suporte na preparação para avaliações, a AWS indica o AWS Security Assurance Services.
A AWS anunciou a disponibilidade geral dos modelos GPT-5.6 Sol, Terra e Luna da OpenAI no Amazon Bedrock. A novidade traz a família de modelos mais avançada da OpenAI até hoje para o motor de inferência de nova geração da plataforma, projetado para alto desempenho, segurança e confiabilidade.
O contexto é relevante: organizações que escalam agentes autônomos e produtos com IA precisam de inteligência de fronteira que funcione de forma confiável ao longo de centenas de etapas — de agentes de código que entregam software em produção a pesquisas de segurança cibernética que exploram novas superfícies de ataque, passando por fluxos de trabalho de genômica que analisam sequências genéticas inteiras de ponta a ponta. Essas cargas de trabalho rodam sobre dados sensíveis, exigem throughput consistente sob demanda imprevisível e operam em ambientes onde residência de dados e segurança não são negociáveis.
Os preços do GPT-5.6 no Bedrock seguem as tarifas de primeira parte da OpenAI, e o uso conta para os compromissos existentes com a AWS.
Um novo sistema de nomenclatura e três camadas de capacidade
O GPT-5.6 inaugura um novo sistema de nomenclatura da OpenAI: o número identifica a geração, enquanto Sol, Terra e Luna identificam camadas de capacidade duráveis que podem evoluir em seu próprio ritmo.
GPT-5.6 Sol — raciocínio avançado
O Sol é o modelo de raciocínio principal e o mais poderoso da OpenAI até o momento. Segundo a própria OpenAI, o Sol estabelece um novo estado da arte no Artificial Analysis Coding Agent Index com 80 pontos — 2,8 acima do próximo melhor modelo — usando menos da metade dos tokens de saída, em menos da metade do tempo e custando cerca de um terço a menos.
No ExploitBench, benchmark de pesquisa em segurança cibernética, o Sol alcança 73,5% contra 47,9% do GPT-5.5 com um orçamento comparável de tokens de saída. No Agents’ Last Exam — avaliação de fluxos de trabalho profissionais de longa duração em 55 áreas —, o Sol atinge 53,6 pontos, superando o próximo melhor modelo em 13,1 pontos. Com esforço de raciocínio médio, ainda lidera por 11,4 pontos a aproximadamente um quarto do custo estimado.
O Sol também introduz o max reasoning effort (esforço máximo de raciocínio), que permite aumentar o poder computacional para trabalhos mais complexos. Os casos de uso indicados incluem agentes de codificação autônoma, pesquisa de vulnerabilidades, fluxos de trabalho de descoberta de medicamentos e tarefas que exigem raciocínio profundo em múltiplas etapas.
GPT-5.6 Terra — equilíbrio para produção
O Terra é o modelo balanceado para o trabalho cotidiano em produção. Ele entrega desempenho superior ao GPT-5.5 com custo menor. É indicado para geração de código, fluxos de trabalho de conteúdo, extração de dados estruturados e tarefas agênticas de propósito geral que precisam de raciocínio sólido sem o preço do modelo principal.
GPT-5.6 Luna — velocidade e economia
O Luna é o modelo rápido e acessível. É indicado para tarefas de inferência em alto volume, como classificação, sumarização, roteamento e aplicações em tempo real onde latência e custo por token são prioritários.
Com as três camadas, é possível calibrar capacidade e custo ao modelo certo para cada carga de trabalho. Os modelos GPT-5.6 concluem tarefas com menos tokens de saída do que seus predecessores, entregando melhor desempenho por dólar gasto.
Motor de inferência construído para escala
O tráfego de agentes tende a ser irregular: uma única requisição de usuário pode disparar centenas de chamadas ao modelo, e a demanda pode mudar rapidamente conforme o uso cresce. O motor de inferência de nova geração do Amazon Bedrock agrupa capacidade para absorver picos de demanda enquanto isola o throughput de cada cliente. Isso reduz a necessidade de escolher entre capacidade compartilhada e desempenho previsível de aplicação.
A inferência dentro da região (In-Region) mantém as requisições dentro da Região AWS especificada, ajudando equipes a cumprir requisitos rígidos de residência de dados.
Cache de prompts com pontos de quebra explícitos
Cargas de trabalho agênticas e de múltiplas etapas repetem boa parte do contexto entre chamadas. Instruções de sistema, definições de ferramentas e arquivos de referência frequentemente permanecem os mesmos enquanto apenas a entrada mais recente muda.
O GPT-5.6 no Amazon Bedrock introduz o cache de prompts com pontos de quebra explícitos para aproveitar essa repetição. Você marca a parte reutilizável de um prompt com um ponto de quebra de cache, e o Bedrock reutiliza o contexto processado em requisições subsequentes que o compartilhem — cada chamada paga apenas pelo trabalho novo. A entrada em cache é cobrada com 90% de desconto e fica disponível para reutilização por pelo menos 30 minutos. Esse período é suficiente para cobrir o burst de chamadas que uma única execução de agente gera, sem multiplicar o custo conforme as cargas de trabalho crescem.
Segurança robusta com proteção em nível de hardware
Modelos mais capazes exigem salvaguardas mais fortes. O GPT-5.6 conta com a pilha de segurança mais robusta da OpenAI até hoje, moldada pelo período de avaliação mais extenso da empresa, combinando red teaming humano com testes automatizados em larga escala. A pilha de segurança inclui recusas em nível de modelo para atividades proibidas, classificadores de uso indevido em tempo real, monitoramento contínuo e aplicação em nível de conta para padrões persistentes.
No Amazon Bedrock, essas proteções se somam à segurança em nível de hardware. O Bedrock utiliza um modelo de segurança ZOA (Zero-Operator Access — acesso zero ao operador), aplicado no chip, de modo que nenhum operador da AWS pode acessar seus prompts ou respostas. Cada chamada ao modelo roda sob as políticas do seu IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso), dentro da sua VPC (Virtual Private Cloud — Nuvem Privada Virtual), e é registrada no AWS CloudTrail. Políticas de perímetro de dados evitam exfiltração entre fronteiras de conta e rede.
Conforme exigido pelo provedor do modelo, dados de tráfego sinalizados por classificadores serão retidos por até 30 dias para detecção automatizada de abuso.
ChatGPT Work e Codex no contexto do GPT-5.6
Junto ao GPT-5.6, a OpenAI lançou o ChatGPT Work, um agente dentro do ChatGPT para tarefas maiores e de múltiplas etapas. O aplicativo desktop atualizado do ChatGPT para Mac e Windows reúne Chat, Work e Codex em uma única experiência, com dois agentes dedicados:
Work: construído para tarefas maiores e de múltiplas etapas. Pode reunir informações em aplicativos e arquivos, usar a web, criar materiais finalizados como planilhas, slides, documentos e sites, e se manter em projetos complexos por horas. Os usuários podem acompanhar o progresso, mudar de direção e aprovar ações importantes.
Codex: o poderoso agente de codificação para desenvolvedores e profissionais técnicos. Trabalha com arquivos locais, repositórios, terminais, ferramentas de desenvolvimento e ambientes de desenvolvimento para escrever funcionalidades, corrigir bugs, executar testes e abrir pull requests.
Os usuários podem configurar o aplicativo para usar o GPT-5.6 por meio da Responses API no Amazon Bedrock.
Disponibilidade e como começar
O GPT-5.6 Sol está disponível nas seguintes Regiões AWS: US East (N. Virginia) e US East (Ohio). O GPT-5.6 Terra e Luna estão disponíveis em US East (N. Virginia), US East (Ohio) e US West (Oregon).
A AWS anunciou a disponibilidade do modelo Gemma-4-E2B-it no Amazon SageMaker JumpStart, ampliando ainda mais o portfólio de modelos de fundação acessíveis aos clientes da plataforma. Desenvolvido pelo Google DeepMind, esse modelo chega como uma opção multimodal e ajustada para seguir instruções, com foco em execução local eficiente — o que o torna uma escolha interessante para quem quer construir aplicações de Inteligência Artificial (IA) na infraestrutura da AWS sem abrir mão de desempenho.
O que é o Gemma-4-E2B-it
O Gemma-4-E2B-it é um modelo multimodal, ou seja, capaz de processar diferentes tipos de entrada: texto, imagem e áudio. A saída gerada é sempre em formato de texto. Um diferencial importante é o seu modo de raciocínio nativo, que permite ao modelo “pensar passo a passo” antes de formular uma resposta — uma abordagem que tende a aumentar a qualidade e a precisão das respostas em tarefas mais complexas.
Capacidades do modelo
O Gemma-4-E2B-it cobre uma gama ampla de casos de uso. Entre as funcionalidades destacadas pela AWS, estão:
Compreensão de imagens: detecção de objetos, interpretação de documentos, entendimento de telas e interfaces de usuário (UI), leitura de gráficos e Reconhecimento Óptico de Caracteres (OCR)
Compreensão de vídeo
Chamada de funções nativa para fluxos de trabalho agênticos
Geração, completude e correção de código
Suporte multilíngue em dezenas de idiomas
Esse conjunto de capacidades posiciona o modelo como uma opção versátil tanto para aplicações voltadas ao usuário final quanto para automações e pipelines de IA mais sofisticados.
Como colocar em produção no SageMaker JumpStart
Uma das vantagens do SageMaker JumpStart é justamente a facilidade de implantação. Para começar a usar o Gemma-4-E2B-it, basta acessar a seção Models dentro do SageMaker Studio ou utilizar o SageMaker Python SDK para realizar o deploy diretamente na conta AWS. O processo é feito em poucos cliques, sem necessidade de configurações complexas de infraestrutura.
A chegada do Gemma-4-E2B-it ao SageMaker JumpStart é mais um passo na expansão do catálogo de modelos de fundação disponíveis na AWS. Para times brasileiros que trabalham com desenvolvimento de aplicações de IA, isso significa acesso a um modelo multimodal de qualidade — com suporte a múltiplos idiomas, incluindo o português — diretamente integrado ao ecossistema de ferramentas que já utilizam no dia a dia.
DocumentDB ganha skill dedicada no Agent Toolkit for AWS
A AWS anunciou que o Amazon DocumentDB (com compatibilidade com MongoDB) passou a integrar o Agent Toolkit for AWS como uma skill especializada de banco de dados. A novidade permite que agentes de codificação com Inteligência Artificial (IA) realizem operações completas em clusters do DocumentDB — desde o provisionamento até a resolução de problemas — seguindo fluxos de trabalho estruturados com boas práticas.
Na prática, isso significa que times de desenvolvimento conseguem executar tarefas complexas no DocumentDB com muito menos esforço manual, sem precisar consultar documentações extensas a cada operação.
O que a skill cobre
A skill do Amazon DocumentDB contempla sete fluxos de trabalho distintos:
Provisionamento de cluster
Design de schema
Avaliação de compatibilidade com MongoDB
Migração baseada em DMS com Captura de Dados de Mudança (CDC)
Ajuste de performance
Revisão Well-Architected com 41 verificações
Upgrades de versão principal
Essa cobertura abrangente reduz erros operacionais e acelera o trabalho dos desenvolvedores, que passam a contar com orientação automatizada em cada etapa.
Integração com o AWS MCP Server e execução standalone
Quando combinada com o AWS MCP Server, a skill permite que os agentes executem comandos da Interface de Linha de Comando (CLI) da AWS e rodem queries de diagnóstico com controles baseados em Gerenciamento de Identidade e Acesso (IAM), registro de auditoria via CloudTrail e execução em ambiente isolado (sandboxed).
Para equipes que preferem trabalhar localmente, a skill também funciona de forma independente, diretamente via CLI da AWS, sem necessidade de integração adicional.
Quando um agente de IA generativa é colocado em produção em arquiteturas multi-tenant, surge um problema de identidade bastante específico: ao fazer uma chamada para uma API downstream em nome de um usuário, qual identidade viaja com essa chamada?
Existem três abordagens possíveis, mas apenas uma delas é segura. Executar a chamada com a identidade de serviço do próprio agente destrói a trilha de auditoria, pois cada sistema downstream precisa confiar incondicionalmente no agente. Encaminhar o token do usuário sem modificação só funciona quando a audiência do token já corresponde à API downstream — condição raramente verdadeira em sistemas multi-tenant. A terceira opção, a troca On-Behalf-Of (OBO), é a única que preserva a identidade do usuário de ponta a ponta, aplica o princípio do menor privilégio na fronteira de audiência e produz um token que a API downstream pode validar de forma independente.
O que é o padrão On-Behalf-Of e por que ele importa
Em uma troca OBO, o claim sub do token de entrada é preservado enquanto o claim aud é reescrito para o serviço downstream. O ator da troca fica registrado em um claim separado (act conforme a RFC 8693, ou cid no Okta), permitindo que a API downstream responda duas perguntas a partir de um único token: em nome de quem a ação está sendo executada? (claim sub) e quem está executando a ação? (claim do ator).
O AgentCore Gateway suporta esse padrão de forma transparente: ele intercepta a chamada de ferramenta, identifica o tenant de destino e instrui o AgentCore Identity a realizar a troca contra o servidor de autorização do tenant antes de emitir a chamada downstream. O código do agente não precisa implementar nenhuma lógica de troca — ele obtém um único token de entrada e invoca ferramentas normalmente.
A implementação de referência: TravelBot
O TravelBot é um assistente de reservas multi-tenant que atende dois tenants de exemplo, Acme e Globex. A implementação de referência estará disponível no repositório aws-samples/sample-obo-flow-poc após a publicação.
A arquitetura tem seis componentes principais:
Servidor de autorização provedor — Emite o Token Web JSON (JWT) de entrada que o agente apresenta ao Gateway. No TravelBot, é o servidor Okta chamado TravelBot Provider.
AgentCore Gateway — Valida o JWT de entrada, roteia a invocação de ferramenta para o tenant correto e orquestra a troca OBO.
AgentCore Identity — Armazena as credenciais do cliente delegado e executa a troca de token RFC 8693 contra o servidor de autorização do tenant.
Servidores de autorização por tenant — Emitem tokens OBO com escopo para a audiência de cada tenant. No TravelBot, ACME Travel API e Globex Travel API são dois servidores Okta distintos, cada um com sua própria audiência e política de acesso.
Superfície de API por tenant — Um Amazon API Gateway HTTP API com um autorizador JWT por tenant. Cada autorizador valida emissor, audiência e escopos obrigatórios.
Lógica de negócio do tenant — Uma função AWS Lambda que recebe o token OBO validado, lê os claims e armazena reservas no Amazon DynamoDB particionado pelo claim sub.
Fluxo de troca de tokens: três fases
O fluxo completo passa por três transformações de token. A tabela a seguir resume como cada claim JWT é transformado entre o token de entrada e o token OBO:
iss: reescrito do servidor provedor para o servidor do tenant
aud: reescrito de travelbot-provider para https://api.acme-travel.example
sub: preservado de ponta a ponta (alice@acme-travel.example)
cid: reescrito do cliente provedor para o cliente delegado (AgentCore Delegate)
scp: reescrito de [openid email gateway/invoke] para [booking/read booking/write]
authorized_scopes: novo claim calculado a partir da associação de grupo do usuário
Três claims carregam a história de segurança: o sub é preservado para que logs de auditoria e decisões de autorização resolvam para o chamador original; o aud é reescrito para a API do tenant, vinculando o token criptograficamente a um único serviço downstream; e o cid registra o delegado que realizou a troca, separando o ator do chamador.
Fase 1 — Token de entrada, emitido pelo servidor de autorização provedor
Um objetivo natural em sistemas multi-tenant é conceder escopos diferentes a cada usuário por papel. Por exemplo, um grupo acme-readonly recebe booking/read, e um grupo acme-fullaccess recebe ambos booking/read e booking/write. O problema é que a troca OBO é processada como uma concessão máquina-a-máquina (M2M): o Okta não mapeia o usuário sujeito de volta para seus grupos para fins de filtragem de escopos. O claim scp do token OBO retorna contendo todos os escopos que o cliente solicitou, independentemente do grupo do usuário.
A solução utiliza um claim em vez de um escopo. Embora o Okta não filtre scp por usuário durante a troca, ele avalia um claim do tipo Expression contra o usuário sujeito no momento da emissão. Adiciona-se um claim personalizado em cada servidor de autorização do tenant:
Nome: authorized_scopes
Tipo de token: Access Token
Tipo de valor: Expression
Valor (Acme): isMemberOfGroupName("acme-fullaccess") ? "booking/read booking/write" : (isMemberOfGroupName("acme-readonly") ? "booking/read" : "")
Incluir em: Qualquer escopo
O token OBO passa a carregar tanto um scp permissivo (informativo) quanto um claim authorized_scopes que reflete a permissão real do usuário. O servidor de recursos toma sua decisão com base em authorized_scopes.
A função Lambda trata authorized_scopes como fonte da verdade para operações de escrita:
# Requisições GET consultam o DynamoDB particionado por tenant + sub.
# Requisições POST exigem adicionalmente booking/write em authorized_scopes:
if method == "POST":
authorized = obo_claims.get("authorized_scopes") or []
if isinstance(authorized, str):
authorized = authorized.split()
if "booking/write" not in authorized:
return {
"statusCode": 403,
"headers": {"Content-Type": "application/json"},
"body": json.dumps({
"error": "forbidden",
"message": f"User {username} is not permitted to create bookings.",
}),
}
# ... proceed to write the booking
Isolamento de dados por tenant com o claim sub
A propagação de identidade só tem valor se os sistemas downstream agirem sobre ela. O TravelBot armazena reservas no DynamoDB particionado pela identidade do usuário: a chave de partição (pk) é "{tenant}#{sub}" — por exemplo, acme#alice@acme-travel.example — e a chave de ordenação é o ID da reserva. Em uma leitura, a Lambda emite uma Query com escopo para o pk do chamador. Em uma escrita, coloca um item sob o mesmo pk. O efeito é que um usuário não consegue recuperar as reservas de outro usuário — não por um filtro na camada de aplicação, mas porque a consulta é construída a partir do próprio claim sub do chamador, assinado pelo Okta e verificado pelo autorizador do API Gateway antes de a Lambda ser invocada.
Um token OBO emitido para um tenant não pode ser usado para acessar os recursos de outro tenant. No TravelBot, esse princípio é aplicado em três locais independentes: no target do Gateway (o valor customParameters.audience é definido por target); no servidor de autorização do tenant (o Okta valida se o parâmetro audience da requisição de troca está registrado no servidor antes de assinar o token OBO); e no autorizador JWT do API Gateway (cada rota está vinculada a um autorizador cuja JwtConfiguration.Audience é a audiência do tenant). Um token cujo claim aud não corresponde é rejeitado com HTTP 401 antes de a função Lambda ser invocada.
Após essas três operações, o código do agente não contém nenhuma lógica de troca de tokens. Ele adquire um token do provedor, abre uma sessão MCP contra o Gateway e invoca ferramentas. O Gateway e o Identity realizam a troca de forma transparente em cada chamada de ferramenta. A integração de um novo tenant requer apenas a criação de um provedor de credenciais e um target de Gateway — sem alterações no código do agente.
Armadilhas comuns na integração com Okta
A implementação do TravelBot revelou um conjunto de problemas que aparecem consistentemente em integrações OBO contra o Okta:
Filtragem de escopos por grupo é ignorada durante a troca de tokens. Como o Okta processa a concessão OBO como M2M, não mapeia o usuário do subject_token para seus grupos para filtragem de scp. Use um claim Expression (authorized_scopes) aplicado no servidor de recursos.
O DPoP (Demonstração de Prova de Posse) deve ser desabilitado. O DPoP vincula um token a uma chave privada que o cliente original possui. O AgentCore Identity é um relay de tokens e não possui essa chave, portanto deixar o DPoP obrigatório produz erros invalid_dpop_proof no momento da troca. Compense com tokens OBO de curta duração e TLS em todos os saltos.
O Okta usa o claim cid, não client_id. O mecanismo allowedClients do Gateway corresponde a client_id, que os tokens de acesso do Okta não carregam. Use allowedAudience.
O parâmetro subject_token_type deve ser access_token. Vários SDKs padronizam para jwt em trocas RFC 8693, e o Okta rejeita isso com invalid_request. Substitua o valor via customParameters no target do Gateway.
O servidor de autorização provedor deve ser registrado como emissor confiável em cada servidor de autorização do tenant. Isso é configurado em “Trusted Servers” no console de administração do Okta. Sem essa relação de confiança, mesmo uma requisição de troca corretamente construída falha.
O aplicativo delegado deve listar o grant type de troca de token em seus grant types permitidos. Tanto o controle no nível do aplicativo quanto a política de acesso do servidor de autorização são obrigatórios. A ausência de qualquer um produz um erro unauthorized_client.
Boas práticas para produção
Um provedor de credenciais e um cliente delegado por tenant — evite compartilhar provedores entre tenants.
Vincule audiências explicitamente — defina customParameters.audience em cada target do Gateway e JwtConfiguration.Audience em cada autorizador do API Gateway.
Emita tokens OBO de curta duração — configure os servidores de autorização dos tenants para emitir tokens OBO com o menor tempo de vida (TTL) que a aplicação tolere.
Trate o client secret do AgentCore Delegate como a credencial mais sensível do sistema — um secret vazado permite que um usuário não autorizado emita tokens OBO para qualquer valor de sub em todos os servidores de autorização de tenant aos quais o delegado está atribuído. Armazene o secret no AWS Secrets Manager com rotação habilitada.
Tome decisões de autorização com base em sub e claims por usuário, não no claim do ator — o chamador original é o principal; o delegado que realizou a troca é o ator.
Nunca emita claims de nomes ou tokens brutos nos logs de aplicação — registre sub, o ator (cid no Okta), aud e o jti do token. Nunca registre o valor bruto do cabeçalho Authorization.
O AgentCore Identity suporta conectividade pública e privada (VPC) para servidores de autorização de tenants. Consulte Conectar a provedores de identidade privados no guia do desenvolvedor do AgentCore para padrões de configuração.
Conclusão
A troca de tokens On-Behalf-Of é o padrão de identidade correto para agentes de IA multi-tenant, e o Amazon Bedrock AgentCore Gateway o operacionaliza sem exigir que o agente implemente a RFC 8693. Ao combinar os provedores de credenciais com audiência vinculada do Gateway com os autorizadores JWT por tenant do API Gateway, preserva-se a identidade do usuário de ponta a ponta, aplica-se o menor privilégio na fronteira de audiência e produz-se uma trilha de auditoria que distingue o delegado do usuário. O claim sub torna-se um principal confiável que os serviços downstream podem passar para uma camada de autorização refinada, como o Amazon Verified Permissions.
