Category: Uncategorized

IA agêntica chega ao setor de saúde regulado

Organizações de saúde e ciências da vida dependem de tarefas manuais e repetitivas baseadas em navegadores para fluxos de trabalho críticos — como processamento de sinistros e coordenação de encaminhamentos médicos. Embora a IA agêntica tenha potencial para automatizar esses processos, as exigências de conformidade da Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) vinham limitando sua adoção em cenários onde informações eletrônicas de saúde protegidas (ePHI) estivessem presentes.

A AWS anunciou que o Amazon Nova Act agora é um serviço elegível para HIPAA. Isso significa que é possível implantar agentes de IA autônomos, baseados em navegador, para automatizar fluxos de trabalho complexos de saúde em conexão com ePHI.

O que é o Amazon Nova Act

O Amazon Nova Act é um serviço da AWS voltado para a criação e o gerenciamento de frotas de agentes de IA confiáveis, com foco na automação de fluxos de trabalho de interface de usuário (UI) em produção e em escala. O serviço executa tarefas repetitivas no navegador e, quando necessário, escala para um supervisor humano.

O Nova Act também se integra a ferramentas externas por meio de chamadas de API, Protocolo de Controle de Modelo (MCP) remoto ou frameworks agênticos, como o Strand Agents. Os fluxos de trabalho podem ser definidos combinando a flexibilidade da linguagem natural com código Python.

Na prática, o Amazon Nova Act consegue navegar em sites, preencher formulários, extrair informações e concluir fluxos de trabalho com múltiplas etapas. Para organizações de saúde, isso se traduz em menor carga administrativa, processamento mais rápido de sinistros e execução mais consistente de processos rotineiros.

Por que a elegibilidade HIPAA importa para IA agêntica

Diferentemente de modelos que apenas geram texto, sistemas de IA agêntica interagem com sistemas ativos, acessam dados e executam fluxos de trabalho que podem envolver Informações de Saúde Protegidas (PHI). Esse nível de interação exige uma atenção especial à conformidade regulatória.

Sob o Modelo de Responsabilidade Compartilhada da AWS, a AWS gerencia a segurança da infraestrutura subjacente, enquanto o cliente permanece responsável por configurar os controles necessários para alcançar a conformidade com o HIPAA em suas implantações.

Casos de uso na área da saúde

Com a elegibilidade HIPAA, o Nova Act abre espaço para uma série de automações em ambientes regulados. Entre os casos de uso mencionados pela AWS, estão:

• Agendamento de consultas, verificação de planos de saúde e autorização prévia em portais de prestadores e operadoras;
• Verificação de status de sinistros, envio de recursos e acompanhamento de reembolsos em sites de operadoras, sem intervenção manual;
• Envio e rastreamento de encaminhamentos entre prestadores;
• Coleta de dados de múltiplos sistemas para relatórios de conformidade.

Como começar a usar

Para utilizar o Nova Act em um ambiente elegível para HIPAA, a AWS orienta seguir os passos abaixo:

• Assinar um Acordo de Parceiro de Negócios (BAA) da AWS por meio do processo de autoatendimento no Console de Gerenciamento da AWS e designar a conta como uma conta HIPAA;
• Revisar a documentação do Nova Act para configurações de segurança específicas do serviço;
• Implementar controles de segurança, incluindo políticas de acesso do Gerenciamento de Identidade e Acesso da AWS (IAM), criptografia com o Serviço de Gerenciamento de Chaves da AWS (KMS) e registro de logs com o AWS CloudTrail;
• Realizar uma revisão de design com a Ferramenta AWS Well-Architected antes de implantar cargas de trabalho que envolvam ePHI.

Para orientações mais detalhadas sobre implementação, a AWS recomenda envolver o AWS Professional Services ou um parceiro com competência em IA generativa da AWS.

Pontos importantes sobre o serviço

• Elegibilidade HIPAA: o Amazon Nova Act está incluído na lista de Serviços Elegíveis para HIPAA. Com um BAA assinado, é possível usar o Nova Act para processar ePHI.
• Integrações: o Nova Act funciona com o framework Strands Agents e se integra ao Amazon Bedrock AgentCore, Amazon CloudWatch e IAM.
• Disponibilidade: o Amazon Nova Act está disponível na região AWS US East (N. Virginia). Para conferir a disponibilidade por região, acesse a página de Capacidades da AWS por Região.
• Preços: os detalhes de precificação estão disponíveis na página de preços do Amazon Nova Act.
• Nota de conformidade: a elegibilidade HIPAA indica que o serviço foi projetado para uso em conformidade com os requisitos do HIPAA. A responsabilidade pela configuração adequada do serviço para atender às obrigações específicas de conformidade é do cliente. Este anúncio não constitui assessoria jurídica ou de conformidade.

Conclusão

Com a elegibilidade HIPAA, o Amazon Nova Act abre caminho para que a IA agêntica seja adotada em ambientes de saúde regulados. Para equipes que atuam nesse setor, vale explorar a documentação do Nova Act e iniciar o processo de assinatura do BAA da AWS para implantar os primeiros fluxos de trabalho de IA em conformidade.

Para mais informações, a AWS disponibiliza as páginas de Segurança em Nuvem AWS — Conformidade HIPAA e a lista de Serviços Elegíveis para HIPAA.

Leituras complementares

• Conformidade HIPAA para soluções de IA generativa na AWS
• Modelo de Responsabilidade Compartilhada da AWS
• AWS Well-Architected Framework — Pilar de Segurança

Fonte

Amazon Nova Act is now HIPAA eligible (https://aws.amazon.com/blogs/machine-learning/amazon-nova-act-is-now-hipaa-eligible/)

O desafio de levar agentes de IA para produção em ambientes SaaS

Provedores de Software como Serviço (SaaS) que desenvolvem aplicações agênticas com múltiplos inquilinos (multi-tenant) enfrentam desafios arquiteturais que vão muito além das preocupações habituais de segurança e governança. Isolamento entre tenants, gerenciamento de identidade, observabilidade, atribuição de custos e mitigação do problema de “vizinho barulhento” são apenas alguns dos obstáculos que separam uma demonstração funcional de um ambiente de produção robusto.

Para endereçar esse cenário, a AWS anunciou o Amazon Bedrock AgentCore, um serviço gerenciado e serverless para construir, implantar e operar com segurança aplicações agênticas na AWS. O serviço oferece primitivos para deploy de agentes, hospedagem de servidores MCP (Model Context Protocol), além de suporte nativo a gerenciamento de identidade, memória, observabilidade e avaliações — tudo projetado para tornar arquiteturas multi-tenant mais simples de construir.

Dez componentes de design para agentes multi-tenant

A AWS detalhou dez componentes arquiteturais que precisam ser considerados ao projetar agentes multi-tenant com o AgentCore. Cada um exige decisões que equilibram isolamento, eficiência operacional e otimização de custos.

Os padrões de isolamento que permeiam todas essas decisões são três: Silo, Pool e Bridge. A escolha entre eles depende da estratégia de tiers do produto SaaS.

1. Runtime do agente: dedicado ou compartilhado

A decisão mais fundamental é como o runtime do agente é provisionado em relação aos tenants. Um runtime dedicado por tenant (padrão Silo) oferece a maior proteção contra o problema do vizinho barulhento e facilita auditorias de conformidade. Um runtime compartilhado reduz custos e overhead operacional, mas exige propagação rigorosa do contexto do tenant dentro do processo.

O AgentCore Runtime resolve essa tensão com computação baseada em microVMs isoladas por sessão. Cada sessão recebe seu próprio sistema de arquivos persistente, permitindo que os agentes mantenham estado entre etapas de uma interação sem risco de vazamento entre sessões. O contexto do tenant é injetado no ambiente de execução via cabeçalhos HTTP customizados — incluindo identificador do tenant, tier, preferências regionais, feature flags e entitlements.

2. Modelos: compartilhados, por tier ou fine-tuned

Modelos de fundação (FM — Foundation Models) compartilhados são o ponto de partida recomendado para a maioria dos deployments multi-tenant. Para casos que exigem terminologia específica, conformidade regulatória ou SLAs de performance, modelos fine-tuned por tenant se tornam necessários, embora introduzam maior complexidade operacional.

A AWS oferece, via Amazon Bedrock, uma seleção de grandes modelos de linguagem (LLM — Large Language Models) de diferentes provedores, além de suporte a fine-tuning com datasets próprios e importação de modelos customizados via Amazon Bedrock Custom Model Import.

3. Workflows: padrões Silo, Pool e Bridge

Workflows podem ser implementados como ferramentas MCP, endpoints de API ou habilidades do agente. O padrão Silo usa habilidades dedicadas por tenant, com toda a lógica de negócio isolada — máxima customização, mas manutenção separada por tenant. O padrão Pool usa habilidades compartilhadas. O padrão Bridge combina os dois: etapas comuns (autenticação, logging, tratamento de erros) ficam em habilidades compartilhadas, que invocam habilidades específicas do tenant em runtime para a lógica crítica de negócio.

4. RAG multi-tenant

Sistemas de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) exigem decisões de isolamento de dados. O padrão Silo usa bancos de dados vetoriais dedicados por tenant — recomendado para indústrias reguladas. O padrão Pool usa bancos vetoriais compartilhados com filtragem por metadados e controle de acesso por namespace, mais eficiente em custo para plataformas com muitos tenants pequenos e médios.

