A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 P6-B200 na região US East (N. Virginia) para uso com o SageMaker Notebook Instances. Essa expansão regional representa um passo importante para equipes que trabalham com treinamento e ajuste fino de modelos de inteligência artificial de grande porte diretamente no ambiente gerenciado da AWS.
Hardware por trás das instâncias P6-B200
As instâncias P6-B200 são equipadas com 8 GPUs NVIDIA Blackwell e 1.440 GB de memória de GPU de alta largura de banda, além de processadores Intel Xeon de 5ª geração (codinome Emerald Rapids). Esse conjunto de hardware entrega até 2x mais desempenho em treinamento de IA quando comparado às instâncias P5en — o que representa um salto considerável para cargas de trabalho intensivas.
Para que servem essas instâncias
O foco principal das P6-B200 é o desenvolvimento interativo e o ajuste fino de grandes modelos de fundação, incluindo:
LLMs — Modelos de Linguagem de Grande Escala (Large Language Models)
Modelos de mistura de especialistas (mixture of experts)
Modelos de raciocínio multimodal
Com esse poder computacional disponível diretamente nos notebooks gerenciados, equipes de ciência de dados e engenharia de ML conseguem experimentar com modelos maiores sem precisar provisionar infraestrutura separada.
Ambientes de desenvolvimento suportados
As instâncias P6-B200 funcionam nos ambientes JupyterLab e CodeEditor dentro do SageMaker, permitindo experimentação ágil com modelos generativos voltados para aplicações como:
Copilotos corporativos (enterprise copilots)
Geração de conteúdo em texto, imagens e vídeo
Como começar
Para quem quiser configurar e explorar esses recursos, a AWS disponibiliza guias para desenvolvedores cobrindo tanto o JupyterLab quanto o CodeEditor no contexto do SageMaker Studio e das instâncias de notebook do SageMaker. A documentação oficial é o ponto de partida recomendado para entender as etapas de configuração e os requisitos de cada ambiente.
A AWS anunciou que o Amazon EMR agora oferece suporte ao Apache Spark 4.0.2 em disponibilidade geral, contemplando os três modelos de implantação do serviço. A novidade traz um conjunto relevante de melhorias para quem trabalha com pipelines de dados, controle de acesso e aplicações em tempo real.
Principais capacidades do Spark 4.0.2 no EMR
Pipelines de dados com ANSI SQL
Uma das mudanças mais práticas é o suporte nativo ao ANSI SQL padrão, o que torna a engenharia de dados acessível a um público mais amplo. Com isso, não é mais necessário aprender a sintaxe específica do Spark para construir e manter pipelines — quem já conhece SQL consegue trabalhar de forma produtiva desde o início.
Suporte a dados semiestruturados com VARIANT
O Spark 4.0.2 introduz suporte nativo a JSON e outros dados semiestruturados por meio dos tipos de dados VARIANT. Isso oferece mais flexibilidade para lidar com formatos de dados variados, sem a necessidade de transformações complexas antes do processamento.
Controle de acesso granular (FGAC)
O Controle de Acesso Refinado (FGAC — Fine-Grained Access Control) agora pode ser aplicado tanto em operações de leitura quanto de escrita nas tabelas registradas no AWS Lake Formation, dentro dos jobs do Apache Spark. Isso permite definir permissões no nível de linha ou coluna, aumentando a precisão no controle de quem acessa o quê.
Apache Iceberg v3 para governança e conformidade
O suporte ao formato de tabela Apache Iceberg v3 complementa as capacidades de segurança ao oferecer garantias de transação mais robustas e rastreamento de linhagem de dados. O resultado são trilhas de auditoria adequadas para atender a exigências regulatórias e fortalecer os frameworks de conformidade e governança.
Streaming aprimorado para aplicações em tempo real
Os controles de streaming foram aprimorados para simplificar o gerenciamento de operações stateful complexas e melhorar o monitoramento. Isso permite colocar em produção aplicações em tempo real com mais agilidade — casos de uso como detecção de fraudes, personalização e outros cenários sensíveis ao tempo são diretamente beneficiados.
Disponibilidade e como começar
O Apache Spark 4.0.2 está disponível em todas as regiões onde o Amazon EMR já opera. Para quem está migrando a partir de uma versão anterior, a AWS disponibiliza o agente de atualização do Apache Spark, uma ferramenta que acelera o processo de upgrade de aplicações EMR existentes.
Para criar uma nova aplicação EMR com Spark 4.0.2, basta acessar o Console de Gerenciamento da AWS e seguir o fluxo padrão de criação.
A AWS anunciou uma expansão no suporte do Amazon Bedrock ao AWS Service Quotas, o serviço centralizado de gerenciamento de cotas da plataforma. A partir de agora, os clientes conseguem visualizar as cotas de inferência do endpoint bedrock-mantle diretamente pelo console de Service Quotas — da mesma forma que já faziam com o endpoint bedrock-runtime e outros serviços da AWS.
Na prática, isso significa que equipes de engenharia e arquitetura ganham uma visão clara e padronizada dos limites que se aplicam às suas cargas de trabalho no Bedrock, sem precisar consultar documentação separada ou abrir chamados para descobrir qual é o teto de requisições disponível.
O que é o endpoint bedrock-mantle
O bedrock-mantle é o endpoint do Amazon Bedrock que oferece compatibilidade com três APIs amplamente utilizadas no mercado de Inteligência Artificial (IA) generativa:
OpenAI Responses API
OpenAI Chat Completions API
Anthropic Messages API
Essa compatibilidade permite que times que já possuem aplicações construídas sobre OpenAI ou Anthropic migrem para o Amazon Bedrock com mudanças mínimas no código. É uma porta de entrada direta para quem quer aproveitar a infraestrutura gerenciada da AWS sem reescrever integrações do zero.
O que ficou visível com esta atualização
Com a expansão do suporte a Service Quotas, o endpoint bedrock-mantle passa a expor, por modelo, as seguintes cotas:
Tokens de entrada por minuto (input-tokens-per-minute)
Tokens de saída por minuto (output-tokens-per-minute)
Essa granularidade por modelo é especialmente útil para equipes que trabalham com múltiplos modelos de fundação simultaneamente e precisam planejar a capacidade de cada um de forma independente.
Como acessar as cotas no console
O acesso é simples e segue o fluxo padrão do AWS Service Quotas:
Abra o console do AWS Service Quotas
Selecione Amazon Bedrock
Pesquise por “Bedrock Mantle” para visualizar as cotas disponíveis
Para solicitar aumento de qualquer uma dessas cotas, basta seguir o processo padrão de aumento de limites do Amazon Bedrock.
Disponibilidade por região
O suporte a Service Quotas para o endpoint bedrock-mantle está disponível em todas as regiões da AWS onde o endpoint é oferecido:
Para o público brasileiro, vale destacar a presença da região de São Paulo, o que garante baixa latência para aplicações hospedadas localmente.
Por que isso importa
Ter visibilidade de cotas de forma proativa é fundamental para quem opera em escala de produção. Sem esse tipo de informação, equipes costumam descobrir os limites apenas quando os erros começam a aparecer — o que pode significar interrupções inesperadas em aplicações críticas. Com essa atualização, o Amazon Bedrock se alinha ao padrão já consolidado de outros serviços da AWS, tornando o planejamento de capacidade mais previsível e menos reativo.
Suporte a instâncias P5.4xl no SageMaker Notebook Instances
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 P5.4xl no SageMaker Notebook Instances. Essa novidade coloca poder computacional de alto nível diretamente nas mãos de quem trabalha com aprendizado profundo (DL — Deep Learning) e computação de alta performance (HPC — High Performance Computing) dentro do ambiente de notebooks gerenciados da AWS.
O que são as instâncias P5.4xl?
As instâncias Amazon EC2 P5.4xl são equipadas com GPUs NVIDIA H100 Tensor Core, consideradas referência de mercado para cargas de trabalho intensivas em IA. De acordo com a AWS, elas entregam até 4x mais velocidade na resolução de problemas em comparação com instâncias EC2 baseadas em GPU da geração anterior, além de uma redução de até 40% no custo de treinamento de modelos de aprendizado de máquina (ML — Machine Learning).
Para quais aplicações são indicadas?
As instâncias P5 são indicadas para treinar e implantar modelos complexos, como Grandes Modelos de Linguagem (LLMs — Large Language Models) e modelos de difusão que alimentam aplicações de IA generativa. Entre os casos de uso destacados pela AWS estão:
Resposta a perguntas (question answering)
Geração de código
Geração de vídeo e imagem
Reconhecimento de fala (speech recognition)
Disponibilidade por região
As instâncias Amazon EC2 P5.4xl já estão disponíveis no SageMaker Notebook Instances nas seguintes regiões da AWS:
US East (N. Virginia e Ohio)
US West (Oregon)
Asia Pacific (Mumbai, Tokyo e Jakarta)
South America (São Paulo)
A inclusão da região de São Paulo é especialmente relevante para equipes e empresas brasileiras que precisam manter dados e processamento dentro do território nacional ou em conformidade com requisitos de latência e residência de dados.
O mundo dos agentes de Inteligência Artificial (IA) está evoluindo rapidamente. A expectativa é que bilhões de agentes de IA generativa operem de forma autônoma, tomando decisões e executando tarefas sem intervenção humana. Para suportar esse cenário, a AWS desenvolveu o Amazon Bedrock AgentCore, uma plataforma modular e totalmente gerenciada para construir, implantar e operar agentes de IA em escala.
Nesse novo contexto, um obstáculo concreto surge quando esses agentes precisam acessar serviços pagos: APIs com cobrança por uso, conteúdo premium e ferramentas que exigem assinatura. O problema se desdobra em várias camadas:
Integrar carteiras de pagamento de terceiros exige gerenciar autenticação, controle de acesso e segurança das credenciais.
A maioria das transações vale centavos, mas métodos tradicionais como cartão de crédito cobram taxas fixas por transação (por exemplo, USD $0,30), tornando micropagamentos economicamente inviáveis.
Protocolos de pagamento para agentes, como o x402 — um dos protocolos populares de pagamento máquina a máquina — têm variações de versão e complexidades que demandam meses de trabalho para integrar corretamente.
Sem guardrails de orçamento, um agente autônomo pode gastar além do limite previsto, especialmente quando múltiplos pagamentos ocorrem em paralelo.
É exatamente para resolver esse conjunto de desafios que a AWS lançou o Amazon Bedrock AgentCore Payments, disponível em preview. O serviço promete reduzir o esforço de integração de meses para dias.
O que é o AgentCore Payments
O AgentCore Payments é o primeiro serviço gerenciado dentro do Amazon Bedrock AgentCore focado em pagamentos. Ele permite que agentes de IA executem micropagamentos de forma autônoma para APIs pagas, servidores MCP (Protocolo de Contexto de Modelo) e conteúdo, com poucas linhas de código.
Os principais recursos oferecidos são:
Pagamentos instantâneos para serviços externos pagos, sem necessidade de configuração manual de cobrança por provedor.
Suporte a stablecoins para micropagamentos economicamente viáveis, incluindo transações abaixo de um centavo.
Guardrails de gastos configuráveis para controle granular de orçamento e limites de transação por agente ou sessão.
Para autenticar carteiras de pagamento com segurança, o AgentCore Payments utiliza o AgentCore Identity. O desenvolvedor cria um payment connector — um recurso de integração específico por provedor de pagamento. Esse conector provisiona automaticamente um provedor de credenciais no AgentCore Identity, que armazena as credenciais em um cofre seguro de tokens e emite tokens de acesso tokenizados sem expor as credenciais brutas.
O serviço suporta assinaturas criptográficas EdDSA, ECDSA e ES256 para operações com carteiras. O material criptográfico fica armazenado no AWS Secrets Manager e nunca é retornado pelas APIs. Na camada de entrada, o serviço impõe autenticação dupla — OAuth e AWS SigV4 — no mesmo pipeline de requisição.
Orquestração de protocolos de pagamento
O cenário de protocolos de pagamento agênticos é fragmentado, com múltiplos padrões competindo entre si. Para resolver isso, o AgentCore Payments oferece um motor de orquestração de pagamentos que fica entre o agente e os provedores de pagamento, expondo uma única interface processPayment.
Essa interface recebe uma requisição de pagamento e retorna uma prova de pagamento que o agente pode apresentar para acessar o serviço pago. O orquestrador gerencia automaticamente fluxos de pagamento em múltiplas etapas, tentativas e casos extremos para protocolos como o x402 (incluindo as versões 1 e 2, que diferem na estrutura dos campos exigidos). O modelo é plugável: adicionar suporte a um novo protocolo não exige mudanças na lógica central nem na API exposta ao desenvolvedor.
Controle de orçamento em tempo real
Agentes são autônomos por natureza, o que torna o controle de gastos um requisito crítico de infraestrutura. O AgentCore Payments implementa limites de gasto na camada de infraestrutura por meio de um fluxo transacional de três fases:
Fase 1 — Reserva: o valor solicitado é deduzido atomicamente do saldo disponível antes de qualquer processamento.
Fase 2 — Processamento: o pagamento é processado pelo provedor.
Fase 3 — Confirmação ou rollback: em caso de sucesso, a transação é confirmada; em caso de falha, o valor reservado é restaurado ao saldo disponível.
Esse protocolo garante que, mesmo com múltiplos agentes transacionando simultaneamente contra o mesmo orçamento, não haja leituras desatualizadas, sobrescritas ou gastos além do limite.
Observabilidade completa dos pagamentos
Para agentes que transacionam de forma autônoma, visibilidade total é indispensável. O AgentCore Payments entrega um sistema de observabilidade em três pilares, publicado diretamente na conta AWS do desenvolvedor, sem necessidade de instrumentação de código:
Métricas no Amazon CloudWatch: contagens de sucesso, falha e latência por operação. A operação processPayment também emite o valor gasto por tipo de token.
Logs estruturados entregues via pipeline assíncrono e em lote, com contexto do recurso de pagamento e ID de requisição para correlação.
Rastreamento distribuído baseado em propagação de contexto W3C com spans compatíveis com OpenTelemetry, enriquecidos com atributos de pagamento como valor gasto, orçamento restante e telemetria da cadeia de assinatura.
Antes de registrar no AgentCore Payments, é necessário obter credenciais de API do provedor de pagamento escolhido. Para Stripe, utiliza-se a chave secreta de API do Stripe Dashboard. Para Coinbase, cria-se uma chave de API na Coinbase Developer Platform, que emite um par de nome de chave e chave privada.
O código abaixo, usando o AgentCore SDK, realiza toda a configuração inicial em uma única chamada:
Com o payment manager configurado, o próximo passo é criar um instrumento de pagamento referenciando o manager e o conector. O instrumento é essencialmente uma carteira embarcada — um endereço de carteira autocustodial gerenciado pelo usuário final. Após a criação, o instrumento precisa ser financiado e a autorização de assinatura deve ser concedida antes que o agente possa transacionar.
A sessão de pagamento define o limite financeiro do agente: quanto pode ser gasto e por quanto tempo. O ID da sessão e o ID do instrumento são passados ao agente quando sua tarefa começa. O agente não pode estender sua sessão nem gastar além dos limites configurados.
Quando o agente chama um endpoint pago e recebe uma resposta HTTP 402 Payment Required, o AgentCore Payments entende o protocolo x402 e sabe exatamente como gerar a prova de pagamento necessária para desbloquear o serviço:
Para ilustrar o funcionamento na prática, imagine um analista financeiro que pede ao seu agente de IA: “Analise as ações da Amazon e compare com benchmarks do setor.” O agente precisa de três fontes pagas: uma API de dados financeiros (USD $0,50 por consulta), um fornecedor de análise de cadeia de suprimentos (USD $1,20 por relatório) e uma base de dados de benchmarks (USD $0,80 por dataset).
O backend da aplicação cria uma sessão com orçamento de USD $10,00 e passa o ID da sessão e o ID do instrumento ao agente. O agente chama cada serviço, recebe HTTP 402 de cada um, e o AgentCore Payments verifica o orçamento atomicamente, assina a transação pelo provedor de carteira configurado e retorna a prova criptográfica. O agente faz a tentativa novamente com a prova e recebe o conteúdo pago.
Três fornecedores, três pagamentos, uma chamada de API cada. Gasto total: USD $2,50 de um orçamento de USD $10,00. O analista recebe a análise completa sem intervenção manual.
O mesmo fluxo funciona independentemente do framework de agente utilizado (Strands Agents, LangChain, etc.) e do modelo de linguagem escolhido — seja Claude da Anthropic, GPT da OpenAI, Gemini do Google ou Llama da Meta.
Integração com outros serviços do AgentCore
Como os pagamentos operam na camada de chamada de ferramentas, eles funcionam naturalmente com outros serviços do AgentCore:
AgentCore Gateway — descobre ferramentas MCP pagas no Coinbase x402 Bazaar sem registro por provedor. Uma única stack de pagamento dá acesso a mais de 10.000 endpoints.
AgentCore Memory — armazena resultados de pesquisas entre sessões. Se o agente já comprou um relatório anteriormente, a memória recupera o resultado sem novo pagamento.
AgentCore Tools — ferramentas gerenciadas como Browser e Code Interpreter funcionam no mesmo fluxo. O Browser navega em sites com paywall e paga pelo conteúdo inline.
AgentCore Runtime — ao implantar o agente com agentcore deploy, o papel ProcessPaymentRole é aplicado no nível de infraestrutura.
Ataques recentes à cadeia de suprimentos e por que isso importa
Desde setembro, diversos ataques notáveis à cadeia de suprimentos de software foram registrados no npm Registry: Shai-Hulud, Chalk/Debug, um abuso de tokens do tea.xyz e, mais recentemente, o axios. Graças a esforços da comunidade envolvendo a equipe do Amazon Inspector, a Open Source Security Foundation e outros colaboradores, os pacotes afetados foram rapidamente identificados, reduzindo o impacto desses incidentes.
Ataques como o Shai-Hulud exploram vulnerabilidades em duas frentes: contas de mantenedores comprometidas que publicam pacotes maliciosos e ambientes de consumidores que baixam e executam esses pacotes. O ataque Shai-Hulud teve sucesso porque credenciais de mantenedores foram comprometidas via phishing, permitindo que agentes de ameaça publicassem versões maliciosas de pacotes populares.
Incidentes como esses reforçam a necessidade de práticas de segurança robustas na cadeia de suprimentos de software. A defesa eficaz exige abordar ambos os lados: mantenedores de pacotes precisam de proteções que previnam comprometimento de contas e limitem a propagação quando credenciais são roubadas; consumidores de pacotes precisam de defesas em camadas que detectem pacotes maliciosos, impeçam sua implantação e limitem danos quando um comprometimento ocorre.
Diagrama do fluxo de ataque Shai-Hulud — fonte: Aws
Usar credenciais temporárias e conceder privilégio mínimo
Quando o Shai-Hulud foi executado em ambientes de desenvolvimento e pipelines de Integração e Entrega Contínua (CI/CD), ele escaneou segredos como tokens npm, tokens GitHub e chaves de acesso do AWS Identity and Access Management (IAM). Credenciais de longa duração expostas dessa forma permitiram que agentes de ameaça propagassem o malware e acessassem recursos em nuvem.
Incidentes recentes mostraram organizações descobrindo múltiplos pares de credenciais IAM vazados, com preocupações sobre credenciais adicionais expostas e potencial comprometimento de pipelines CI/CD.
A remoção de credenciais de longa duração dos ambientes de desenvolvimento e pipelines CI/CD reduz o escopo de exposição caso um sistema seja comprometido. Para desenvolvedores trabalhando localmente, o novo comando de login da AWS CLI (aws login) simplifica a aquisição de credenciais CLI de curta duração e elimina a necessidade de armazenar credenciais de longa duração em arquivos de configuração. O AWS IAM Identity Center também oferece uma forma direta de adquirir credenciais temporárias que expiram automaticamente.
Para pipelines CI/CD, a federação via OpenID Connect (OIDC) com GitHub Actions, GitLab CI ou outras plataformas fornece credenciais temporárias para cada job sem armazenar tokens de longa duração. O IAM também pode federar identidades AWS para serviços externos, permitindo que workloads na AWS acessem serviços externos de forma segura sem credenciais de longo prazo.
Credenciais temporárias expiram automaticamente, limitando a janela de exposição caso um pipeline seja comprometido. Para serviços de terceiros que não suportam credenciais temporárias, a recomendação é armazenar as credenciais em um serviço centralizado como o AWS Secrets Manager ou o AWS Systems Manager Parameter Store, limitando o acesso a esses segredos, exigindo credenciais temporárias e aplicando rotação automática com registro de auditoria.
Resumo das recomendações para reduzir risco de exposição de credenciais
Usar credenciais temporárias: Federar usuários de um provedor de identidade central para a AWS e usar IAM roles para acesso. SEC02-BP02: Usar credenciais temporárias.
Em caso de incidente de segurança onde credenciais possam ter sido expostas, a orientação é rotacionar imediatamente todas as credenciais de longa duração. Utilizar o Amazon GuardDuty e o AWS CloudTrail para detectar atividade IAM anômala e identificar quais credenciais podem ter sido comprometidas.
Implementar defesa em profundidade
Mesmo com credenciais temporárias e privilégio mínimo, uma única conta comprometida pode permitir que agentes de ameaça publiquem pacotes maliciosos ou acessem recursos sensíveis. A defesa em profundidade cria múltiplas camadas de proteção que trabalham juntas para prevenir a propagação após o comprometimento inicial.
O princípio-chave é garantir que, se uma credencial ou conta for comprometida, controles adicionais impeçam que esse comprometimento se espalhe pela organização. Isso inclui Autenticação Multifator (MFA) para acesso combinada com diferentes IAM roles para workloads sensíveis.
Para projetos open source de desenvolvedor único, o MFA se torna ainda mais crítico porque não há separação de funções através de múltiplos mantenedores. Em ambientes de equipe, exigir múltiplos aprovadores para liberar pacotes para produção cria separação de funções. A aprovação multi-parte deve ser implementada dentro do próprio pipeline para implantações sensíveis — garantindo que mesmo se credenciais de um desenvolvedor forem comprometidas e ele disparar um deploy, o pipeline exija aprovação adicional antes de liberar para produção.
Para consumidores de pacotes, fluxos de aprovação múltipla em pipelines de implantação ajudam a garantir que, se um pacote malicioso passar pela varredura inicial, a revisão humana possa identificar mudanças suspeitas antes da implantação em produção.
Assinatura de artefatos como parte da defesa em profundidade
A assinatura de artefatos fornece uma camada criptográfica complementar que funciona junto com os controles de processo. O ataque Shai-Hulud teve sucesso porque credenciais comprometidas de mantenedores permitiram publicar pacotes maliciosos diretamente no registro npm público. Para consumidores de pacotes, a defesa é garantir que pacotes obtidos de registros públicos não alcancem produção sem verificação.
Ao vincular criptograficamente um pacote ou imagem de contêiner à identidade que o produziu, a assinatura cria uma camada de verificação independente da credencial usada para disparar o build — significando que uma credencial de desenvolvedor comprometida sozinha não é suficiente para introduzir um artefato não verificado no pipeline de implantação.
O AWS Signer fornece assinatura criptográfica para pacotes, criando uma camada adicional de verificação. O modelo de autorização de assinatura separa responsabilidades: credenciais de desenvolvedor não devem ter permissões de assinatura. Apenas roles de pipeline CI/CD devem ter permissões de assinatura através da API signer:StartSigningJob. O Signer usa Módulos de Segurança de Hardware (HSMs) validados FIPS 140-3 Nível 3 para armazenar chaves de assinatura.
O fluxo de assinatura de imagens de contêiner funciona da seguinte forma:
O Amazon ECR chama o Signer com o digest da imagem e o perfil de assinatura
O Signer verifica as permissões do perfil e assina o digest usando chaves armazenadas em HSMs validados FIPS 140-3 Nível 3
A assinatura é armazenada junto à imagem no Amazon ECR usando formato de artefato OCI (Open Container Initiative)
No momento da implantação, controladores de admissão (Kyverno para Amazon EKS, lifecycle hooks para Amazon ECS) verificam assinaturas antes de permitir a implantação
Diagrama do fluxo de assinatura com AWS Signer — fonte: Aws
Os benefícios do Signer em comparação com a construção de infraestrutura de assinatura personalizada incluem:
Totalmente gerenciado: Sem necessidade de construir infraestrutura customizada ou gerenciar ciclo de vida de certificados
Automatizado: A assinatura gerenciada do ECR acontece automaticamente no push da imagem sem etapas manuais
Governança centralizada: Um único perfil de assinatura pode ser usado em múltiplas contas e pipelines
Integração nativa: Integração com Notation e Kyverno para verificação de assinatura no Amazon EKS
Conformidade FIPS 140-3 Nível 3: Atende requisitos regulatórios rigorosos para operações criptográficas
O registro de auditoria para todas as operações de assinatura permite detectar padrões incomuns, como assinatura a partir de novos endereços IP, horários incomuns ou sucessão rápida de jobs de assinatura.
Centralizar o gerenciamento de dependências
Ao centralizar o gerenciamento de pacotes e dependências, é possível validar e aprovar dependências antes de serem usadas em aplicações e auditar rapidamente dependências em caso de incidente de segurança na cadeia de suprimentos.
Na AWS, o AWS CodeArtifact permite hospedar e gerenciar os pacotes de software da organização. A configuração de grupos de pacotes permite definir uma lista aprovada de fontes upstream e bloquear acesso a todas as outras — um controle direto contra ataques de typosquatting, onde pacotes maliciosos são publicados com nomes que se assemelham a pacotes legítimos. Em vez de depender dos desenvolvedores para identificar nomes suspeitos na hora da instalação, a configuração de grupo de pacotes impõe a barreira no nível do repositório.
A centralização também permite fixar versões de dependências para evitar que atualizações automáticas puxem versões maliciosas, e remover rapidamente dependências comprometidas em todo o portfólio de software quando um incidente ocorre.
Para pacotes npm especificamente, as atestações de proveniência fornecem um controle complementar no lado do consumidor. Disponíveis desde o npm 9.5, as atestações vinculam um pacote publicado ao repositório de código-fonte específico e ao fluxo CI/CD que o produziu, usando Sigstore como infraestrutura de assinatura subjacente. Quando um pacote é instalado, a CLI do npm pode verificar que o artefato publicado corresponde à proveniência de build atestada.
Escanear dependências ao longo do ciclo de vida de desenvolvimento
A AWS disponibiliza serviços para escanear dependências continuamente, do desenvolvimento à implantação:
No desenvolvimento: O Kiro pode realizar análise de composição de software durante revisões de código para identificar código de terceiros vulnerável.
Em repositórios de código e pipelines: O Amazon Inspector escaneia código próprio, dependências de terceiros e Infraestrutura como Código (IaC) em busca de vulnerabilidades.
Para imagens de contêiner: O Amazon Inspector fornece varredura contínua de vulnerabilidades em imagens no Amazon ECR. Também pode ser integrado diretamente em pipelines CI/CD para escanear imagens antes de serem enviadas ao ECR ou implantadas.
Scanners de vulnerabilidade tradicionais focam em CVEs conhecidos — vulnerabilidades divulgadas publicamente com identificadores atribuídos. Ataques à cadeia de suprimentos como o Shai-Hulud envolvem pacotes maliciosos que funcionam como zero-days: são intencionalmente criados por agentes de ameaça e explorados ativamente antes de um CVE ser atribuído. Scanners tradicionais baseados em bancos de dados de CVE não detectarão esses pacotes até que sejam formalmente identificados e catalogados, o que pode levar dias ou semanas.
Detectar essas ameaças requer análise comportamental em escala e colaboração da comunidade, não apenas correspondência estática de assinaturas. A escala operacional da AWS — com inteligência de ameaças de fontes como MadPot e dados de resposta a incidentes de milhões de clientes — permite a detecção de comportamento suspeito de pacotes em múltiplos ambientes simultaneamente.
Quando um pacote recém-publicado exibe comportamento de coleta de credenciais em múltiplas contas de clientes em poucas horas após a publicação, esse sinal entre contas permite identificação rápida. Essas descobertas são contribuídas para bancos de dados mantidos pela comunidade como o OpenSSF Malicious Packages Repository, que atribui um identificador formal (MAL-ID) e o compartilha com a comunidade de segurança. Para a campanha de token farming do tea.xyz, o tempo médio entre submissão e identificação formal foi de aproximadamente 30 minutos.
Um modelo de ameaça relacionado importante é o pacote “dorminhoco” (sleeper package): um pacote que aparenta ser benigno na publicação e ativa comportamento malicioso apenas após um atraso ou condição de gatilho. A análise estática sozinha é insuficiente para capturar esses pacotes porque o payload malicioso não está presente ou ativo no momento da instalação. A análise comportamental do Amazon Inspector é projetada especificamente para detectar essa classe de ameaça.
Listas de Materiais de Software (SBOMs) nos formatos SPDX ou CycloneDX permitem avaliar rapidamente a exposição durante incidentes. No incidente Shai-Hulud, os pacotes comprometidos (MAL-2025-46974 e CVE-2025-59144) foram identificados precocemente, fornecendo achados acionáveis para remediação rápida. Para orientações adicionais: SEC11-BP02: Automatizar testes ao longo do ciclo de vida de desenvolvimento e lançamento.
Configurar logging e monitoramento
A visibilidade sobre atividades é essencial para detectar comportamento anômalo precocemente. As recomendações incluem:
Habilitar logging de aplicações e serviços
Centralizar e monitorar logs entre contas
Usar o GuardDuty para monitorar continuamente atividade maliciosa e chamadas de API anômalas
O logging do CloudTrail fornece trilhas de auditoria para acesso a credenciais e atividade de API. Ao responder a incidentes de cadeia de suprimentos, deve-se revisar logs do CloudTrail para eventos específicos que indicam comprometimento de credenciais ou atividade maliciosa:
Chamadas sts:AssumeRole de endereços IP ou regiões inesperadas
Chamadas secretsmanager:GetSecretValue ou ssm:GetParameter de fontes desconhecidas
Chamadas ecr:PutImage de estações de trabalho de desenvolvedores, contornando pipelines CI/CD
Chamadas lambda:UpdateFunctionCode fora de janelas normais de implantação
Chamadas iam:CreateAccessKey seguidas de atividade imediata de API
Chamadas codecommit:GitPush ou codebuild:StartBuild de endereços IP incomuns
Quando combinado com regras do Amazon EventBridge, é possível disparar respostas automatizadas quando o Amazon Inspector detecta pacotes maliciosos ou quando esses padrões incomuns de acesso a credenciais ocorrem. Para orientações adicionais: SEC04: Detecção.
Arquitetura de defesa completa com as camadas de prevenção, controle, verificação, detecção e resposta — fonte: Aws
Incidentes recentes como Shai-Hulud, Chalk/Debug e tea.xyz refletem esforços contínuos de agentes de ameaça para atacar registros de pacotes, pipelines CI/CD e credenciais de desenvolvedores visando maior superfície de ataque e propagação. Uma única conta de mantenedor comprometida ou pacote malicioso pode se propagar simultaneamente em milhares de ambientes de consumidores.
Os controles descritos neste artigo foram projetados com esse modelo de ameaça em mente: credenciais temporárias limitam o valor de tokens roubados; gerenciamento centralizado de dependências e bloqueio de upstream reduzem a superfície de ataque no nível do registro; assinatura de artefatos garante que mesmo se um pipeline de build for comprometido, artefatos não assinados não alcancem produção; e varredura de dependências ao longo do ciclo de vida do software ajuda a identificar pacotes comprometidos precocemente. Cada camada estreita a janela de oportunidade para um agente de ameaça.
A Amazon Web Services (AWS) mantém um time global especializado em resposta a incidentes de segurança chamado AWS CIRT — sigla para Customer Incident Response Team (Equipe de Resposta a Incidentes de Clientes). Esse time opera 24 horas por dia, 7 dias por semana, e é composto por engenheiros de segurança que atuam diretamente em eventos ativos nos ambientes dos clientes.
É importante entender o escopo de atuação do AWS CIRT dentro do Modelo de Responsabilidade Compartilhada da AWS: o time foca no lado do cliente — ou seja, na segurança dentro da nuvem, não na infraestrutura física gerenciada pela própria AWS. Quando um cliente enfrenta acesso não autorizado, exfiltração de dados ou ransomware em seu ambiente AWS, é exatamente aí que o CIRT entra em ação.
Como acionar o suporte em caso de incidente ativo
Se você está passando por um evento de segurança ativo agora, o caminho mais direto é abrir um chamado de suporte. Veja como fazer isso corretamente:
Deixe claro na descrição do chamado que se trata de um incidente de segurança urgente.
Abrir o chamado a partir da conta comprometida permite que a AWS confirme a titularidade da conta e gere um número de acompanhamento. Se você tiver um time de conta (TAM, Account Manager ou Solutions Architect), pode acionar essa equipe para iniciar uma escalada. E caso tenha perdido o acesso à sua conta, ainda é possível enviar uma solicitação de assistência por outro canal.
O que o AWS CIRT faz durante um engajamento
Durante um atendimento, o AWS CIRT concentra sua análise nos logs de serviços AWS e no plano de controle da nuvem. As principais fontes utilizadas são AWS CloudTrail, Amazon VPC Flow Logs e findings do Amazon GuardDuty. A partir dessas fontes, o time realiza triagem, análise e contenção do incidente, além de oferecer recomendações para evitar recorrências.
Vale destacar um ponto importante: para investigações que vão além do plano de controle AWS — como análise de sistema operacional, memória ou revisão de código de aplicação — a recomendação é complementar o suporte do CIRT com um parceiro especializado da AWS em forense digital e resposta a incidentes (DFIR).
Catálogo de Técnicas de Ameaças para AWS (TTC)
Um dos recursos mais valiosos desenvolvidos pelo AWS CIRT é o Threat Technique Catalog for AWS (TTC) — Catálogo de Técnicas de Ameaças para AWS. O TTC nasceu como uma referência interna: o time precisava registrar e compartilhar os padrões que se repetiam entre os engajamentos, evitando que a mesma análise fosse refeita do zero a cada novo caso. Com o tempo, ficou evidente que esse conhecimento seria valioso para todos os clientes, e o catálogo foi tornado público.
O TTC é baseado na MITRE ATT&CK Cloud Matrix e documenta táticas, técnicas e procedimentos (TTPs) de agentes de ameaça específicos para ambientes AWS, com orientações de detecção e mitigação para cada entrada. É possível filtrar por serviços AWS presentes no seu ambiente para focar no que é mais relevante para a sua realidade. As descobertas do TTC também alimentam a lógica de detecção de serviços como o Amazon GuardDuty, fortalecendo as proteções automatizadas dos clientes.
Ferramentas open source disponibilizadas pelo CIRT
Além do catálogo de ameaças, o AWS CIRT abriu o código de diversas ferramentas desenvolvidas internamente para resolver problemas recorrentes nos engajamentos. Essas ferramentas complementam — e não substituem — o conjunto de segurança já existente no seu ambiente. Para uma visão abrangente de como estruturar um programa de resposta a incidentes, o ponto de partida recomendado é o Guia de Resposta a Incidentes de Segurança da AWS.
AWS Customer Playbook Framework: frameworks de resposta baseados nas lições aprendidas pelo CIRT em eventos reais de segurança.
AWS CloudSaga: ferramenta para testar controles e alertas de segurança no ambiente AWS, simulando eventos baseados em cenários reais observados pelo CIRT.
O AWS CIRT também mantém cinco workshops públicos, atualizados regularmente para simular eventos de segurança atuais. Os temas cobertos são: uso não autorizado de credenciais IAM, ransomware no Amazon S3, cryptomining, SSRF no IMDSv1 e ferramentas de preparação para resposta a incidentes.
Para participar, basta ter uma conta AWS e conexão com a internet. Os workshops são construídos com base nos mesmos cenários que o time usa internamente para treinamento — a ideia é tornar esse aprendizado acessível para qualquer profissional que queira se preparar melhor para resposta a incidentes na nuvem.
Como entrar em contato com o AWS CIRT
Qualquer cliente AWS pode acionar o CIRT por meio de um chamado de suporte, independentemente do plano contratado. Clientes que possuem um time de conta dedicado também podem iniciar uma escalada diretamente por esse canal. Para clientes com Enterprise Support ou Unified Operations, há ainda a opção de contratar o AWS Security Incident Response, um serviço gerenciado voltado para triagem e resposta a eventos de segurança.
Para feedbacks ou dúvidas, o CIRT pode ser contactado pelo e-mail aws-cirt@amazon.com. Por fim, recomenda-se também assinar os AWS Security Bulletins via feed RSS para receber notificações sobre eventos de segurança nos serviços AWS.
A AWS anunciou a expansão do Amazon GuardDuty Malware Protection for AWS Backup com suporte a backups contínuos do Amazon S3. Com essa novidade, equipes de segurança e operações podem escanear backups contínuos do S3 em busca de malware e identificar, ao longo de toda a linha do tempo de backup, quais pontos estão limpos e seguros para uma eventual recuperação.
O que muda na prática
Antes dessa atualização, a proteção contra malware do GuardDuty para o AWS Backup não alcançava os backups contínuos do S3 — um tipo de backup que captura alterações de forma incremental e permite restaurar dados para qualquer ponto no tempo. Agora, essa lacuna foi preenchida.
Com o novo suporte, é possível:
Habilitar varreduras completas ou incrementais de malware para backups contínuos do S3 diretamente dentro do plano de backup;
Executar varreduras sob demanda até qualquer ponto de restauração disponível;
Consultar o status da varredura em qualquer ponto da linha do tempo do backup contínuo por meio da nova API GetPITRMalwareScanResults — o que permite verificar se um determinado momento de recuperação está livre de ameaças antes de iniciar a restauração.
Por que isso importa
Backups contínuos são amplamente usados por equipes que precisam de baixa tolerância à perda de dados. O problema é que, sem verificação de integridade contra malware, um backup contínuo pode estar preservando arquivos comprometidos — e uma restauração a partir desse ponto poderia reintroduzir a ameaça no ambiente. Com essa integração, é possível garantir que o ponto de restauração escolhido é realmente seguro antes de acionar qualquer processo de recuperação.
Disponibilidade
O suporte a backups contínuos do S3 está disponível em todas as regiões da AWS onde o Amazon GuardDuty Malware Protection for AWS Backup já era suportado. Para começar a usar, basta acessar o console do AWS Backup, ou utilizar a API ou a Interface de Linha de Comando (CLI). Para mais detalhes técnicos, a AWS disponibiliza a documentação do AWS Backup e a documentação do Amazon GuardDuty Malware Protection.
Quem trabalha com operações em nuvem conhece bem o ciclo: alarmes do Amazon CloudWatch disparando, erros acumulando no AWS Lambda sem que ninguém perceba, e degradação de performance no Amazon Elastic Compute Cloud (Amazon EC2) que só vira problema quando o cliente liga reclamando. O time passa o dia alternando entre dashboards, triando alertas e investigando incidentes que já impactaram usuários — e o resultado é engenheiro de plantão esgotado, débito técnico crescendo e metas de Acordo de Nível de Serviço (SLA) sendo perdidas.
A raiz do problema é estrutural: as ferramentas de monitoramento atuais exigem que alguém esteja constantemente consultando, analisando e decidindo o que merece atenção. É um modelo que não escala. É nesse contexto que a AWS apresentou o AgentWatch.
O que são agentes ambientes?
Agentes ambientes representam uma mudança de paradigma em relação aos sistemas de IA tradicionais. Em vez de aguardar uma consulta direta, esses agentes escutam fluxos de eventos continuamente, respondem de forma dinâmica e processam múltiplas tarefas em paralelo — tudo isso reduzindo a carga operacional sobre as pessoas. Eles monitoram sem interrupção, mas envolvem humanos apenas nos momentos em que o julgamento humano é realmente necessário.
Para infraestrutura AWS, isso significa que um agente ambiente pode acompanhar recursos continuamente, identificar tendências e entregar inteligência acionável sem que a equipe precise abrir um dashboard manualmente ou vasculhar logs.
Apresentando o AgentWatch
O AgentWatch é um agente de monitoramento ambiente construído sobre o Modelo de Linguagem de Grande Escala (LLM) do Amazon Bedrock e implantado usando o Amazon Bedrock AgentCoreRuntime — um ambiente de hospedagem serverless e seguro, criado especificamente para executar agentes de IA em escala. Com o AgentCore Runtime, agentes são disponibilizados como endpoints HTTP que podem ser chamados programaticamente, enquanto autenticação, escalabilidade e gerenciamento de infraestrutura são tratados automaticamente.
A solução implementa um modelo híbrido: algumas tarefas são totalmente autônomas (como monitorar utilização de recursos e fornecer informações de baixo risco), enquanto outras exigem aprovação humana, como analisar causas de alarmes e implementar correções. O Slack funciona como interface principal, onde o agente posta relatórios e onde a equipe pode interagir com ele sob demanda.
Três padrões de supervisão humana
Supervisão humana no ciclo de decisão (HITL — Human-in-the-Loop) é fundamental para construir agentes ambientes confiáveis. O AgentWatch implementa três padrões que equilibram autonomia com controle adequado:
Padrão de Notificação (Notify)
A cada 15 minutos (intervalo parametrizável via MonitoringSchedule rate, com opções de 5, 10, 30 ou 60 minutos), o AgentWatch gera um relatório de monitoramento cobrindo alarmes do CloudWatch, problemas críticos e saúde dos recursos em múltiplas contas AWS. O agente posta esses relatórios em um canal do Slack, mantendo a equipe informada sem exigir ação imediata. O intervalo de 15 minutos foi escolhido para equilibrar detecção ágil de problemas com uso razoável de API — rápido o suficiente para capturar issues, mas sem gerar fadiga de alertas.
Padrão de Questionamento (Question)
Quando o AgentWatch detecta um alarme crítico mas não tem clareza suficiente para decidir entre remediação automatizada ou escalada para um engenheiro de plantão, ele posta uma pergunta no Slack pedindo orientação. Esse comportamento imita o que um Engenheiro de Confiabilidade de Site (SRE) faria ao consultar um administrador sênior antes de fazer mudanças significativas em sistemas de produção.
Padrão de Revisão (Review)
Para ações potencialmente impactantes — como modificar recursos AWS, ajustar políticas de escalabilidade ou alterar thresholds de alarmes — o agente apresenta a ação proposta no Slack junto com contexto e justificativa. A equipe pode aprovar a ação, rejeitá-la ou editar os parâmetros antes da execução.
Arquitetura e implementação
O ciclo de monitoramento do AgentWatch começa com o Amazon EventBridge disparando uma função AWS Lambda a cada 15 minutos via regra cron. Essa função Lambda autentica com o Amazon Cognito usando credenciais de cliente Autorização Aberta 2.0 (OAuth 2.0) para obter um token de acesso, e então chama o AgentCore Runtime com o prompt de monitoramento.
O AgentCore instancia um agente LangChain — framework para construir aplicações baseadas em modelos de linguagem — equipado com sete ferramentas especializadas de monitoramento para infraestrutura AWS. Essas ferramentas coletam sistematicamente dados de dashboards, grupos de logs, logs de serviços, padrões de erro, status de alarmes e métricas entre contas, proporcionando visibilidade abrangente do ambiente.
Após a coleta, o agente LangChain envia os dados agregados do CloudWatch para o modelo Claude Sonnet do Amazon Bedrock, que transforma as informações brutas de monitoramento em insights contextuais e legíveis por humanos. O resumo inteligente retorna pelo agente até o AgentCore Runtime, volta para a função Lambda, que formata a análise em blocos estruturados do Slack com seções organizadas para análise de logs e status de alarmes.
A infraestrutura de implantação tem três componentes principais:
Função Lambda: camada de orquestração que autentica com o Cognito, chama o endpoint do AgentCore Runtime e formata respostas para o Slack.
EventBridge: fornece invocação agendada via regra configurada para disparar a cada 15 minutos.
Amazon API Gateway: o Amazon API Gateway expõe a função Lambda como endpoint HTTP integrado ao app Slack via slash commands. Perguntas digitadas no Slack são roteadas para o API Gateway, que aciona o Lambda com a pergunta como prompt.
Essa arquitetura de duplo acionamento permite dois modos de operação: modo agendado, em que o agente roda autonomamente a cada 15 minutos postando relatórios proativos; e modo sob demanda, em que a equipe faz perguntas específicas via Slack e recebe respostas imediatas para troubleshooting interativo.
O trecho central do agente tem a seguinte estrutura:
No modo de monitoramento agendado, o AgentWatch gera e posta relatórios automaticamente a cada 15 minutos, entregando visibilidade contínua da saúde da infraestrutura AWS diretamente no canal do Slack da equipe — sem intervenção manual.
No modo sob demanda, a equipe usa slash commands do Slack para investigar situações específicas. Exemplos de consultas:
/ask What is the status of my CloudWatch alarms?
/ask Show me recent errors in my Lambda functions
/ask Analyze log patterns for the last hour
Casos de uso e benefícios
O AgentWatch entrega valor em múltiplos cenários operacionais. A solução identifica problemas potenciais antes que impactem usuários ao analisar continuamente métricas, logs e alarmes do CloudWatch em toda a infraestrutura AWS. Isso reduz a sobrecarga operacional — a equipe gasta menos tempo em tarefas rotineiras de monitoramento enquanto mantém visibilidade sobre a saúde dos sistemas.
A integração com Slack melhora a colaboração entre times de desenvolvimento e operações, suportando consultas em linguagem natural e discussões sobre problemas de infraestrutura. Para ambientes corporativos, o suporte multi-conta permite que grandes organizações monitorem infraestruturas AWS distribuídas a partir de um único agente centralizado.
Como começar
Para implantar o AgentWatch, é necessário ter uma conta AWS com permissões para CloudWatch, Lambda e EventBridge, um User Pool do Cognito configurado para autenticação OAuth 2.0 e um workspace do Slack com permissões para criar apps. Para desenvolvimento local e customizações, é necessário Python 3.11 ou superior.
Os comandos de configuração rápida são:
# Configurar o Provedor de Identidade
python idp_setup/setup_cognito.py
# Instalar a CLI mais recente do AgentCore
npm install -g @aws/agentcore
# Criar projeto AgentCore e trazer o código do agente existente
agentcore create --name AgentWatch --no-agent
agentcore add agent \
--name AgentWatch \
--type byo \
--code-location . \
--entrypoint ambient_agent.py \
--language Python
# Implantar no AgentCore Runtime
agentcore deploy
# Implantar infraestrutura
cd deployment
./deploy.sh
Após a execução do script de implantação, ele fornece a URL do webhook do Slack necessária para a configuração do app. O script automatiza todo o processo: configura o provedor de identidade (Cognito), implanta o agente no AgentCore Runtime e configura a função Lambda, a regra do EventBridge e o API Gateway. As instruções completas estão disponíveis no repositório GitHub.
Segurança e boas práticas
O AgentWatch implementa múltiplas camadas de segurança: OAuth 2.0 com Cognito para acesso seguro à API, assunção de papéis do Gerenciamento de Identidade e Acesso (IAM) para permissões granulares entre contas, e o AgentCore Runtime que adiciona capacidades de segurança e conformidade de nível corporativo. Os padrões HITL ajudam a prevenir ações autônomas inadequadas, e o registro de logs fornece trilhas de auditoria e capacidades de troubleshooting.
Extensões possíveis
A arquitetura de agente ambiente construída para monitoramento pode ser estendida para outros domínios operacionais:
Otimização de custos: adicionar ferramentas para analisar padrões de gastos e recomendar oportunidades de otimização.
Relatórios de conformidade: automatizar verificações de conformidade via AWS Config e AWS CloudTrail.
Análise de performance: aprimorar com monitoramento de performance de aplicações e recomendações de otimização.
Conclusão
O AgentWatch representa uma abordagem concreta para sair do ciclo reativo de monitoramento. Ao combinar operações autônomas com supervisão humana adequada, a solução realiza verificações de infraestrutura a cada 15 minutos, entrega relatórios acionáveis no Slack e responde a consultas em linguagem natural sobre o ambiente AWS — tudo isso mantendo a equipe informada e no controle.
A arquitetura usa os AWS Managed Services (AMS) e o Amazon Bedrock AgentCore Runtime para fornecer uma base escalável e segura para implantação de agentes ambientes. À medida que os agentes de IA se tornam mais sofisticados, arquiteturas como a do AgentWatch tendem a se tornar padrão para equipes que precisam operar com eficiência sem abrir mão do julgamento humano em decisões críticas de infraestrutura.
Para começar, acesse o AgentWatch no GitHub para instruções completas de implantação e detalhes de implementação.
Construir um aplicativo de inteligência artificial não deveria exigir um doutorado em aprendizado de máquina nem meses lidando com arquiteturas complexas. Mas é exatamente isso que acontece na prática quando você tenta orquestrar múltiplas chamadas de API, gerenciar o estado de uma conversa e criar agentes capazes de raciocinar de forma autônoma.
Ideias simples de IA acabam se transformando em projetos enormes, que demandam conhecimento especializado em processamento de linguagem natural e sistemas distribuídos. É nesse contexto que a AWS publicou um tutorial mostrando como o Strands Agents muda esse cenário — permitindo construir um assistente de pesquisa completamente funcional com apenas 30 linhas de código.
O que é o Strands Agents?
O Strands Agents é um framework open source que resolve diretamente os desafios do desenvolvimento de IA. Ele oferece uma forma direta de criar agentes inteligentes capazes de realizar tarefas como pesquisa, análise e geração de conteúdo, combinando o poder dos Modelos de Linguagem de Grande Escala (LLMs) com lógica personalizada e APIs via código Python.
A abordagem do framework é orientada pelo modelo: em vez de hardcoding complexo, ele usa LLMs para raciocínio e planejamento autônomos. Isso significa que você pode criar agentes com apenas um prompt e uma lista de ferramentas, enquanto o LLM cuida da lógica e do uso das ferramentas.
Entre os principais diferenciais do Strands Agents estão:
Arquitetura flexível: suporta desde agentes únicos até redes multi-agente e sistemas hierárquicos.
Integração via decorator @tool: permite conectar funções externas e APIs de forma simples.
Design agnóstico de modelo: funciona com diferentes provedores de LLM, incluindo Amazon Bedrock, Anthropic e OpenAI.
Integração nativa com AWS: conecta-se naturalmente com Amazon Bedrock e AWS Lambda.
Pronto para produção: equipes da AWS já utilizam o framework em serviços como Amazon Q e AWS Glue.
Licença Apache 2.0: open source com contribuições ativas da comunidade.
Respostas em streaming em tempo real: ideal para aplicações interativas que precisam de feedback imediato.
Além do Strands Agents, a AWS apresenta o Kiro, um Ambiente de Desenvolvimento Integrado (IDE) com IA que escreve código para que os desenvolvedores possam focar nas decisões. O Kiro possui um sistema de extensões chamado Kiro Powers, que empacota servidores MCP, arquivos de direcionamento e hooks em unidades reutilizáveis.
O Strands power, por exemplo, reúne busca na documentação do SDK, guias de introdução e padrões corretos de API para que o Kiro possa estruturar agentes com precisão. Com mais de 50 extensões curadas da AWS, parceiros e da comunidade — cobrindo design, implantação, segurança e observabilidade — a instalação é feita com um clique.
Pré-requisitos para começar
Antes de partir para o código, a AWS lista o que você precisa ter configurado:
Em seguida, é necessário anexar uma política inline de Gerenciamento de Identidade e Acesso (IAM) com escopo reduzido à função ou conjunto de permissões utilizado. Essa política concede apenas as permissões necessárias para o tutorial — invocar o modelo Claude Sonnet via Amazon Bedrock:
O ponto de partida é instalar o SDK do Strands Agents e o Streamlit no terminal do Kiro:
pip install strands-agents
pip install streamlit
Com isso, já é possível criar o primeiro agente em um arquivo Python chamado research.py:
from strands import Agent
# Create an agent with default settings
agent = Agent()
# Ask the agent a question
agent("Tell me about agentic AI")
Para executá-lo:
python -u research.py
Simples assim. Com essa base estabelecida, o próximo passo é evoluir para uma aplicação web com interface interativa.
Gerando o assistente completo com o Kiro
Aqui entra a vantagem do Kiro: usando linguagem natural, é possível descrever os requisitos e deixar o IDE gerar a implementação. O processo consiste em abrir o Kiro, criar um novo arquivo Python (por exemplo, research_assistant.py) e fornecer o seguinte prompt:
Create a Streamlit research assistant app using strands Agent library with these exact requirements:
1. App title: "Research Assistant" with subtitle "Enter a topic to get research analysis and recommendations"
2. Text input field with placeholder "e.g., renewable energy, artificial intelligence"
3. "Generate Research Report" button that when clicked:
- Shows spinner with "Researching and analyzing..." message
- Redirects stdout to prevent terminal output interference (import sys, os and use devnull)
- Creates Agent() instance
- Uses this exact prompt template:
"You are a research assistant. For the topic '{topic}':
1. Overview of the topic in about 50 words
2. Find recent 2 articles about {topic} in 20 words each
3. Things to know relevant to the topic and description as prerequisites in 20 words each
like if topic is agentic ai then prereq is machine learning and generative ai
4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each
5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
- Displays response using st.subheader(f"Research Report: {topic}") and st.write(response.message['content'][0]['text'])
- Restores stdout in finally block
- Shows warning if no topic entered
Use try/finally pattern for stdout redirection. Keep code minimal and functional.
O código gerado pelo Kiro é o seguinte:
import sys
import os
import streamlit as st
from strands import Agent
st.title("Research Assistant")
st.write("Enter a topic to get research analysis and recommendations")
topic = st.text_input("Research Topic", placeholder="e.g., renewable energy, artificial intelligence")
if st.button("Generate Research Report"):
if topic:
with st.spinner("Researching and analyzing..."):
old_stdout = sys.stdout
try:
sys.stdout = open(os.devnull, "w")
agent = Agent()
response = agent(
f"You are a research assistant. For the topic '{topic}': "
f"1. Overview of the topic in about 50 words "
f"2. Find recent 2 articles about {topic} in 20 words each "
f"3. Things to know relevant to the topic and description as prerequisites in 20 words each "
f"like if topic is agentic ai then prereq is machine learning and generative ai "
f"4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each "
f"5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
)
finally:
sys.stdout = old_stdout
st.subheader(f"Research Report: {topic}")
st.write(response.message["content"][0]["text"])
else:
st.warning("Please enter a topic to research.")
Observação importante: sem uma ferramenta de navegação web, o agente gera URLs a partir do seu conhecimento de treinamento. Esses links podem não refletir os artigos mais recentes. Para recuperação em tempo real, é necessário adicionar um servidor MCP apropriado como ferramenta.
Executando a aplicação
No terminal, navegue até o diretório onde o arquivo research_assistant.py foi salvo e execute:
streamlit run research_assistant.py
O Streamlit abrirá a interface no navegador. Basta inserir um tópico de interesse e clicar em “Generate Research Report” para receber o relatório de pesquisa.
Uso responsável de servidores MCP
O tutorial da AWS traz recomendações importantes sobre o uso de servidores MCP:
Fixe o servidor MCP em uma versão ou hash de commit específico (por exemplo, pip install "arxiv-mcp==X.Y.Z").
Revise o código-fonte antes de instalar.
Para casos de uso em produção, a recomendação é usar a recuperação nativa do Amazon Bedrock (Knowledge Bases/RAG).
Para implantações voltadas ao cliente ou entre organizações, passe servidores MCP de terceiros pelo processo de revisão jurídica e de segurança da sua organização.
Servidores MCP compartilham os privilégios do processo do agente, incluindo quaisquer credenciais AWS disponíveis. Trate-os como parte do seu perímetro de confiança.
A AWS reforça que o tutorial é um ponto de partida, e que antes de levar qualquer aplicação baseada nesse padrão para produção, é essencial considerar os seguintes pontos:
Valide a entrada do usuário: limite o tamanho do tópico e remova caracteres não imprimíveis antes de passar a string para o agente.
Ative o logging: habilite o registro de invocação de modelos no Amazon Bedrock e os eventos de dados do AWS CloudTrail para bedrock:InvokeModel e bedrock:Converse.
Controle de custos: configure um alarme de cota sob demanda no Amazon Bedrock e um limite de consultas por sessão para evitar esgotamento de custos.
Classifique dados persistidos: se armazenar histórico de conversas, classifique os dados e remova valores sensíveis antes de gravar.
Revise o modelo de responsabilidade compartilhada: consulte o Modelo de Responsabilidade Compartilhada da AWS para entender a divisão entre o que a AWS gerencia e o que é responsabilidade do cliente.
Além disso, o tutorial alerta que o streamlit run vincula ao endereço 127.0.0.1 por padrão, tornando a interface acessível apenas localmente. Não exponha a aplicação à rede local ou à internet sem adicionar autenticação, proteção contra CSRF e um limite de custo no Amazon Bedrock.
Conclusão
O tutorial da AWS demonstra como o Strands Agents, combinado com as capacidades de geração de código do Kiro, permite construir funcionalidades sofisticadas de IA com uma quantidade mínima de código. O framework reduz a complexidade do desenvolvimento de IA por meio de uma criação de agentes intuitiva, enquanto o Kiro aumenta a produtividade do desenvolvedor por meio de codificação assistida por IA.
As aplicações resultantes são ao mesmo tempo poderosas e fáceis de manter, com modificações personalizadas feitas rapidamente via engenharia de prompt. Para quem quer explorar mais sobre o Strands Agents, a AWS disponibilizou o artigo introdutório Apresentando o Strands Agents, um SDK de Agentes de IA Open Source.