O Amazon Bedrock Knowledge Bases oferece capacidades gerenciadas de RAG com suporte a múltiplos bancos vetoriais e possibilidade de criar bases de conhecimento isoladas ou compartilhadas. Para orientações detalhadas, a AWS publicou referências sobre RAG multi-tenant com Amazon Bedrock Knowledge Bases e sobre multi-tenancy em aplicações RAG com filtragem de metadados.

5. Contexto do tenant, padrão act-on-behalf e propagação de tokens

Diferentemente de APIs determinísticas, agentes de IA são não-determinísticos e potencialmente autônomos. Um agente comprometido poderia fazer chamadas não autorizadas a serviços downstream, levando a roubo de credenciais, escalada de privilégios e o problema do “Confused Deputy”.

A AWS recomenda o padrão de delegação (Act-on-Behalf), em vez de impersonação completa. Nesse modelo, os tokens são transformados em cada fronteira de serviço com credenciais de escopo limitado e uma claim act (conforme o RFC 8693 do OAuth 2.0) que identifica o agente. O AgentCore Identity suporta a troca de token On-behalf-of, permitindo que agentes e servidores MCP troquem um token de acesso do usuário por um novo token com escopo restrito para um recurso downstream específico.

O contexto do tenant deve ser codificado em Tokens Web JSON (JWT — JSON Web Tokens) capturando três dimensões: Contexto de Segurança (claims padrão: iss, sub, exp, aud), Contexto do Tenant (tenant_id e escopos específicos) e Contexto da Requisição (atributos de domínio para lógica de negócio).

6. Controle de acesso granular para ferramentas MCP e APIs

Aplicações agênticas multi-tenant precisam restringir o acesso a servidores MCP por meio de políticas avaliadas em runtime — considerando cotas do tenant, permissões por tier e limites de uso. O AgentCore Policy intercepta e avalia todas as requisições dos agentes antes de permitir acesso a ferramentas, com políticas escritas em linguagem natural ou diretamente em Cedar.

Na camada de invocação, servidores MCP filtram as ferramentas disponíveis com base no tier do tenant, feature flags e limites de quota. O AgentCore Gateway permite que agentes acessem ferramentas de forma segura, transformando APIs e funções AWS Lambda em ferramentas compatíveis com agentes, com suporte a Amazon API Gateway, schemas OpenAPI, modelos Smithy, funções Lambda e servidores MCP.

Na camada de acesso a dados, políticas de Controle de Acesso Baseado em Atributos (ABAC — Attribute-Based Access Control) reforçam o isolamento usando condições do AWS Identity and Access Management (IAM — Identity and Access Management) para restringir o acesso a dados com base em tags e atributos do principal.

7. Memória: isolamento por namespace hierárquico

O gerenciamento de memória multi-tenant deve implementar cinco níveis lógicos: Global (conhecimento compartilhado entre tenants), Estratégia (padrões específicos por tipo de agente), Tenant (histórico e preferências do tenant), Usuário (contexto individual dentro do tenant) e Sessão (memória de curto prazo para conversas ativas).

O AgentCore Memory oferece isolamento por namespace hierárquico em todos esses níveis, com suporte a políticas baseadas em recursos e controle de acesso baseado em atributos para acesso granular. A implementação envolve construir identificadores compostos a partir de informações do tenant e do usuário (por exemplo, tenant_123:user_456) e prefixar todas as operações de memória com o caminho de namespace apropriado.

8. Identidade, confiança e descoberta de agentes

Conforme agentes interagem com outros agentes além das fronteiras organizacionais, três preocupações fundamentais emergem: identidade (quem é este agente e ele pode provar isso?), confiança (devo confiar neste agente?) e descoberta (como encontro o agente certo?).

O AgentCore Identity implementa identidades de agente como workload identities, com cada agente recebendo uma identidade verificável criptograficamente ancorada na conta AWS e na infraestrutura IAM da organização. Para confiança, a indústria ainda está trabalhando no problema — o Agent Naming Service (ANS) v2, atualmente um Internet-Draft da IETF (trabalho em andamento), ancora cada identidade de agente a um nome de domínio DNS, com três níveis de verificação: Bronze (PKI), Silver (PKI + DANE) e Gold (PKI + DANE + Transparency Log).

Para descoberta, o AWS Agent Registry, disponível via Amazon Bedrock AgentCore, oferece um catálogo centralizado para descobrir agentes, habilidades, servidores MCP e recursos customizados em uma organização, com busca por linguagem natural ou estruturada.

9. Rastreamento de custos por tenant e observabilidade

A atribuição precisa de custos em ambientes multi-tenant requer instrumentação a nível de aplicação que emita métricas tagueadas por tenant para cada invocação do agente, capturando tokens de entrada/saída, invocações de ferramentas e duração de execução. O AgentCore Observability oferece visibilidade em tempo real dos workflows dos agentes com integração compatível com OpenTelemetry, alimentada pelo Amazon CloudWatch.

10. Guardrails: segurança de conteúdo

Guardrails multi-tenant atuam em três pontos: pré-processamento (validação do input antes do processamento pelo agente, bloqueando prompt injections e sanitizando PII conforme requisitos de conformidade como HIPAA e PCI-DSS), pós-processamento (validação das respostas para precisão factual, detecção de alucinações e varredura por vazamento de dados sensíveis) e configurações por tenant ou tier.

O Amazon Bedrock Guardrails oferece filtragem de conteúdo e controles de segurança com políticas configuráveis para tópicos negados, filtros de conteúdo, filtros de palavras e redação de informações sensíveis.

Implementando os três padrões com o AgentCore

Padrão Silo

No modelo Silo, cada tenant opera dentro de uma stack totalmente isolada, com seu próprio AgentCore Runtime, AgentCore Gateway e AgentCore Memory, todos delimitados por fronteiras IAM separadas. O fluxo começa com a autenticação do usuário no provedor de identidade, que emite um JWT com o contexto do tenant. Um proxy da aplicação SaaS roteia a requisição para o agente correto com base nesse contexto, e o AgentCore Runtime valida o JWT, cria uma sessão microVM isolada e inicia o raciocínio do agente. Quando o agente precisa invocar ferramentas, chama o Gateway dedicado ao tenant, que valida o JWT, extrai o contexto e integra com os recursos backend específicos daquele tenant.

O trade-off é o maior overhead operacional, já que cada cliente executa recursos dedicados. Mas para workflows críticos de segurança e conformidade, o escopo limitado de impacto potencial justifica a escolha.

Padrão Pool

No modelo Pool, os recursos são compartilhados entre múltiplos tenants para maximizar a utilização e a eficiência operacional. O AgentCore Runtime e a lógica do agente são compartilhados, com o contexto do tenant extraído do JWT em cada execução. O AgentCore Memory é particionado com base no contexto do tenant usando namespace (por exemplo, actor_id: "tenant-a:user-123"). O Gateway centralizado roteia chamadas de ferramentas para recursos backend compartilhados, aplicando isolamento via credenciais e configurações com escopo por tenant.

O modelo Pool é altamente eficiente e pode ser a única opção viável quando há um grande número de tenants pequenos. O trade-off é a necessidade de maior rigor nos testes de controle de acesso granular e mais instrumentação para atribuição de custos por tenant.

Padrão Bridge

O modelo Bridge representa um meio-termo estratégico, combinando a eficiência de custo da infraestrutura compartilhada com os benefícios de segurança de recursos isolados. A ideia é poder escolher o nível de isolamento em cada camada e componente individualmente, em vez de estar preso a um padrão único. Por exemplo, é possível ter um AgentCore Runtime e Gateway siloed para tenants premium e um Runtime e Gateway pooled para tenants do tier padrão. Outra variação possível é um Runtime siloed com Gateway e ferramentas pooled.

Próximos passos

Este artigo cobre os conceitos fundamentais para construção de agentes multi-tenant. A AWS indicou que publicará posts subsequentes com implementações end-to-end dos modelos Pool e Silo, incorporando os componentes detalhados nas considerações de design. Para quem quiser colocar a mão na massa desde já, a AWS disponibilizou um workshop de agentes multi-tenant com experiência prática usando o Amazon Bedrock AgentCore.

Fonte

Building multi-tenant agents with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-multi-tenant-agents-with-amazon-bedrock-agentcore/)

Novas APIs para gerenciamento de identidades no AWS Managed Microsoft AD

Gerenciar identidades e acessos em ambientes complexos é um dos maiores desafios operacionais de times de segurança e infraestrutura. A AWS anunciou novas capacidades para o AWS Directory Service para Managed Microsoft Active Directory — conhecido como AWS Managed Microsoft AD — que permitem gerenciar usuários e grupos diretamente por meio de APIs, da Interface de Linha de Comando AWS (AWS CLI) e do console de gerenciamento da AWS.

Essas operações seguem o padrão Criar, Ler, Atualizar e Excluir (CRUD) e fazem parte de um conjunto chamado Directory Service Data APIs. Com elas, é possível realizar ações como:

• Listar usuários e grupos
• Consultar detalhes de usuários e grupos
• Desabilitar e habilitar contas de usuários
• Redefinir senhas de usuários
• Gerenciar membros de grupos

Essas APIs abrem um leque de possibilidades para integrar o gerenciamento do Active Directory a fluxos de trabalho existentes, aplicações personalizadas e ferramentas de terceiros.

Benefícios práticos da automação de identidades

A introdução dessas APIs traz impactos diretos em diferentes frentes do dia a dia operacional:

• Automação do ciclo de vida de identidades: é possível gerenciar contas de usuários de forma programática em todas as fases — desde a criação até a exclusão — simplificando os processos de entrada e saída de colaboradores.
• Segurança aprimorada: ao integrar essas APIs com serviços como o Amazon GuardDuty, é possível criar respostas automáticas a ameaças, como a desabilitação de contas com acessos inadequados.
• Conformidade melhorada: o gerenciamento automatizado de usuários ajuda a aplicar políticas consistentes e a manter a conformidade com requisitos regulatórios.
• Eficiência operacional: tarefas rotineiras como provisionamento, desprovisionamento e gerenciamento de grupos podem ser automatizadas, reduzindo esforço manual e o risco de erros humanos.
• Capacidade de integração: as APIs permitem integração fluida com sistemas de gerenciamento de identidades já existentes, aplicações personalizadas e ferramentas de terceiros.
• Otimização de custos: ao automatizar processos e reduzir intervenções manuais, as organizações podem potencialmente reduzir os custos operacionais associados ao gerenciamento de identidades.

Visão geral da solução de segurança automatizada

Para demonstrar o poder dessas novas APIs, a AWS apresenta uma solução prática que automatiza a detecção e a resposta a comportamentos inesperados de usuários do Active Directory. A arquitetura combina múltiplos serviços da AWS em um fluxo de automação de segurança robusto.

O funcionamento é o seguinte:

• O GuardDuty monitora continuamente comportamentos anômalos de usuários do AWS Managed Microsoft AD. No exemplo descrito, o tipo de alerta monitorado é o Backdoor:Runtime/C&CActivity.B!DNS.
• Uma regra do Amazon EventBridge detecta os alertas do GuardDuty relacionados a esses usuários e aciona um fluxo de trabalho no AWS Step Functions.
• O fluxo do Step Functions extrai o nome de usuário do Active Directory a partir da instância usando um comando do Systems Manager e, em seguida, inicia uma automação que desabilita a conta via a API DisableUser.
• Uma segunda regra do EventBridge monitora a chamada à API DisableUser e envia uma notificação por e-mail ao administrador usando o Serviço de Notificação Simples da Amazon (Amazon SNS).

A regra do EventBridge para capturar o alerta do GuardDuty é configurada assim:

{
  "detail-type": ["GuardDuty Finding"],
  "source": ["aws.guardduty"],
  "detail": {
    "type": ["Backdoor:Runtime/C&CActivity.B!DNS"]
  }
}

Já a regra que monitora a chamada à API de desabilitação de usuário tem o seguinte formato:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.ds"],
  "detail": {
    "eventSource": ["ds.amazonaws.com"],
    "eventName": ["DisableUser"]
  }
}

Essa solução entrega remediação automatizada em tempo quase real, reduzindo significativamente a janela de exposição e contendo o impacto de acessos não autorizados.

Observação importante: a solução deve ser implantada na Região AWS primária do diretório.

Pré-requisitos para implementar a solução

GuardDuty

O GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades inesperadas e comportamentos não autorizados para proteger contas AWS, cargas de trabalho e dados armazenados no Amazon Simple Storage Service (Amazon S3). Para ativá-lo, acesse o console do GuardDuty. Se for a primeira vez, selecione All Features e clique em Get Started. Se já utilizou o serviço antes, selecione Runtime Monitoring e clique em Enable.

AWS Managed Microsoft AD

O AWS Directory Service oferece um serviço totalmente gerenciado para o Microsoft Active Directory (AD) na nuvem AWS. Ao criar o diretório, a AWS implanta dois controladores de domínio exclusivos em Zonas de Disponibilidade separadas para garantir alta disponibilidade. Para cenários que exigem ainda mais resiliência e desempenho, é possível escalar o AWS Managed Microsoft AD adicionando controladores de domínio extras.

Para criar um novo AWS Managed Microsoft AD, acesse o console do Directory Service, escolha Set up directory, selecione AWS Managed Microsoft AD, escolha a edição Standard, informe o nome DNS do diretório e a senha, selecione a Nuvem Privada Virtual (VPC) desejada e clique em Create directory.

Criando um usuário de teste no Active Directory

Para simular a ameaça, é necessário criar um usuário de teste. Esse usuário será utilizado para acessar uma instância EC2 e executar um comando que simula atividade suspeita, resultando na desabilitação automática da conta.

Para criar o usuário, utilize o AWS CloudShell ou a AWS CLI na sua máquina local, substituindo o valor de --directory-id pelo ID do seu diretório:

# Create the test user
aws ds-data create-user \
  --directory-id "your-directory-id" \
  --sam-account-name "TestUser" \
  --given-name "Test" \
  --surname "User"

Em seguida, defina uma senha para o usuário:

aws ds reset-user-password \
  --directory-id "your-directory-id" \
  --user-name "TestUser" \
  --new-password "YourSecurePassword123!"

No exemplo, a senha utilizada é YourSecurePassword123!. Caso precise substituí-la por uma senha que atenda aos requisitos da sua organização, consulte a documentação sobre redefinição e habilitação de senha de usuário no AWS Managed Microsoft AD. Para mais detalhes sobre criação de usuários, veja o guia sobre como criar um usuário no AWS Managed Microsoft AD.

Instância EC2 de teste

Para gerar alertas no GuardDuty, é necessário ter uma instância Linux EC2 ingressada no domínio. Caso ainda não tenha uma, siga as instruções para ingressar uma instância Linux em um domínio do Active Directory. Essa instância será usada para simular a atividade suspeita que aciona o alerta do GuardDuty e inicia o fluxo de remediação automatizado.

Implantando a solução

A implantação é feita por meio de um template do CloudFormation. Após baixar o template, acesse o console do CloudFormation, escolha Create Stack com novos recursos, faça o upload do arquivo e preencha os parâmetros:

• DirectoryID: informe o ID do seu AWS Active Directory.
• NotificationEmail: informe o endereço de e-mail para receber as notificações.

Aceite a criação de recursos do Gerenciamento de Identidade e Acesso (IAM) com nomes personalizados e clique em Submit. Quando o status mudar para CREATE_COMPLETE, a solução estará pronta.

Testando a solução

Para simular uma ameaça, utilize um domínio de teste do GuardDuty que o serviço reconhece como servidor de comando e controle. Acesse o console do Amazon EC2, selecione a instância de teste criada anteriormente e conecte-se via Session Manager. Autentique-se com o usuário de teste usando o comando su seguido do usuário com o nome do domínio — por exemplo, su TestUser@example.com — e execute o comando:

curl guarddutyc2activityb.com

O comando retornará um erro porque a página não será resolvida, mas o GuardDuty terá detectado os eventos suspeitos. Em 3 a 5 minutos, um alerta de alta severidade do tipo Backdoor:Runtime/C&CActivity.B!DNS aparecerá no console do GuardDuty, acionando a automação que desabilita a conta. Após a desabilitação, uma notificação por e-mail será enviada ao administrador (podendo levar até 5 minutos para chegar).

Observação: antes de repetir o teste, é necessário arquivar o alerta do GuardDuty, pois a regra do EventBridge só é acionada uma vez para um alerta com os mesmos detalhes. Para arquivar, selecione o alerta Backdoor:Runtime/C&CActivity.B!DNS, clique em Actions e selecione Archive.

Conclusão

As novas APIs do AWS Directory Service para o AWS Managed Microsoft AD representam um avanço significativo para equipes que precisam gerenciar identidades de forma programática e segura. Ao combinar essas APIs com serviços como GuardDuty e Step Functions, é possível construir fluxos de automação sofisticados que fortalecem a postura de segurança e simplificam os processos de gerenciamento de identidades.

O caso de uso apresentado é apenas um dos muitos cenários possíveis. Para quem quiser explorar uma abordagem alternativa usando cmdlets do PowerShell com o AWS Systems Manager Run Command para desabilitar usuários, a AWS disponibiliza um post complementar: Como desabilitar automaticamente usuários no AWS Managed Microsoft AD com base em alertas do GuardDuty. Para mais informações sobre o serviço e suas APIs, consulte a documentação oficial do AWS Directory Service.

Fonte

Automating identity lifecycle and security with AWS Directory Service APIs (https://aws.amazon.com/blogs/security/automating-identity-lifecycle-and-security-with-aws-directory-service-apis/)

O que é o KY3P e por que isso importa

A Amazon Web Services (AWS) concluiu a avaliação de segurança do Conheça Seu Terceiro (KY3P), conduzida pela S&P Global. Com isso, os clientes da AWS passam a ter acesso a um relatório padronizado que pode simplificar bastante o processo de due diligence de fornecedores — especialmente para empresas de setores regulados, como o financeiro.

O KY3P, também conhecido como S&P Global Comprehensive Assessment (anteriormente chamado de TruSight), é uma avaliação validada e baseada em evidências. Seu propósito é apoiar a conformidade regulatória e facilitar a troca padronizada de dados de risco entre a AWS e seus clientes. O diferencial da metodologia é que ela vai além de políticas e declarações: ela valida a implementação e operação real dos controles de segurança.

O que a avaliação cobre

A metodologia de avaliação de risco do KY3P contempla mais de 200 controles distribuídos em 26 categorias e nove domínios de risco. Entre os temas abordados estão:

• Privacidade
• Gerenciamento de Redes
• Gerenciamento de Acesso Lógico
• Segurança Física e Ambiental

Os critérios de avaliação foram desenvolvidos por um consórcio de instituições financeiras líderes no mercado global. Isso confere ao KY3P um alto nível de reconhecimento e credibilidade junto a reguladores e auditores.

Como isso beneficia os clientes da AWS

Com a adoção da nuvem crescendo em ritmo acelerado em diferentes setores, a AWS se tornou um componente crítico nos ambientes de terceiros de muitas organizações. Clientes em setores regulados — como o financeiro — precisam cumprir exigências rigorosas de due diligence sobre seus fornecedores, e isso inclui provedores de nuvem.

O relatório KY3P permite que esses clientes mapeiem os controles da AWS em relação a frameworks e padrões amplamente utilizados, como:

• Estrutura de Cibersegurança do NIST versão 2 (NIST CSF v2)
• Padrão de Segurança de Dados da Indústria de Cartões de Pagamento versão 4.0 (PCI DSS 4.0)
• ISO 27001:2022

Isso significa que, em vez de conduzir avaliações independentes e repetitivas, as empresas podem usar os resultados do KY3P para obter visibilidade imediata sobre a cobertura de controles da AWS — reduzindo esforço operacional e acelerando processos de conformidade.

Como acessar o relatório

Para saber como obter acesso ao relatório, a AWS disponibiliza uma página dedicada. Mais informações estão disponíveis na página de avaliação AWS KY3P. Quem quiser explorar outros programas de conformidade da AWS também pode consultar os Programas de Conformidade da AWS.

Fonte

AWS KY3P report now available for third-party supplier due diligence (https://aws.amazon.com/blogs/security/aws-ky3p-report-now-available-for-third-party-supplier-due-diligence/)

O que foi anunciado

A AWS anunciou uma expansão significativa no Amazon CloudWatch Logs Insights: a linguagem de consulta do serviço passou a suportar 13 novos comandos e funções, ampliando consideravelmente as possibilidades de análise de logs diretamente na plataforma.

Para quem trabalha no dia a dia com observabilidade e monitoramento na AWS, essa atualização resolve uma série de limitações práticas que antes exigiam processamento externo ou gambiarras nas queries.

Quais são as novidades

Os novos recursos foram organizados em três categorias principais:

Funções de string e numéricas

• round — arredondamento de valores numéricos
• startswith — filtra registros cujo campo começa com determinado prefixo
• endswith — filtra registros cujo campo termina com determinado sufixo
• case — lógica condicional dentro da query
• regex_replace — substituição de padrões via expressão regular
• haversine — cálculo de distância geográfica entre coordenadas

Funções de codificação e decodificação

• urlencode e urldecode — codificação e decodificação de URLs
• base64encode e base64decode — codificação e decodificação de payloads em Base64 diretamente na query

Novos comandos de parsing e análise

• parse logfmt — faz o parsing de logs estruturados no formato logfmt, convertendo-os em campos individuais
• expand — expande arrays JSON aninhados em registros individuais
• relevantfields — identifica e exibe automaticamente os campos mais relevantes em grupos de logs com alta cardinalidade

Por que isso importa na prática

Quem analisa logs no CloudWatch Logs Insights frequentemente se deparava com situações como: precisar manipular strings diretamente na query, decodificar valores em Base64 sem sair da interface, fazer parsing de logs que não estavam em formato JSON, ou ainda calcular distâncias geográficas a partir de coordenadas registradas nos logs.

Com esses 13 novos recursos, a AWS reduz a necessidade de pré-processar ou transformar logs antes de consultá-los, tornando o fluxo de análise mais ágil e centralizado.

Disponibilidade

Todos os novos comandos e funções já estão disponíveis em todas as regiões comerciais da AWS. Para explorar os detalhes de uso e sintaxe de cada função, a AWS disponibiliza a documentação oficial do Amazon CloudWatch Logs.

Fonte

Amazon CloudWatch Logs Insights adds new query commands and functions (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cloudwatch-logs-insights/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do Amazon Aurora MySQL 8.4, versão compatível com o MySQL 8.4 da comunidade — uma versão de Suporte de Longo Prazo (LTS) do MySQL. A novidade traz compatibilidade com o MySQL 8.4.7 da comunidade e uma mudança importante na forma como as versões são numeradas.

Versionamento alinhado com a comunidade

A partir do Aurora MySQL 8.4, o número de versão que aparece no seu cluster passa a corresponder diretamente à versão do MySQL da comunidade com a qual ele é compatível. Isso simplifica bastante o entendimento de qual base de código está sendo executada. Além disso, a AWS continua gerenciando os patches subjacentes automaticamente, reduzindo o trabalho operacional do dia a dia.

A AWS também definiu metas públicas de atualização: versões principais serão lançadas em até 12 meses após o lançamento de uma versão LTS da comunidade, versões menores em até 3 meses, e uma versão LTS menor do Aurora em até 12 meses após cada versão principal. Para acompanhar os objetivos de lançamento por engine, a AWS disponibilizou a agenda de lançamentos open source do Aurora e RDS.

Segurança reforçada por padrão

O Aurora MySQL 8.4 chega com configurações de segurança mais rígidas para novos clusters. Os destaques são:

• TLS obrigatório por padrão, com suporte apenas a TLS 1.2 e 1.3
• Novas contas utilizam o plugin de autenticação caching_sha2_password
• Políticas de validação de senha configuráveis via grupos de parâmetros do cluster de banco de dados

Verificações automáticas antes do upgrade

Antes de o cluster ficar offline durante uma atualização, verificações automatizadas de pré-upgrade identificam possíveis problemas de compatibilidade. Isso dá mais confiança para quem precisa migrar de versões anteriores. Para entender melhor a experiência completa do cliente com essa versão, a AWS publicou o blog de lançamento do Aurora MySQL 8.4.

Como fazer o upgrade ou a migração

Existem três caminhos para atualizar um banco de dados existente para o Aurora MySQL 8.4:

• Amazon RDS Blue/Green Deployments
• Upgrade in-place
• Restauração a partir de um snapshot

Para detalhes sobre como realizar upgrades de versão principal, o Guia do Usuário do Amazon Aurora é o ponto de partida recomendado.

Para quem está migrando de fontes MySQL externas, as opções disponíveis são o AWS Database Migration Service ou o Percona XtraBackup.

Disponibilidade

O Aurora MySQL 8.4 já está disponível em todas as regiões da AWS onde o Aurora MySQL é suportado. Para começar a usar, a AWS disponibiliza uma página de introdução ao Amazon Aurora.

Fonte

Amazon Aurora MySQL 8.4 is now generally available (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-aurora-mysql/8-4/)

Visibilidade de identidade agora dentro do Security Hub

A AWS anunciou uma atualização relevante para equipes de segurança: o AWS Security Hub agora é capaz de identificar riscos de identidade originados por acessos não utilizados. Permissões, funções (roles) e credenciais do Gerenciamento de Identidade e Acesso (IAM) que estão ociosas passam a ser detectadas diretamente no mesmo console centralizado onde as equipes já acompanham ameaças, exposições e achados de postura de segurança.

Antes dessa mudança, gerenciar riscos de identidade em centenas de contas AWS exigia alternar entre múltiplas ferramentas, sem uma visão unificada que conectasse permissões não utilizadas à exposição real de recursos. Agora, esses riscos de identidade aparecem lado a lado com os demais achados de segurança, permitindo que as equipes priorizem a remediação com base no risco organizacional real.

Como funciona na prática

Ao habilitar o Security Hub para a organização, um IAM Access Analyzer vinculado ao serviço é criado automaticamente em cada conta membro — sem nenhuma configuração adicional necessária. A partir daí, o Security Hub:

• Avalia os principais do IAM com base em 90 dias de atividade de acesso real;
• Detecta acessos não utilizados nesse período;
• Correlaciona os achados de identidade com o contexto de exposição, ajudando as equipes a focar nos riscos que realmente importam.

Além disso, o serviço oferece a geração sob demanda de políticas de menor privilégio recomendadas, baseadas nos padrões de uso real. Isso ajuda as equipes a refinarem as permissões do IAM e a reduzirem a superfície de ataque da organização.

Parte de uma evolução maior

A AWS posiciona essas capacidades como um passo fundamental em direção a um gerenciamento mais amplo de direitos de infraestrutura em nuvem dentro do Security Hub. Tudo isso entregue com os mesmos fluxos de trabalho, regras de automação e integrações downstream já existentes na plataforma — sem quebrar o que as equipes já usam.

Disponibilidade e custo

Essas funcionalidades estão incluídas no Security Hub Essentials sem custo adicional. Para saber mais sobre como os achados de acesso não utilizado funcionam, a AWS disponibiliza documentação detalhada no Guia do Usuário do AWS Security Hub e na página do produto AWS Security Hub. A lista completa de regiões onde o serviço está disponível pode ser consultada na Lista de Serviços Regionais da AWS.

Fonte

AWS Security Hub now uncovers identity risks from unused access (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-hub-unused-access/)

O que mudou no Security Hub Extended

A AWS anunciou a expansão do plano Security Hub Extended, que passa a contar com 21 soluções parceiras curadas organizadas em 9 categorias de segurança. Sete novos fornecedores foram incorporados nesta rodada de atualizações:

• SentinelOne — segurança de endpoint
• CyberArk — segurança de identidade
• Sublime — segurança de e-mail
• Varonis — segurança de dados
• LayerX — segurança de navegador
• Native Security — segurança em nuvem
• Zenity — segurança de Inteligência Artificial (IA)

Com essa ampliação, as equipes de segurança ganham mais flexibilidade para montar uma stack que realmente se encaixe nas necessidades da sua organização, podendo escolher entre líderes consolidados de mercado e fornecedores em ascensão dentro de cada domínio.

O que é o Security Hub Extended

O Security Hub Extended é um plano do AWS Security Hub desenhado para simplificar a forma como empresas adquirem, implantam e integram uma solução de segurança corporativa de pilha completa. Ele cobre as seguintes camadas:

• Endpoint
• Identidade
• E-mail
• Rede
• Dados
• Navegador
• Nuvem
• Inteligência Artificial (IA)
• Operações de segurança

A proposta é reunir soluções da própria AWS e de parceiros em um único ponto de controle, facilitando a identificação e a resposta a riscos que atravessam diferentes fronteiras tecnológicas.

Como os dados das soluções parceiras chegam ao Security Hub

Um ponto técnico importante: todas as soluções participantes emitem seus alertas e descobertas de segurança no padrão Esquema Aberto de Segurança Cibernética (OCSF — Open Cybersecurity Schema Framework). Isso significa que os dados chegam automaticamente agregados dentro do AWS Security Hub, sem necessidade de integrações manuais ou transformações de formato.

Modelo comercial: sem amarras de longo prazo

Do ponto de vista comercial, a AWS estruturou o plano com algumas características que tendem a facilitar a adoção em ambientes corporativos:

• Precificação pay-as-you-go publicada e transparente para todas as soluções
• Fatura única consolidada na AWS
• Elegibilidade automática ao Programa de Desconto Empresarial (EDP — Enterprise Discount Program)
• Suporte unificado de Nível 1 para clientes do AWS Enterprise Support
• Sem compromissos de longo prazo

Disponibilidade

As sete novas soluções parceiras já estão disponíveis em todas as regiões comerciais da AWS onde o Security Hub opera. Para verificar quais regiões são suportadas, consulte a tabela de regiões da AWS.

Para detalhes sobre preços, acesse a página de preços do AWS Security Hub. Para começar a explorar o plano, o acesso pode ser feito pelo console do AWS Security Hub ou pela página do produto.

Fonte

Security Hub Extended expands to 21 curated partner solutions across 9 categories (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-hub-extended/)

O problema central: LLMs não são atores confiáveis

Agentes de IA têm uma característica fundamental que os diferencia de sistemas tradicionais: eles se adaptam. Encontram múltiplos caminhos para resolver um problema, tomam decisões em tempo real e operam com autonomia. Essa flexibilidade é justamente o que os torna úteis — mas também é o que cria um desafio sério de segurança.

O Modelo de Linguagem Grande (LLM) no coração de um agente é não determinístico. Suas decisões não podem ser previstas ou garantidas antecipadamente. Ele pode alucinar ações prejudiciais com total confiança. É vulnerável a ataques de injeção de prompt, nos quais adversários inserem comandos maliciosos por meio de respostas de ferramentas ou entradas do usuário. Para um LLM, comandos e dados são a mesma coisa — apenas tokens.

Por isso, do ponto de vista de segurança, a abordagem correta é tratar o LLM como um ator não confiável. Isso não é pessimismo; é defesa em profundidade.

A boa notícia é que o LLM não age diretamente sobre o mundo externo. Ele precisa passar por um orquestrador que invoca ferramentas com base em sua saída. É exatamente nesse ponto de passagem que os controles precisam ser aplicados. O que se precisa nessa fronteira é de autorização: uma decisão sobre se cada invocação de ferramenta deve ser permitida e sob quais condições.

Por que as abordagens comuns não são suficientes

Dois caminhos costumam ser adotados para lidar com esse problema, mas ambos têm limitações importantes:

• Fluxos de trabalho hard-coded: eliminam a incerteza, mas também eliminam o propósito de usar um LLM como cérebro do agente. Você acaba construindo uma aplicação tradicional com uma interface de LLM. Além disso, mesmo com essa restrição, usar saídas de LLM em qualquer etapa reabre os mesmos riscos.
• Humano no loop (human-in-the-loop): oferece uma rede de segurança para operações críticas e sempre terá seu papel. Mas depender disso como mecanismo principal de controle sacrifica a autonomia e pode gerar fadiga de aprovação.

O que se precisa é de uma camada de aplicação auditável e determinística que fique fora do agente e das ferramentas. Por quê fora? Porque o plano do LLM é exatamente a coisa que não se pode confiar — ele não pode ser responsável por aplicar suas próprias restrições. Controles na camada do LLM, como prompts de sistema e alinhamento em tempo de treinamento, podem ser contornados por injeção de prompt ou alucinação. Verificações hard-coded no código do agente ou das ferramentas são mais robustas, mas tornam-se difíceis de auditar e gerenciar em escala, especialmente quando a lógica de segurança está espalhada por muitas ferramentas e serviços.

Centralizar a autorização fora de ambos fornece um único ponto de verificação que o LLM não pode contornar — auditável e verificável independentemente do código da aplicação.

Onde entram as Políticas do AgentCore

O Amazon Bedrock AgentCore Gateway fica entre o agente e as ferramentas remotas que ele acessa. Quando uma Política do AgentCore é associada a um Gateway, tudo é bloqueado por padrão. As políticas abrem seletivamente essa fronteira, especificando quais invocações de ferramentas são permitidas e sob quais condições. Essa aplicação vale para todo o tráfego de ferramentas roteado pelo Gateway.

O Amazon Bedrock AgentCore oferece a infraestrutura para implantar e gerenciar agentes em escala. Ele inclui o AgentCore Runtime para hospedar agentes, o AgentCore Gateway para gerenciar como os agentes se conectam a ferramentas usando o Protocolo de Contexto de Modelo (MCP), e a Policy no AgentCore. A Policy intercepta todo o tráfego do agente pelos gateways e avalia cada requisição contra as políticas definidas antes de permitir o acesso à ferramenta.

Para que essa abordagem escale, as políticas precisam ser mais simples de entender do que o comportamento do agente. E é aí que entra o Cedar.

O que é o Cedar e por que foi escolhido

Cedar é uma linguagem de políticas de autorização de código aberto desenvolvida pela AWS que recentemente ingressou na Cloud Native Computing Foundation (CNCF). Ele foi projetado com propriedades específicas: é construído exclusivamente para autorização, legível por humanos e analisável por máquinas usando raciocínio automatizado.

Linguagem natural é ambígua demais para infraestrutura crítica de segurança. Linguagens de programação de uso geral, como Python, são muito expressivas, mas difíceis de analisar — podem ter efeitos colaterais não intencionais, problemas de terminação e são difíceis de entender. O Cedar evita esses problemas excluindo loops e operações com estado, então a avaliação de políticas termina em tempo O(n) nos casos comuns. Esse tempo de execução limitado significa que os agentes podem tomar decisões de autorização sem prejudicar a experiência do usuário.

Como o Cedar é usado pelo AgentCore

A AgentCore Policy usa o Cedar e suas capacidades de análise matemática em vários pontos do fluxo de trabalho do AgentCore Gateway: o motor de autorização Cedar é usado na avaliação de políticas, e o Cedar Analysis é usado durante a criação de políticas e no plano de controle.

Criação de políticas com IA neuro-simbólica

Desenvolvedores podem escrever políticas Cedar diretamente ou usar linguagem natural que é traduzida para Cedar por meio de um loop de feedback de IA neuro-simbólica. Essa abordagem combina a flexibilidade do aprendizado de máquina com a exatidão provável do raciocínio automatizado: um LLM gera políticas a partir da linguagem natural, enquanto o Cedar Analysis as valida usando raciocínio simbólico e matemático.

O fluxo funciona assim: um administrador especifica — em linguagem natural — quais ferramentas MCP o agente pode chamar e sob quais condições. O loop neuro-simbólico formaliza essa descrição em políticas Cedar. Primeiro, o LLM traduz a linguagem natural em políticas Cedar. Em seguida, essas políticas passam por dois estágios de verificação.

No primeiro estágio, a AgentCore Policy usa um gerador de schema que recebe as descrições das ferramentas MCP e produz um schema Cedar. O Cedar valida as políticas contra esse schema, ajudando a garantir que elas referenciem ferramentas e parâmetros válidos e eliminando classes inteiras de erros em tempo de execução. Se a validação passar, o segundo estágio executa o Cedar Analysis, que codifica cada política como uma fórmula matemática e detecta problemas como políticas que concedem ou negam tudo, ou que contêm condições impossíveis.

Plano de controle

Ao associar políticas a um AgentCore Gateway, o Cedar Analysis realiza uma análise holística de todo o conjunto de políticas. Em vez de analisar políticas isoladamente, ele examina como elas interagem e qual é o efeito combinado. Essa análise identifica possíveis erros lógicos — como políticas conflitantes ou redundantes — e detecta se o conjunto de políticas produz resultados de autorização não intencionais.

Aplicação na invocação de ferramentas MCP

Cada requisição de ferramenta feita ao gateway do AgentCore é avaliada contra as políticas Cedar, que determinam se a invocação da ferramenta MCP com os argumentos fornecidos deve ser permitida. Isso cria o envelope de segurança enquanto permite as pontes necessárias para que o agente realize seu trabalho.

Filtragem de ferramentas MCP

O Cedar habilita uma camada adicional de proteção que opera antes de qualquer invocação de ferramenta. Quando um agente emite um comando de listagem de ferramentas, o AgentCore Gateway usa a capacidade de avaliação parcial do Cedar para determinar quais ações sempre seriam negadas sob o conjunto de políticas atual. Essas ações são omitidas da resposta de listagem de ferramentas. O agente e o LLM subjacente nunca veem essas ações de ferramentas, eliminando uma classe inteira de risco: o agente não pode tentar invocar uma ferramenta que não sabe que existe.

Legibilidade: políticas que auditores entendem

Conformidade regulatória e auditorias de segurança exigem políticas que humanos possam entender e verificar. As políticas Cedar se leem como linguagem natural estruturada, tornando-as acessíveis a equipes de segurança, responsáveis por conformidade e partes interessadas do negócio. Veja um exemplo do artigo original:

// Only allow bulk discounts for premium customers with sufficient quantity
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
) when {
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Platinum" &&
  context.input.orderQuantity >= 50
} unless {
  context.input
    .productTypes
    .containsAny (
      ["limited_edition", "seasonal_specials"]
    )
};

Auditores sem formação técnica conseguem entender essa política: “Permitir descontos em volume para clientes Platinum que pedem pelo menos 50 itens, exceto para produtos de edição limitada ou especiais de temporada.” A cláusula unless torna a exceção clara, que é como as regras de negócio são tipicamente expressas em linguagem natural.

Vale notar que essa única política restringe duas fontes de dados diferentes. O nível do cliente vem de uma declaração de Token Web JSON (JWT) — não pode ser alucinado ou manipulado pelo LLM. As entradas da ferramenta, como quantidade do pedido e tipos de produto, porém, originam-se da chamada de ferramenta do LLM. As políticas Cedar restringem essas entradas apenas a valores permitidos, garantindo que mesmo se o LLM produzir argumentos inesperados, a camada de aplicação de políticas os rejeite deterministicamente.

Análise formal para verificação de políticas

As políticas Cedar podem ser codificadas como fórmulas matemáticas e analisadas usando técnicas de raciocínio automatizado por meio de um codificador simbólico. A análise de políticas, incluindo comparação de políticas, está disponível como uma ferramenta CLI de código aberto.

Detectando erros lógicos

O Cedar Analysis pode detectar quando políticas contêm erros lógicos. Por exemplo, o artigo original mostra uma política com restrições contraditórias — o nível do cliente não pode ser simultaneamente “Gold” e “Platinum”. A intenção era usar || em vez de &&, um erro que tanto humanos quanto sistemas de IA podem cometer ao criar políticas. O Cedar Analysis também detecta políticas que sempre permitem uma determinada ação, geralmente uma indicação de política excessivamente permissiva.

// This policy cannot allow any requests due to logical errors
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
) when {
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  principal.getTag("customer_tier") == "Platinum"
} unless {
  context.input.refundAmount > 1000
};

Detectando conflitos entre políticas

O Cedar Analysis também analisa o conjunto completo de políticas para detectar inconsistências entre políticas individuais diferentes. O artigo original apresenta um exemplo onde uma política permit permite que clientes Gold processem reembolsos abaixo de $100, enquanto uma política forbid bloqueia clientes Gold (e Platinum) de processar reembolsos abaixo de $500. Como forbid tem precedência sobre permit no Cedar, a política forbid bloquearia todos os reembolsos de clientes Gold apesar da política permit.

Comparando mudanças de políticas

Ao atualizar políticas, o Cedar Analysis pode determinar o impacto exato de uma mudança. O artigo original mostra um exemplo onde uma modificação na cláusula unless — aparentemente mais restritiva à primeira vista — na verdade torna a política mais permissiva. O Cedar Analysis detecta isso automaticamente e gera uma tabela mostrando a diferença em permissividade entre o conjunto original e o atualizado:

Principal type    Action              Resource type    Status
OAuthUser         ProcessRefund       Gateway          Equivalent
OAuthUser         ApplyBulkDiscount   Gateway          More permissive

Essa capacidade de verificação formal é essencial quando agentes operam autonomamente e podem afetar o mundo real. Organizações precisam de certeza matemática de que suas políticas se comportarão conforme o esperado.

Comportamento determinístico para governança confiável

Ao contrário dos modelos probabilísticos de IA, a segurança empresarial exige garantias determinísticas. As políticas Cedar sempre produzem a mesma decisão de autorização para requisições idênticas, independentemente da ordem de avaliação ou do estado do sistema. A semântica padrão do Cedar — negar por padrão, forbid vence, sem ordenação — ajuda a garantir comportamento previsível.

De políticas para produção

O Raciocínio automatizado já provou seu valor em toda a AWS, desde o AWS IAM Access Analyzer verificando políticas de acesso até segurança comprovável para configurações de rede. Aplicar essas mesmas técnicas à IA agêntica é uma extensão natural: à medida que os agentes assumem mais responsabilidades, a necessidade de garantias matematicamente fundamentadas só cresce.

A abordagem neuro-simbólica descrita — combinando a flexibilidade do LLM com o rigor do raciocínio automatizado — aponta para um futuro onde agentes podem ser ao mesmo tempo mais autônomos e mais confiáveis, porque a verificação acompanha a autonomia.

A Policy já está disponível como parte do Amazon Bedrock AgentCore Gateway. Para saber mais sobre o Cedar e suas capacidades, visite o site do Cedar, experimente o Cedar playground ou participe da comunidade Cedar no Slack da CNCF. Para mais informações sobre a Policy no Amazon Bedrock AgentCore Gateway, consulte a documentação da AWS ou explore o console do AgentCore Gateway.

Fonte

Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows (https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/)

Uma nova forma de adotar segurança enterprise

A AWS publicou o terceiro artigo da série sobre o Security Hub Extended, e desta vez o foco não é técnico — é filosófico. O texto explica por que a solução foi construída da forma que foi, e defende que o modelo tradicional de aquisição de produtos de segurança enterprise está pronto para uma transformação fundamental.

Se você acompanhou os posts anteriores da série, já sabe o que é o Security Hub Extended: na primeira publicação, a AWS apresentou o produto como uma expansão significativa do Security Hub que reúne soluções de parceiros curados em uma experiência unificada. Na segunda publicação, o foco foi técnico — fluxo de integração, modelo de preços e a camada de operações unificada baseada no Open Cybersecurity Schema Framework (OCSF). Agora, o texto dá um passo atrás para discutir a motivação por trás de tudo isso.

O problema com o modelo atual de aquisição

Quem já tentou avaliar um novo produto de segurança enterprise conhece bem o processo: solicitar uma demonstração, esperar, assistir à demo, pedir uma Prova de Conceito (PoC), aguardar a equipe de serviços profissionais configurar tudo, negociar preços que não estão publicados em lugar nenhum, envolver o setor de compras e, por fim, assinar um contrato de múltiplos anos. Meses depois, você finalmente descobre se o produto resolve ou não o seu problema no seu ambiente específico.

Enquanto isso, um engenheiro de segurança mais ágil da sua equipe já instalou uma ferramenta de código aberto, conectou dados reais e, em duas horas, sabe se a solução funciona para os casos de uso da empresa. Ele não precisou de apresentação de slides. Precisou de algo que pudesse colocar as mãos.

A AWS ilustra esse ponto com um relato emblemático: um CISO de uma empresa Fortune 500 afirmou ter levado 9 meses para contratar uma solução de segurança — e que ela ainda não funcionava da forma como foi demonstrada. Essa frustração, segundo a AWS, não é exceção. É a norma.

O artigo é cuidadoso ao não demonizar o modelo de vendas tradicional. Vendas assistidas evoluíram por boas razões: procurement enterprise é complexo, produtos precisam de customização e clientes precisam de suporte. O ponto central é outro: as ameaças evoluem constantemente, e os times de defesa precisam de flexibilidade para descobrir e implantar novas soluções na mesma velocidade em que o cenário muda.

O que duas décadas de AWS ensinaram sobre adoção em escala

A AWS argumenta que passou vinte anos aprendendo como permitir que clientes adotem tecnologia enterprise complexa nos seus próprios termos e em escala massiva. Computação, armazenamento, bancos de dados, Inteligência Artificial e Aprendizado de Máquina (IA/ML), redes e segurança — tudo adotado via console, no ritmo de cada cliente, escalado quando estavam prontos.

Serviços como Amazon GuardDuty, Amazon Inspector, AWS Shield e AWS Security Hub estão disponíveis no Console de Gerenciamento da AWS, todos com modelo de pagamento por uso (pay-as-you-go) e ativados com um clique. Dezenas de milhares de clientes — de startups de duas pessoas a grandes instituições financeiras — adotam esses serviços da mesma forma: experimentam, percebem o valor, expandem e aprofundam o uso.

Segundo a AWS, chegar a esse ponto exigiu um mindset de produto diferente: o tempo para obter valor (time-to-value) se torna a métrica mais importante, a fricção no processo de integração (onboarding) vira o maior inimigo e a transparência de preços passa a ser inegociável. Não foi um caminho sem erros — o texto é honesto sobre isso —, mas os resultados são claros: quando clientes adotam com base na experiência e não no compromisso, eles não apenas ficam, como expandem o uso e se tornam defensores do produto.

A lógica por trás do Security Hub Extended

Com essa base estabelecida, a AWS se fez a pergunta que originou o Security Hub Extended: por que não construir uma abordagem similar para soluções de parceiros líderes de mercado? Por que empresas como CrowdStrike, Splunk, Zscaler e inovadores emergentes como Cyera, Noma e 7AI não poderiam chegar até os clientes com a mesma experiência sem fricção que os serviços nativos da AWS têm?

O argumento é que esses parceiros construíram produtos incríveis, mas nem sempre tiveram um canal para colocar esses produtos diretamente nas mãos dos clientes que mais precisam deles, no momento certo, em escala, de forma tão natural quanto ativar um serviço da AWS.

É exatamente isso que o Security Hub Extended propõe ser: não uma substituição da forma como os parceiros constroem ou vendem, mas uma infraestrutura que permite que seus produtos falem por si mesmos.

Como funciona na prática

Para equipes que já utilizam o Security Hub, as soluções de parceiros curados ficam disponíveis para descoberta diretamente ao lado dos serviços de segurança da AWS. O modelo é:

• Um clique para avaliar, um clique para implantar
• Preços pay-as-you-go na fatura existente da AWS, com descontos do Programa de Desconto Enterprise (EDP) aplicados automaticamente
• Sem ciclo de procurement separado e sem compromissos de longo prazo obrigatórios
• Possibilidade de começar rápido, validar em escala e, quando estiver pronto, assumir compromissos para descontos maiores

Mas o Security Hub Extended não é apenas uma forma mais simples de comprar produtos de segurança. É também uma solução unificada. Quando um cliente habilita uma solução pelo Extended, a AWS trabalha para que a experiência seja integrada de ponta a ponta:

• Sensores implantados automaticamente em workloads do Amazon EC2, Amazon EKS e AWS Fargate, usando o mesmo mecanismo do GuardDuty Runtime Monitoring
• Funções do IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso) provisionadas em toda a Organização com um clique
• Inventário de recursos automatizado desde o primeiro dia — buckets S3, bancos de dados, workloads de IA — sem trabalho manual
• Soluções emitem findings no formato OCSF, automaticamente agregados no Security Hub ao lado de findings do GuardDuty, Inspector e demais serviços de segurança da AWS

O Security Hub aplica pontuação de risco e análise correlacionada em todos eles — findings nativos da AWS e de terceiros juntos, ponderados e priorizados em uma visão única da postura de segurança.

Correlação que nenhuma solução isolada consegue

Um dos pontos mais relevantes do artigo é a capacidade de correlação entre soluções. Um exemplo citado: uma detecção de endpoint pelo CrowdStrike, correlacionada com um roubo de credencial identificado pelo GuardDuty e um evento de acesso a dados detectado pelo Cyera, produz um caminho de ataque (attack path) que nenhuma dessas soluções conseguiria gerar sozinha.

Essa correlação usa o contexto nativo da AWS — topologia do IAM, exposição de VPC (Virtual Private Cloud — Nuvem Privada Virtual), criticidade dos recursos — para enriquecer o contexto de cada caminho de ataque para os analistas de segurança. Habilitar uma solução pelo Security Hub Extended não adiciona mais um painel isolado. Aprofunda a inteligência do painel que você já tem.

A AWS também menciona que está desenvolvendo resposta automatizada: os clientes poderão optar por playbooks pré-construídos que tomam ações via serviços nativos da AWS quando uma ameaça é detectada — como isolar recursos comprometidos, revogar credenciais ou conter ameaças ativas. O objetivo declarado é chegar a uma resposta em segundos, não nas horas que leva hoje para alternar entre cinco consoles e dois sistemas de tickets.

Onde o produto está hoje e para onde vai

A AWS é transparente sobre o estágio atual: ainda é o “primeiro inning”, ou o famoso “Dia 1” da cultura Amazon. O produto foi lançado em fevereiro de 2026 com 14 parceiros e já conta com 21, cobrindo endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA e operações de segurança.

O feedback mais recorrente dos clientes, segundo o artigo, é que a simplificação do procurement e a flexibilidade do pay-as-you-go com preços públicos — mesmo antes de considerar os benefícios de operações unificadas e normalização de dados — já representam um diferencial significativo.

Para quem quiser explorar, o Security Hub Extended já está disponível. Basta acessar o Security Hub, buscar pelo plano Security Hub Extended ou visitar a página de preços do Security Hub Extended. O modelo é pay-as-you-go, sem compromisso. A recomendação da AWS é começar pelo que resolve o problema mais urgente — a equipe saberá se está funcionando em dias, não em meses.

Para compartilhar feedback, a AWS indica o AWS re:Post para o Security Hub ou o suporte da AWS.

Por que isso importa para equipes de segurança brasileiras

O Security Hub Extended representa uma mudança de paradigma relevante para qualquer equipe de segurança que opera na AWS. A proposta de consolidar soluções de parceiros líderes de mercado dentro do mesmo fluxo operacional dos serviços nativos — com preços transparentes, sem procurement demorado e com correlação automática de dados — resolve uma dor real e conhecida por qualquer profissional de segurança que já passou por um processo de avaliação enterprise tradicional.

O produto ainda está em evolução, e a própria AWS reconhece isso com transparência. Mas a direção é clara, e os sinais iniciais de adoção descritos no artigo indicam que a aposta está ressoando com o mercado.

Fonte

AWS Security Hub Extended: Why enterprise security products should sell themselves (https://aws.amazon.com/blogs/security/aws-security-hub-extended-why-enterprise-security-products-should-sell-themselves/)