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.
A AWS adicionou suporte à API compatível com OpenAI nos endpoints de inferência em tempo real do Amazon SageMaker AI. Na prática, qualquer aplicação que já se comunique com a API da OpenAI — seja usando o OpenAI SDK, LangChain ou Strands Agents — pode ser redirecionada para um endpoint do SageMaker com uma única mudança: a URL base. Nenhuma reescrita de lógica, nenhuma adaptação de chamadas, nenhum cliente customizado.
Os endpoints do SageMaker AI passam a expor o caminho /openai/v1, que aceita requisições no formato Chat Completions e retorna as respostas diretamente do container, incluindo streaming. O roteamento é feito pelo nome do endpoint na URL, tornando qualquer cliente compatível com OpenAI funcional sem configuração adicional.
Para um exemplo completo com deploy e invocação, a AWS disponibilizou um notebook no GitHub.
Principais cenários de uso
Workflows agênticos em infraestrutura própria
Equipes que desenvolvem agentes de IA com múltiplas etapas usando frameworks como Strands Agents ou LangChain podem agora executar esses workflows inteiramente em endpoints próprios do SageMaker AI. Os agentes continuam chamando modelos pela mesma interface compatível com OpenAI, mas a inferência roda em instâncias de GPU dedicadas dentro da própria conta AWS.
Múltiplos modelos em um único endpoint
Quem opera vários modelos simultaneamente — por exemplo, um Llama para tarefas gerais, um Mistral ajustado para um domínio específico e um modelo menor para classificação — pode hospedar todos em um único endpoint usando inference components. Cada modelo recebe sua própria alocação de recursos e todos ficam acessíveis pelo mesmo OpenAI SDK, sem clientes separados ou lógica de roteamento no código da aplicação.
Modelos fine-tuned sem alterações no código
Para quem realiza fine-tuning de modelos open source, o deploy no SageMaker AI permite que as aplicações existentes continuem funcionando sem alterações. A única mudança necessária é a URL do endpoint. O restante — chamadas ao SDK, lógica de streaming, formatação de prompts — permanece intacto.
Autenticação com bearer tokens
Os endpoints compatíveis com OpenAI no SageMaker AI utilizam autenticação via bearer token. O SDK Python do SageMaker inclui um gerador de tokens que cria tokens com tempo de vida limitado — válidos por até 12 horas — a partir das credenciais AWS já existentes no ambiente. Não são necessárias chaves de API adicionais ou segredos extras.
O token exige as permissões sagemaker:CallWithBearerToken e sagemaker:InvokeEndpoint no IAM da conta.
Gerando um token
from sagemaker.core.token_generator import generate_token
from datetime import timedelta
token = generate_token(region="us-west-2", expiry=timedelta(minutes=5))
O gerador usa as credenciais AWS disponíveis no ambiente: credenciais de usuário IAM, perfil de instância no Amazon EC2 ou sessão do AWS IAM Identity Center (SSO). Por padrão, os tokens têm validade de 12 horas, mas isso pode ser ajustado com o parâmetro expiry. Para a ordem completa de resolução de credenciais, consulte a documentação de credenciais do Boto3.
Auto-refresh para aplicações de longa duração
Para aplicações que rodam continuamente, é possível implementar um padrão de renovação automática usando httpx, gerando um token novo a cada requisição:
import httpx
from sagemaker.core.token_generator import generate_token
class SageMakerAuth(httpx.Auth):
def __init__(self, region: str):
self.region = region
def auth_flow(self, request):
request.headers["Authorization"] = f"Bearer {generate_token(region=self.region)}"
yield request
http_client = httpx.Client(auth=SageMakerAuth(region="us-west-2"))
Como boa prática, recomenda-se restringir o campo Resource ao ARN específico do endpoint para a ação InvokeEndpoint, em vez de usar wildcard. Já o CallWithBearerToken exige wildcard — não suporta restrições por recurso.
Boas práticas de segurança com tokens: o bearer token carrega a mesma autorização das credenciais AWS usadas para gerá-lo. Trate-o com o mesmo cuidado que trataria as credenciais. Não gere tokens a partir de roles com permissões amplas como AdministratorAccess ou SageMakerFullAccess. Não armazene tokens em disco, variáveis de ambiente, arquivos de configuração, bancos de dados ou caches distribuídos. Não registre tokens em logs e transmita-os apenas por protocolos criptografados como HTTPS. Como a geração de token é uma operação local sem overhead de rede, a recomendação é gerar um token novo no momento do uso ou usar o padrão de auto-refresh com httpx.Auth.
Deploy de endpoint com modelo único
O exemplo abaixo realiza o deploy do modelo Qwen3-4B usando o container Deep Learning vLLM do SageMaker AI em uma instância ml.g6.2xlarge.
Atenção: endpoints do SageMaker AI geram custos enquanto estiverem ativos, independentemente do tráfego recebido. Consulte a página de preços do Amazon SageMaker AI para mais detalhes.
import boto3
import sagemaker
import time
from sagemaker.core.helper.session_helper import Session
from sagemaker.core.helper.session_helper import get_execution_role
# AWS configuration
REGION = "us-west-2"
# Automatically resolve account ID and default SageMaker execution role
session = Session(boto_session=boto3.Session(region_name=REGION))
ACCOUNT_ID = boto3.client("sts", region_name=REGION).get_caller_identity()["Account"]
EXECUTION_ROLE = get_execution_role(sagemaker_session=session)
# HF Model ID
MODEL_HF_ID = "Qwen/Qwen3-4B"
# SageMaker vLLM Deep Learning Container
VLLM_IMAGE = f"763104351884.dkr.ecr.{REGION}.amazonaws.com/vllm:0.20.2-gpu-py312-cu130-ubuntu22.04-sagemaker"
# Instance type (1x NVIDIA L4 GPU)
INSTANCE_TYPE = "ml.g6.2xlarge"
sagemaker_client = boto3.client("sagemaker", region_name=REGION)
print(f"Region: {REGION}")
print(f"Account ID: {ACCOUNT_ID}")
print(f"Execution role: {EXECUTION_ROLE}")
print(f"Model HF ID: {MODEL_HF_ID}")
Quando o endpoint atingir o status InService, ele estará disponível tanto no caminho padrão /invocations do SageMaker AI quanto no caminho compatível com OpenAI em /openai/v1/chat/completions.
Invocando o endpoint com o OpenAI SDK
A URL base segue o formato: https://runtime.sagemaker.<REGION>.amazonaws.com/endpoints/<ENDPOINT_NAME>/openai/v1
from openai import OpenAI
from sagemaker.core.token_generator import generate_token
REGION = "us-west-2"
sme_base_url = f"https://runtime.sagemaker.{REGION}.amazonaws.com/endpoints/{SME_ENDPOINT_NAME}/openai/v1"
client = OpenAI(
base_url=sme_base_url,
api_key=generate_token(region=REGION)
)
print(f"Base URL: {sme_base_url}")
stream = client.chat.completions.create(
model="",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain how transformers work in machine learning, in three sentences."},
],
stream=True,
)
for chunk in stream:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="")
print()
O campo model é repassado diretamente ao container. Como o SageMaker AI faz o roteamento pelo nome do endpoint na URL, esse campo pode ficar vazio ou receber o nome que o container espera.
Deploy com inference components (múltiplos modelos)
Com inference components, é possível hospedar vários modelos em um único endpoint, cada um com alocação de recursos dedicada. Nesse modelo, o modelo é associado ao componente, não à configuração do endpoint:
É possível criar inference components adicionais no mesmo endpoint para hospedar múltiplos modelos com escalonamento e alocação de recursos independentes.
Invocando inference components
Para invocar um inference component específico, inclua o nome do componente no caminho da URL: https://runtime.sagemaker.<REGION>.amazonaws.com/endpoints/<ENDPOINT>/inference-components/<IC_NAME>/openai/v1
import httpx
from openai import OpenAI
from sagemaker.core.token_generator import generate_token
shared_http = httpx.Client()
client_a = OpenAI(
base_url=(
f"https://runtime.sagemaker.{REGION}.amazonaws.com"
f"/endpoints/{IC_ENDPOINT_NAME}/inference-components/{IC_NAME}/openai/v1"
),
api_key=generate_token(region=REGION),
http_client=shared_http,
)
response = client_a.chat.completions.create(
model="",
messages=[{"role": "user", "content": "What is 42 * 3? Reply with the number."}],
)
print(f"Response: {response.choices[0].message.content}")
print(f"Connection pool active: shared_http is reusable across multiple IC clients")
O httpx.Client compartilhado permite que múltiplas instâncias do cliente OpenAI reutilizem as mesmas sessões TLS e o mesmo pool de conexões.
Integração com Strands Agents
O Strands Agents é um SDK open source para construção de agentes de IA. Por suportar provedores de modelos compatíveis com OpenAI, agora é possível executar workflows multi-agente inteiramente na infraestrutura do SageMaker AI — com controle total sobre qual versão do modelo os agentes utilizam e sem que os dados saiam da conta AWS.
from openai import AsyncOpenAI
from strands import Agent, tool
from strands.models.openai import OpenAIModel
from sagemaker.core.token_generator import generate_token
@tool
def calculator(expression: str) -> str:
"""Evaluate a math expression."""
return str(eval(expression))
strands_client = AsyncOpenAI(
base_url=f"https://runtime.sagemaker.{REGION}.amazonaws.com/endpoints/{SME_ENDPOINT_NAME}/openai/v1",
api_key=generate_token(region=REGION),
)
model = OpenAIModel(client=strands_client, model_id="", params={"temperature": 0.7})
coder = Agent(
model=model,
system_prompt=(
"You are an expert Python developer. Write clean, well-documented "
"Python code with type hints. Output ONLY the code, no explanation."
),
tools=[calculator],
)
reviewer = Agent(
model=model,
system_prompt=(
"You are a senior code reviewer. Review Python code for correctness, "
"performance, and PEP 8 style. Give a concise review with specific suggestions."
),
tools=[calculator],
)
Limpeza de recursos
Para evitar cobranças contínuas, é fundamental excluir os endpoints e recursos associados após o uso. Endpoints do SageMaker AI geram custos enquanto estiverem ativos, mesmo sem receber tráfego.
Com o suporte à API compatível com OpenAI, o Amazon SageMaker AI remove a principal barreira de integração entre as aplicações de IA já existentes — construídas sobre o padrão OpenAI — e a infraestrutura necessária para escalar com controle. É possível manter o código existente, usar qualquer framework compatível com OpenAI e executar inferência em endpoints dedicados com controle de GPU, escalonamento e residência de dados.
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.
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.
Figura 1: Fluxo de geração de políticas Cedar — Imagem original — fonte: AWS
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 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.
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.
O problema com a chamada tradicional de ferramentas
Quando um Modelo de Linguagem Grande (LLM — Large Language Model) precisa consultar ferramentas externas, o fluxo convencional funciona assim: o modelo chama uma ferramenta, aguarda o resultado, raciocina sobre ele, chama a próxima ferramenta e repete o ciclo. Para tarefas que envolvem múltiplas chamadas, esse padrão gera latência e consumo de tokens que se acumulam rapidamente.
Imagine a pergunta: “Quais membros do time de engenharia ultrapassaram o orçamento de viagens no terceiro trimestre?” Sem PTC, o modelo precisaria chamar uma ferramenta para listar os 20 membros do time, depois chamar outra ferramenta 20 vezes para buscar os registros de despesas de cada um, receber mais de 2.000 linhas de dados na janela de contexto e, só então, tentar filtrar e comparar tudo em linguagem natural. Cada chamada exige um ciclo completo de inferência do modelo.
Esse processo cria três problemas que se somam:
Consumo de tokens: todos os resultados intermediários — inclusive os milhares de registros que o modelo vai descartar — passam pela janela de contexto.
Latência: 20 chamadas sequenciais significam 20 ciclos de inferência.
Precisão: pedir a um modelo de linguagem que filtre, agregue e compare milhares de registros em linguagem natural é uma fonte de erros. Algumas linhas de Python fariam isso com exatidão.
Como a Chamada Programática de Ferramentas (PTC) resolve isso
A Chamada Programática de Ferramentas (PTC — Programmatic Tool Calling) inverte o padrão. Em vez de orquestrar chamadas uma a uma, o modelo gera um único bloco de código Python que coordena todas as ferramentas, processa os resultados e retorna apenas a saída final para o contexto. O modelo é amostrado uma vez para produzir o código; a execução fica por conta do ambiente sandbox.
No mesmo exemplo de auditoria de despesas, o código gerado pelo modelo com PTC ativado faz duas coisas importantes. Primeiro, usa asyncio.gather() para buscar os registros de todos os 20 funcionários em paralelo, em vez de sequencialmente. Segundo, toda a filtragem, agregação e comparação de orçamentos acontece em Python — não em linguagem natural. Apenas a saída do print() final volta ao contexto do modelo. Os mais de 2.000 registros brutos nunca chegam a tocá-lo.
import asyncio
import json
# Step 1: Get team members
team_json = await get_team_members(department="engineering")
team = json.loads(team_json)
# Step 2: Fetch all expense records in parallel
expense_tasks = [
get_expenses(employee_id=m["id"], quarter="Q3")
for m in team
]
expenses_results = await asyncio.gather(*expense_tasks)
# Step 3: Filter and check budgets
exceeded = []
for member, exp_json in zip(team, expenses_results):
expenses = json.loads(exp_json)
total_travel = sum(
e["amount"] for e in expenses
if e["category"] == "travel" and e["status"] == "approved"
)
if total_travel > 5000:
budget_json = await get_custom_budget(user_id=member["id"])
budget = json.loads(budget_json)
limit = budget["budget_limit"]
if total_travel > limit:
exceeded.append({
"name": member["name"],
"spent": total_travel,
"limit": limit,
"exceeded_by": total_travel - limit
})
# Step 4: Only the summary enters the model's context
print(f"{len(exceeded)} members exceeded budget:")
print(json.dumps(exceeded, indent=2))
O modelo é amostrado apenas duas vezes no total: uma para gerar o código e outra para interpretar o resultado final. Tudo entre esses dois momentos — chamadas de ferramentas, processamento de dados, filtragem — acontece dentro do container, sem inferência adicional.
O PTC é especialmente eficaz para processamento de grandes volumes de dados, cálculos numéricos precisos, orquestração de processos em múltiplas etapas e cenários sensíveis à privacidade, onde dados brutos não devem entrar no contexto do modelo.
Três formas de implementar PTC no Amazon Bedrock
A AWS descreve três caminhos para implementar PTC no Amazon Bedrock, cada um adequado a um perfil diferente de equipe.
Parte 1: PTC auto-hospedado com Amazon ECS e Docker
Para equipes que precisam de controle total, a abordagem auto-hospedada usa dois componentes principais: um orquestrador (rodando em uma task do Amazon Elastic Container Service — ECS, em uma função AWS Lambda ou em outra unidade de computação) e um sandbox Docker isolado que executa o código Python gerado pelo modelo.
A ideia central é simples: em vez de passar as definições de ferramentas no parâmetro tool_config, elas são injetadas no system prompt, e o modelo recebe instrução para escrever código Python que orquestre essas ferramentas. O código gerado roda no sandbox Docker. O orquestrador atua como plano de controle, interceptando chamadas de ferramentas via Comunicação entre Processos (IPC — Inter-Process Communication), executando-as externamente e injetando os resultados de volta no sandbox.
O sistema usa uma arquitetura de duplo processo. O orquestrador inicia um container Docker para cada requisição de execução de código. A comunicação acontece via fluxos de entrada e saída padrão: o container escreve requisições de chamada de ferramentas no stderr, e o orquestrador injeta os resultados via stdin. Para demarcar os diferentes tipos de mensagem no fluxo de texto, o sistema define marcadores de limite como __PTC_TOOL_CALL__, __PTC_END_CALL__ e __PTC_OUTPUT__.
O container Docker roda com isolamento rígido: sem acesso à rede, sistema de arquivos somente leitura, usuário não-root, capacidades Linux removidas e limites de memória e CPU aplicados. O código gerado pelo modelo não consegue escapar do sandbox, persistir dados ou consumir recursos excessivos.
O loop do orquestrador envia a consulta do usuário ao Amazon Bedrock, extrai o código gerado pelo modelo do bloco tool_use da resposta, executa no sandbox Docker e devolve a saída como tool_result. O modelo então produz a resposta final legível para humanos.
Parte 2: PTC gerenciado com Amazon Bedrock AgentCore Code Interpreter
Para equipes que preferem não gerenciar containers Docker e infraestrutura de ECS, o Amazon Bedrock AgentCore oferece um Code Interpreter gerenciado que implementa o mesmo padrão PTC. O modelo escreve código, um sandbox gerenciado o executa e apenas o resultado final retorna ao contexto do modelo.
A diferença principal em relação à abordagem auto-hospedada é que as ferramentas são pré-carregadas na sessão do sandbox em vez de serem despachadas de volta ao cliente via IPC. Inicia-se uma sessão do Code Interpreter, as definições das funções de ferramentas são injetadas como código Python e, então, o modelo gera código que chama essas funções diretamente. O AgentCore usa o cliente boto3 bedrock-agentcore.
A comparação entre as duas abordagens:
Auto-hospedado (ECS + Docker): você gerencia a infraestrutura, tem controle total sobre o sandbox, pode instalar pacotes Python específicos e configurar políticas de segurança personalizadas. A execução das ferramentas acontece no lado do cliente via IPC.
AgentCore (gerenciado): infraestrutura totalmente gerenciada, ambiente de execução padrão, ferramentas executadas dentro do próprio sandbox. Recomendado para quem quer os benefícios de economia de tokens e precisão do PTC sem o custo operacional de manter containers.
Parte 3: Compatibilidade com o SDK da Anthropic via proxy
Para equipes que preferem a experiência de desenvolvimento do SDK da Anthropic e querem usar o Amazon Bedrock como backend, é possível construir um proxy leve de tradução de API que fica entre o SDK da Anthropic e o Amazon Bedrock.
O proxy é implantado no Amazon ECS e traduz chamadas da API da Anthropic para chamadas InvokeModel do Amazon Bedrock. Ele também gerencia o ciclo de vida do sandbox Docker e o protocolo PTC completo de forma transparente. Para migrar, basta alterar o base_url para apontar para o proxy:
import anthropic
# Point the Anthropic SDK at the proxy deployed on ECS.
# The proxy translates these calls to Bedrock InvokeModel under the hood.
client = anthropic.Anthropic(
api_key="your-proxy-api-key", # API key configured in the proxy
base_url="http://your-proxy-url.com" # Your proxy's ECS endpoint
)
Essa abordagem é recomendada para equipes que preferem a interface do SDK da Anthropic enquanto rodam inferência no Amazon Bedrock e se beneficiam de estar dentro da própria conta AWS.
Resultados experimentais
Para validar a solução auto-hospedada, a AWS executou a mesma tarefa de auditoria de despesas em múltiplos modelos disponíveis no Amazon Bedrock. O cenário usou oito membros de um time de engenharia, com 20 a 50 registros de despesas por pessoa por trimestre (cada um com mais de 15 campos) e regras de orçamento com limite padrão de US$ 5.000 e exceções personalizadas para cargos sênior.
A resposta correta esperada era:
Alice Chen: orçamento US$ 5.000, gasto US$ 9.876,54, excedeu em +US$ 4.876,54
Emma Johnson: orçamento US$ 5.000, gasto US$ 5.266,02, excedeu em +US$ 266,02
Os resultados comparativos entre modo PTC e modo tradicional:
Claude Sonnet 4.6 (adaptive thinking): 12.739 tokens (PTC) vs. 128.043 (sem PTC) — redução de 90,1%. Correto em ambos os modos.
Claude Opus 4.6 (adaptive thinking): 13.043 vs. 126.152 — redução de 89,7%. Correto em ambos.
Qwen3-Coder-480B: 34.159 vs. 305.114 — redução de 88,8%. Correto apenas com PTC.
Qwen3-Next-80B: 28.878 vs. 233.332 — redução de 87,6%. Correto apenas com PTC.
DeepSeek V3.2 (thinking): 19.543 vs. 245.967 — redução de 92,1%. Correto apenas com PTC.
MiniMax M2.1 (thinking): 11.787 vs. 101.990 — redução de 88,4%. Correto apenas com PTC.
Kimi 2.5 (thinking): 10.875 vs. 148.085 — redução de 92,7%. Correto apenas com PTC.
GLM 4.7 (thinking): 11.550 vs. 115.829 — redução de 90,0%. Correto apenas com PTC.
Os principais achados são três. O consumo de tokens caiu entre 87% e 92% em todos os modelos no modo PTC — em vez de centenas de milhares de tokens fluindo pela janela de contexto, apenas o código e o resumo final chegam ao modelo. A precisão melhorou significativamente: no modo PTC, todos os oito modelos produziram a resposta correta; sem PTC, apenas os modelos Claude acertaram. A compatibilidade entre modelos foi confirmada — Claude, Qwen, DeepSeek, MiniMax, Kimi e GLM alcançaram resultados corretos no modo PTC, demonstrando que o padrão funciona em famílias de modelos diversas.
Análise de custos
Tomando o Claude Sonnet como exemplo, com redução de aproximadamente 90% no consumo de tokens e precificação de US$ 3/US$ 15 por milhão de tokens de entrada/saída, a projeção para 1.000 execuções diárias da tarefa de auditoria em ambiente de produção seria:
Custo diário estimado sem PTC: ~US$ 520
Custo diário estimado com PTC: ~US$ 52
Custo mensal sem PTC: ~US$ 15.600
Custo mensal com PTC: ~US$ 1.560
Economia mensal estimada: ~US$ 14.040 (90%)
Os valores variam conforme a complexidade da tarefa e o volume de dados, mas o padrão é consistente: o PTC reduz custos em proporção à quantidade de dados intermediários que mantém fora da janela de contexto.
Conclusão
A Chamada Programática de Ferramentas representa uma mudança na forma como agentes de IA interagem com ferramentas — de invocações conversacionais uma a uma para execução paralela e filtrada orquestrada por código. As três abordagens apresentadas pela AWS são agnósticas em relação ao modelo, implantadas de forma privada dentro da conta AWS do usuário e extensíveis a novos modelos à medida que ficam disponíveis no Amazon Bedrock.
A AWS anunciou a disponibilidade do Amazon Inspector na região AWS Ásia-Pacífico (Taipei). A expansão amplia a cobertura de segurança do serviço para mais uma região global, permitindo que clientes que operam nessa localidade utilizem o gerenciamento automatizado de vulnerabilidades diretamente em seus ambientes.
O que é o Amazon Inspector?
O Amazon Inspector é um serviço de gerenciamento de vulnerabilidades totalmente automatizado. Ele realiza varreduras contínuas em cargas de trabalho AWS, cobrindo instâncias do Amazon EC2 (Elastic Compute Cloud), imagens de contêiner e funções do AWS Lambda — tudo isso em busca de vulnerabilidades de software e exposições de rede não intencionais. O serviço opera em nível organizacional, o que significa que pode ser aplicado de forma centralizada em múltiplas contas dentro de uma AWS Organization.
O que muda com essa expansão?
Com a chegada do Amazon Inspector à região de Taipei, os clientes que utilizam essa localidade passam a contar com os mesmos recursos já disponíveis em outras regiões. Entre os principais benefícios destacados pela AWS estão:
Descoberta automática de workloads: o serviço identifica automaticamente instâncias EC2 recém-lançadas, funções Lambda e imagens de contêiner elegíveis enviadas ao Amazon ECR (Elastic Container Registry).
Avaliações contínuas de vulnerabilidades: as varreduras acontecem de forma ininterrupta, sem necessidade de configuração manual a cada novo recurso provisionado.
Resultados de segurança acionáveis: os achados são apresentados de forma clara, facilitando a priorização e a resposta das equipes de segurança.
Avaliação gratuita de 15 dias
Assim como nas demais regiões, todas as contas que utilizarem o Amazon Inspector pela primeira vez têm direito a um período de avaliação gratuita de 15 dias. Durante esse período, todas as instâncias EC2, funções Lambda e imagens de contêiner enviadas ao Amazon ECR elegíveis são escaneadas continuamente sem custo algum. Após o encerramento do período de teste, a cobrança passa a seguir os valores da tabela de preços pública do Amazon Inspector.
Como começar
Para equipes que ainda não utilizam o Amazon Inspector, esse é um bom momento para avaliar o serviço sem compromisso financeiro. A AWS disponibiliza documentação oficial e a opção de iniciar o período de avaliação gratuita diretamente pelo console.
O alerta mais recente do CIRT chama atenção para uma abordagem que vem crescendo: após comprometer uma conta AWS, o invasor tenta removê-la do AWS Organizations da organização. O objetivo é simples — escapar dos controles, políticas e visibilidade que a estrutura do Organizations oferece.
Como o ataque funciona
Tudo começa com a obtenção da permissão organizations:LeaveOrganization. Quem tem esse acesso pode chamar a API LeaveOrganization, que, quando executada a partir de uma conta membro, solicita a saída dessa conta da organização.
Quando uma conta tenta sair de uma organização, pelo menos duas chamadas de API são registradas no CloudTrail: organizations:AcceptHandshake e organizations:LeaveOrganization. Se você tem logging centralizado, esses podem ser os últimos eventos que você verá da conta comprometida antes de ela sair da organização e passar a registrar eventos apenas em seus próprios logs locais.
Os eventos do CloudTrail associados a contas entrando ou saindo de uma organização devem ser investigados sempre que não fizerem parte de um fluxo operacional aprovado pela equipe. Os principais eventos a monitorar incluem: conta membro saindo da organização, conta aceitando convite para entrar em outra organização, organização convidando a conta, e conta de gerenciamento removendo uma conta membro.
Como se proteger: passos recomendados
1. Implemente uma SCP que bloqueie a saída da organização
A medida mais direta e eficaz é criar uma SCP que negue a ação organizations:LeaveOrganization. A AWS oferece orientações detalhadas sobre como implementar esse controle, incluindo o JSON da política e recomendações de design de OU para acomodar migrações legítimas de contas sem abrir mão da proteção em ambientes de produção e desenvolvimento.
As SCPs funcionam como barreiras que limitam o que qualquer política IAM pode permitir dentro das contas membro. O CIRT recomenda fortemente que toda organização que usa o AWS Organizations verifique hoje mesmo se essa SCP está em vigor — e a implemente caso ainda não esteja. É um controle rápido de aplicar e com impacto operacional mínimo.
2. Aplique o princípio do menor privilégio no IAM
Como essa ação pode partir de qualquer credencial IAM comprometida que tenha a permissão organizations:LeaveOrganization — não apenas do root —, limitar quais usuários e roles podem adicionar ou remover contas, alterar políticas, assumir outras roles ou modificar suas próprias permissões reduz significativamente os caminhos disponíveis para um invasor.
A recomendação é revisar periodicamente as políticas IAM em busca de permissões excessivamente amplas, com atenção especial para: iam:AttachRolePolicy, iam:AttachUserPolicy, iam:PutRolePolicy e sts:AssumeRole com políticas de confiança abrangentes.
3. Proteja as credenciais root
O comprometimento do root continua sendo um dos vetores de entrada mais comuns para esse padrão de ataque. As medidas recomendadas são: habilitar autenticação multifator (MFA) em todos os usuários root, excluir quaisquer chaves de acesso root existentes e adotar o gerenciamento centralizado de acesso root para remover completamente as credenciais root das contas membro.
Um padrão mais amplo que merece atenção
O CIRT aponta que essa técnica reflete uma tendência mais ampla: agentes maliciosos estão cada vez mais familiarizados com o funcionamento dos controles de governança da AWS e tomam medidas deliberadas para separar contas das proteções que a organização oferece. Desabilitar o CloudTrail, excluir detectores do GuardDuty e remover contas do Organizations são variações da mesma estratégia — eliminar os guardrails e a visibilidade que limitariam a ação do invasor e ajudariam a organização a responder.
Os controles para prevenir isso já estão disponíveis e são simples de implementar. O ponto de partida recomendado é seguir as orientações da equipe do AWS Organizations e implementar a SCP DenyLeaveOrganization — o controle de maior impacto e menor esforço para essa técnica específica. A partir daí, revisar a cobertura de SCPs em toda a estrutura de OUs, garantir que credenciais root e permissões IAM estejam devidamente protegidas em todas as contas membro, e assegurar que os processos de detecção e resposta contemplem essa técnica contribuem para uma postura de segurança mais robusta.
Por que padrões de design para agentes de voz escaláveis importam
Organizações que precisam entregar experiências de voz rápidas, naturais e confiáveis enfrentam desafios recorrentes: alta latência, gerenciamento de áudio em tempo real e coordenação de múltiplos agentes em fluxos complexos. A AWS publicou um guia detalhado mostrando como usar Amazon Nova Sonic, Amazon Bedrock AgentCore e Strands BidiAgent para construir agentes de voz escaláveis e manuteníveis que lidam com esses desafios de forma eficiente, resultando em interações mais responsivas e inteligentes com o cliente.
O artigo explora três padrões arquiteturais populares para agentes de voz, destacando seus trade-offs e melhores práticas para minimizar latência.
Os blocos fundamentais
Antes de mergulhar nos padrões de arquitetura, vale entender os três componentes-chave utilizados como solução de exemplo.
Amazon Nova Sonic é um modelo fundacional que cria conversas naturais de fala para fala (speech-to-speech) em aplicações de IA generativa. Os usuários podem interagir com a IA por voz em tempo real, com capacidades de entender tom, fluxo conversacional natural e executar ações.
Amazon Bedrock AgentCore Runtime é um ambiente de hospedagem serverless para agentes de IA. Você empacota seu agente como um container, faz o deploy no AgentCore Runtime e ele cuida de escalabilidade, isolamento de sessão e cobrança. Para agentes de voz, oferece:
Isolamento de sessão em nível de microVM para evitar picos de latência por vizinhos ruidosos
AgentCore Gateway para hospedagem compartilhada de ferramentas usando o protocolo open source Protocolo de Contexto de Modelo (MCP)
Memória persistente entre sessões
Telemetria para métricas específicas de voz como time-to-first-audio
Strands Agents é um framework open source para construção de agentes de IA. Sua classe BidiAgent é uma opção de integração entre o Nova Sonic e sua aplicação. Ela gerencia o ciclo de vida do stream bidirecional, roteia chamadas de ferramentas e cuida do gerenciamento de sessão, simplificando a aplicação do agente de voz através da interface SDK do modelo.
Três padrões de integração: ferramenta, agente-como-ferramenta (sub-agente) e segmentação de sessão
Em vez de construir um agente único e todo-poderoso, sistemas de voz modernos são cada vez mais compostos por agentes orientados a ferramentas, sub-agentes atuando como ferramentas e estratégias de segmentação de sessão que isolam prompts, memória e permissões. Esses padrões permitem decompor assistentes grandes em componentes menores, especializados e reutilizáveis, mantendo fronteiras claras de segurança.
Antes de executar os exemplos, é necessário instalar Python e as dependências necessárias, incluindo strands-agents e boto3, além de garantir que sua configuração IAM tenha as permissões necessárias para os serviços requeridos. Para o exemplo completo, consulte o repositório no GitHub.
Padrão 1: AgentCore Gateway – seleção de ferramenta para baixa latência
Uma chamada de ferramenta (tool call) é quando um agente de voz envia entrada para uma função ou serviço externo, que processa e retorna a saída. Isso permite que o agente execute tarefas como consultar um banco de dados ou acionar um serviço de forma rápida e segura, sem etapas adicionais de raciocínio.
Com o AgentCore Gateway, você expõe sua lógica de negócio existente como ferramentas — funções discretas que o Nova Sonic pode chamar diretamente durante uma conversa. O modelo de voz seleciona qual ferramenta invocar, passa os parâmetros, obtém o resultado e fala de volta. Não há camada intermediária de raciocínio entre o modelo e a ferramenta.
O AgentCore Gateway hospeda servidores MCP como endpoints gerenciados. MCP é o protocolo; AgentCore Gateway é a funcionalidade da AWS que os executa. O agente de voz se conecta via ARNs do Gateway:
# Nova Sonic calls tools directly via AgentCore Gateway
model = BidiNovaSonicModel(
model_id="amazon.nova-2-sonic-v1:0",
mcp_gateway_arn=[
"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/auth-tools",
"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/banking-tools",
"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/mortgage-tools",
],
)
Quando um usuário diz “Qual é o meu saldo?”, o Nova Sonic:
Entende a intenção a partir da fala
Seleciona get_account_balance das ferramentas MCP disponíveis
Chama a ferramenta com os parâmetros corretos
Fala o resultado de volta
Trade-off: O Nova Sonic toma todas as decisões. Se uma chamada de ferramenta requer validação em múltiplas etapas, lógica condicional ou encadeamento de múltiplas operações, essa carga de raciocínio recai inteiramente sobre o system prompt do modelo de voz. Para ferramentas simples funciona bem. Para fluxos complexos, torna-se frágil.
Padrão 2: Sub-agente – raciocínio adicional com agentes desacoplados
No padrão sub-agente (ou agente-como-ferramenta), sua lógica de negócio existente roda em agentes autônomos, cada um com seu próprio modelo, system prompt, ferramentas e capacidades de raciocínio. O orquestrador de voz delega tarefas inteiras a esses sub-agentes em vez de chamar ferramentas individuais.
Existem diversas formas de conectar um sub-agente ao seu agente de voz. Agente-para-Agente (A2A) e Strands Agent-as-Tool são duas abordagens comuns:
Agent-as-tool local: O sub-agente roda no mesmo processo, encapsulado como uma função @tool usando o padrão Agents as Tools no Strands. É a abordagem mais direta — sem hop de rede e sem deploy separado. O trade-off é que o sub-agente compartilha o mesmo processo e escala junto com o orquestrador.
Agente remoto via protocolo A2A: O sub-agente é implantado como um servidor A2A independente no AgentCore Runtime (ou servidor remoto) e invocado pela rede. A2A é um protocolo aberto para comunicação agente-a-agente. Assim como o MCP conecta agentes a ferramentas, o A2A conecta agentes a outros agentes. Conforme o blog da AWS sobre suporte ao protocolo A2A no AgentCore Runtime explica, agentes construídos com diferentes frameworks (Strands, OpenAI, LangGraph, Google ADK) podem compartilhar contexto e raciocínio em um formato comum.
Veja a abordagem local agent-as-tool, onde cada sub-agente é um @tool encapsulando um Agent completo do Strands:
# sub_agents.py — Define sub-agents as Strands tools using the Agents-as-Tools pattern
from strands import Agent, tool
from strands.models import BedrockModel
# Each sub-agent is a full Strands Agent wrapped as a @tool
# The BidiAgent orchestrator calls these via Nova Sonic's tool use
@tool
def authenticate_customer(account_id: str, date_of_birth: str) -> str:
"""Authenticate a customer using their account ID and date of birth.
Handles the full verification flow including identity checks and retry logic.
Returns authentication status and token."""
auth_agent = Agent(
model=BedrockModel(model_id="amazon.nova-lite-v1:0"),
system_prompt="""You are an authentication agent. Verify the customer's identity
using the provided account ID and date of birth. Call verify_identity to check
credentials. Return a clear auth status in 1-2 sentences.""",
tools=[verify_identity, check_account_exists], # Sub-agent's own tools
)
result = auth_agent(f"Authenticate account {account_id}, DOB: {date_of_birth}")
return str(result)
@tool
def handle_banking_inquiry(query: str, auth_token: str) -> str:
"""Handle banking questions — balances, transactions, transfers.
Validates permissions and returns a conversational summary."""
banking_agent = Agent(
model=BedrockModel(model_id="amazon.nova-lite-v1:0"),
system_prompt="""You are a banking agent. Use the provided tools to answer
the customer's query. Summarize results in 2-3 natural sentences.
Do not return raw JSON.""",
tools=[get_account_balance, get_recent_transactions, transfer_funds],
)
result = banking_agent(query)
return str(result)
@tool
def handle_mortgage_inquiry(query: str) -> str:
"""Handle mortgage questions — rates, calculations, eligibility, application status.
Performs its own calculations and reasoning."""
mortgage_agent = Agent(
model=BedrockModel(model_id="amazon.nova-lite-v1:0"),
system_prompt="""You are a mortgage specialist. Help with rate inquiries,
payment calculations, and eligibility assessments. Keep responses concise
and conversational — this will be spoken aloud.""",
tools=[get_mortgage_rates, calculate_payment, check_eligibility],
)
result = mortgage_agent(query)
return str(result)
O orquestrador de voz então usa o BidiAgent com essas ferramentas de sub-agente:
# voice_orchestrator.py — BidiAgent with sub-agents as tools
from strands.experimental.bidi.agent import BidiAgent
from strands.experimental.bidi.models.nova_sonic import BidiNovaSonicModel
from sub_agents import authenticate_customer, handle_banking_inquiry, handle_mortgage_inquiry
model = BidiNovaSonicModel(
region="us-east-1",
model_id="amazon.nova-2-sonic-v1:0",
provider_config={"audio": {"voice": "tiffany", "input_sample_rate": 16000, "output_sample_rate": 16000}},
)
agent = BidiAgent(
model=model,
tools=[authenticate_customer, handle_banking_inquiry, handle_mortgage_inquiry],
system_prompt="""You are a banking voice assistant. Route customer requests to the
appropriate specialist. Always authenticate before accessing account data.
Keep your own responses brief — the sub-agents handle the details.""",
)
await agent.run(inputs=[ws_input], outputs=[ws_output])
O sub-agente faz seu próprio raciocínio. O Nova Sonic não precisa orquestrar os passos individuais — ele delega e fala o resultado.
Trade-off: Cada chamada de sub-agente adiciona latência: a inferência do modelo do sub-agente mais suas chamadas de ferramenta. Em uma conversa por voz, isso significa silêncio mais longo enquanto o sub-agente raciocina. O blog da AWS sobre assistentes de voz multi-agente recomenda começar com modelos menores e eficientes como Amazon Nova 2 Lite para sub-agentes, reduzindo latência enquanto ainda lida com tarefas especializadas de forma eficaz.
O Amazon Nova 2 Sonic suporta chamada assíncrona de ferramentas, de modo que a conversa continua naturalmente enquanto ferramentas rodam em segundo plano. Ele continua aceitando entrada, pode executar múltiplas ferramentas em paralelo e se adapta graciosamente se o usuário mudar seu pedido no meio do processo.
Padrão 3: Segmentação de sessão para latência ultra-baixa
Existe uma terceira abordagem que vale considerar. Ela não se encaixa perfeitamente nos padrões MCP ou sub-agente, mas é construída especificamente para cenários de voz onde latência é a preocupação principal.
Em vez de delegar ferramentas externas ou sub-agentes, você segmenta a conversa em fases lógicas, cada uma com sua própria sessão Nova Sonic, system prompt e conjunto de ferramentas. Quando a conversa transiciona de uma fase para a próxima (por exemplo, de autenticação para consulta de conta), você fecha a sessão atual e abre uma nova com prompt e ferramentas diferentes, dentro da mesma conexão WebSocket.
Pense em um assistente bancário de voz com três fases de conversa: autenticação, gerenciamento de conta e consulta de hipoteca. Em vez de carregar um system prompt massivo com todas as ferramentas, você executa cada fase como uma sessão focada do Nova Sonic:
# Phase 1: Authentication
auth_session = BidiNovaSonicModel(
model_id="amazon.nova-2-sonic-v1:0",
mcp_gateway_arn=["arn:...gateway/auth-tools"], # Only auth tools
)
auth_agent = BidiAgent(
model=auth_session,
tools=[],
system_prompt="""You are an authentication assistant. Collect the user's account ID
and date of birth. Call verify_identity to authenticate.
Once verified, say 'You're all set' and stop.""",
)
# Run until authentication completes
await auth_agent.run(inputs=[ws_input], outputs=[ws_output])
# Phase 2: Account management (new session, new prompt, new tools)
banking_session = BidiNovaSonicModel(
model_id="amazon.nova-2-sonic-v1:0",
mcp_gateway_arn=["arn:...gateway/banking-tools"], # Only banking tools
)
banking_agent = BidiAgent(
model=banking_session,
tools=[],
system_prompt="""You are a banking assistant. The user is already authenticated.
Help with balance inquiries, transactions, and transfers.
Keep responses to one or two sentences.""",
)
await banking_agent.run(inputs=[ws_input], outputs=[ws_output])
Cada fase obtém uma sessão limpa do Nova Sonic com:
System prompt focado: Mais curto, mais específico, menos espaço para o modelo se confundir.
Apenas as ferramentas relevantes: via MCP gateways, ferramentas locais ou ambos. O modelo não desperdiça ciclos de raciocínio escolhendo entre 15 ferramentas quando precisa de apenas 3.
Opcionalmente seus próprios sub-agentes: uma fase que requer raciocínio mais profundo pode usar o Padrão 2 internamente, enquanto fases mais simples ficam apenas com ferramentas.
O contexto da sessão anterior pode ser passado para a nova sessão como histórico de chat, mantendo a continuidade da conversa geral.
Comparação entre os padrões
Resumo comparativo dos três padrões em relação a fatores-chave:
Latência: Ferramenta (baixa) | Sub-agente (mais alta) | Segmentação de sessão (mais baixa, com latência durante transições)
Conjunto de ferramentas por turno: Ferramenta (ferramentas carregadas) | Sub-agente (ferramentas do sub-agente) | Segmentação (apenas ferramentas da fase)
System prompt: Ferramenta (um prompt grande) | Sub-agente (orquestrador + prompts dos sub-agentes) | Segmentação (prompts pequenos por fase)
Profundidade de raciocínio: Ferramenta (apenas modelo de voz) | Sub-agente (modelo de voz + sub-agente) | Segmentação (apenas modelo de voz por fase)
Continuidade da conversa: Ferramenta (transparente) | Sub-agente (transparente) | Segmentação (requer lógica de handoff entre fases)
Melhores práticas de latência para agentes de voz
Latência é uma consideração fundamental ao construir agentes de voz em comparação com agentes de texto. Seguem técnicas práticas para manter tempos de resposta rápidos:
Comece com modelos pequenos para sub-agentes. O orquestrador de voz usa Nova Sonic para a conversa, mas sub-agentes não precisam de um modelo grande. Comece com Amazon Nova 2 Lite ou Nova 2 Micro. São rápidos, otimizados em custo e lidam bem com a maioria das tarefas especializadas. Você sempre pode fazer upgrade de um sub-agente específico para um modelo maior se a qualidade exigir.
Projete sub-agentes stateful com cache. Um sub-agente stateless que consulta banco de dados ou API a cada chamada adiciona latência toda vez. Em vez disso, projete sub-agentes para cachear resultados de fontes de dados (APIs, funções AWS Lambda, bancos de dados) dentro de uma sessão. Se o sub-agente bancário busca detalhes da conta uma vez, ele deve manter esses dados em memória e servir perguntas subsequentes (saldo, transações, resumo) a partir do cache.
Faça prefetch de dados após autenticação. Isso é especialmente valioso para cenários de contact center. Após um cliente se autenticar, você já sabe quem ele é. Não espere que ele pergunte antes de puxar seus dados. Busque imediatamente saldos de conta, transações recentes, alertas pendentes e status de hipoteca em segundo plano.
Paralelize chamadas de ferramenta independentes. Se o usuário pedir “Me dê uma visão geral das minhas contas”, não chame get_checking_balance, depois get_savings_balance, depois get_credit_card_balance sequencialmente. Use execução concorrente para que três chamadas aconteçam de uma vez. O Strands suporta isso nativamente — o executor de ferramentas do agente roda chamadas independentes em paralelo por padrão.
Use frases de preenchimento para mascarar latência de ferramentas. Quando uma chamada de ferramenta ou delegação de sub-agente é inevitável, instrua o modelo de voz a falar um breve preenchimento enquanto espera: “Deixe-me verificar isso para você…” ou “Um momento enquanto eu consulto…” Isso mantém a conversa viva em vez de cair em silêncio.
Minimize a contagem de ferramentas por sessão. A seleção de ferramentas fica mais lenta conforme o número de ferramentas disponíveis cresce. Se seu agente tem 15 ferramentas mas uma conversa típica usa apenas 3 a 4, considere o padrão de segmentação de sessão para carregar apenas as ferramentas relevantes por fase.
Limpeza de recursos
Após finalizar os testes do exemplo, lembre-se de limpar os recursos criados para evitar custos desnecessários. Siga as instruções do repositório para parar serviços e deletar qualquer infraestrutura implantada.
Conclusão
Migrar um chatbot de texto para um assistente de voz não é um simples trabalho de wrapper. O modelo de interação é fundamentalmente diferente — desde o design de respostas até orçamentos de latência e comportamento de turn-taking. Mas com uma arquitetura multi-agente bem estruturada e o Amazon Bedrock AgentCore, a camada de lógica de negócio permanece intacta. Os sub-agentes já construídos são o maior ativo — reutilize-os.
É possível estender o exemplo para seu próprio caso de uso, integrar suas ferramentas de negócio, refinar prompts para interações por voz e testar o agente em cenários reais para preparar para deploy em produção. Para aprender mais sobre agentes de voz na AWS:
O problema: agentes que esquecem tudo entre sessões
Quem trabalha com IDEs agênticas sabe bem a frustração: você passa dias ou semanas desenvolvendo em uma base de código complexa, com requisitos de negócio específicos, preferências de projeto bem definidas — e toda vez que abre uma nova sessão, o agente começa do zero. Nenhuma memória das conversas anteriores, nenhum contexto acumulado, nenhuma preferência salva.
O resultado prático é que o desenvolvedor precisa repassar as mesmas informações contextuais repetidamente, o que impacta diretamente a produtividade. É exatamente esse problema que a AWS abordou em um tutorial recente, demonstrando como estender a memória conversacional do Kiro CLI por meio de um servidor Protocolo de Contexto de Modelo (MCP) personalizado integrado ao Amazon Bedrock AgentCore Memory.
O que é o Kiro CLI e o Bedrock AgentCore Memory
O Kiro CLI é uma ferramenta que permite interagir com os agentes de IA do Kiro diretamente pelo terminal. Já o Amazon Bedrock AgentCore Memory é um serviço totalmente gerenciado pela AWS que permite que agentes de IA retenham informações de interações passadas, tornando as conversas mais inteligentes e conscientes do contexto.
O serviço oferece capacidades tanto para memória de curto prazo (contexto de trabalho imediato) quanto para memória de longo prazo (aprendizado acumulado entre sessões), com busca semântica integrada. Isso possibilita que agentes retenham contexto, aprendam com interações anteriores e entreguem experiências verdadeiramente personalizadas.
Visão geral da solução
A arquitetura proposta pela AWS é composta por três componentes principais que trabalham em conjunto:
Amazon Bedrock AgentCore Memory: serviço gerenciado responsável por armazenar e recuperar o contexto das conversas, com busca semântica nativa.
Servidor MCP personalizado: expõe as capacidades do AgentCore Memory por meio do protocolo MCP, tornando as operações de memória acessíveis a clientes compatíveis.
Kiro CLI: conecta-se ao servidor MCP via protocolos STDIO para armazenar e recuperar o histórico conversacional.
O servidor MCP atua como uma ponte entre o Kiro CLI e o Amazon Bedrock AgentCore Memory, permitindo que o Kiro mantenha histórico e contexto de conversas entre sessões.
Ferramentas disponíveis no servidor MCP
O servidor MCP organiza suas ferramentas em três categorias:
Ferramentas de conversa: permitem buscar histórico por tópico ou período, armazenar conversas com rastreamento consistente de sessão, recuperar o conteúdo completo de conversas e listar sessões anteriores.
Ferramentas de monitoramento: permitem visualizar estatísticas de uso de memória e a configuração do servidor MCP.
Ferramentas de gerenciamento: permitem deletar sessões específicas e remover dados armazenados quando necessário.
Estratégia de recuperação em dois estágios
A solução adota uma estratégia de recuperação em cascata: primeiro tenta a busca semântica usando a API retrieve_memory_records do Bedrock AgentCore Memory para correspondência conceitual; caso não encontre resultados adequados, recorre à correspondência direta no conteúdo dos eventos, varrendo os payloads brutos das conversas armazenadas nas sessões do AgentCore Memory.
Essa abordagem garante que as conversas sejam recuperáveis independentemente de o processamento semântico já ter sido concluído. Também é possível usar expressões de tempo em linguagem natural nas consultas, como “recente”, “ontem à noite” ou “semana passada”, para localizar conversas relevantes.
3. Criar o recurso de memória e gerar a configuração do agente Kiro
Este passo pode levar alguns minutos para ser concluído:
python3 setup_bedrock_agentcore_memory.py
Durante a execução, será solicitado que você escolha um tipo de identificador de ator. As conversas ficam associadas a esse identificador:
Opção 1 — User ID (padrão): recomendado para uso pessoal. Utiliza o nome de usuário do sistema a partir da variável de ambiente USER. Define ACTOR_ID_TYPE=userid no arquivo agent/kiro_memory.json.
Opção 2 — Project ID: recomendado para isolamento de memória por equipe ou projeto. Requer que você forneça o projectid e o your-project-id. Define ACTOR_ID_TYPE=projectid e PROJECT_ID=your-project-id no arquivo agent/kiro_memory.json.
A estratégia de namespace utilizada é: /strategy/semanticMemoryStrategy/actor/{actorId}/session/{sessionId}
Para definir o agente kiro_memory como padrão, adicione o seguinte ao arquivo cli.json no diretório ~/.kiro/settings/:
{"chat.defaultAgent": "kiro_memory"}
5. Fazer login no Kiro CLI
Para autenticar no Kiro CLI, é necessário ter um AWS Builder ID ou uma assinatura ativa do Kiro pela organização. Caso não tenha, é possível criar um AWS Builder ID seguindo as instruções da documentação oficial.
kiro-cli login --use-device-flow
Selecione a opção Use for Free with Builder ID usando as teclas de seta e pressione Enter. Uma URL será gerada para autenticação. Acesse-a no navegador, faça login com o Builder ID criado, confirme a solicitação e autorize o acesso. Ao retornar ao terminal, a mensagem Logged in successfully confirmará o login.
6. Iniciar o Kiro CLI e verificar as ferramentas disponíveis
kiro-cli --classic
Após iniciar, execute /mcp para listar os servidores MCP configurados na sessão. Depois que o servidor MCP for inicializado com sucesso, execute /tools para listar as ferramentas disponíveis. As seguintes ferramentas estarão acessíveis por meio do agentcore-memory-mcp-server:
clear_all_data — exclui informações de um namespace específico na memória
delete_session — exclui uma sessão específica
get_direct_conversation_history — acessa o conteúdo completo de sessões específicas
get_memory_stats — usa list_memory_records para fornecer uma visão geral da memória
get_server_config — exibe a configuração do servidor MCP
get_session_details — fornece informações sobre uma sessão específica
list_sessions — lista sessões armazenadas anteriormente
search_conversation_history — busca histórico de conversas por tópico ou período
search_memories — outra ferramenta para busca em memória de longo prazo
store_conversation — armazena conversas com IDs de sessão consistentes
Testando a solução na prática
O Kiro CLI invoca os servidores MCP conforme a funcionalidade necessária para responder ao prompt. Os hooks do Kiro CLI são acionados automaticamente para armazenar a conversa após cada interação.
Um exemplo prático de uso seria perguntar ao Kiro sobre um serviço da AWS — como o AWS DevOps Agent — e autorizar o acesso às ferramentas solicitadas. Ao encerrar a sessão com /quit e fazer login novamente, é possível perguntar “O que discutimos sobre o AWS DevOps Agent?” e o Kiro usará o agentcore-memory-mcp-server para buscar as informações relevantes no Bedrock AgentCore Memory.
A partir daí, é possível fazer perguntas de acompanhamento — como integrações disponíveis ou informações de preço — e o contexto acumulado nas sessões anteriores será aproveitado automaticamente. Ao encerrar e retornar em outro momento, o Kiro consegue apresentar um resumo das discussões anteriores em linguagem natural.
Limpeza dos recursos
Caso tenha seguido o tutorial apenas para fins de demonstração e queira evitar cobranças futuras, execute o seguinte comando para excluir os recursos criados:
python3 cleanup_bedrock_agentcore_memory.py
Também é necessário excluir manualmente a configuração do agente em ~/.kiro/agents/kiro_memory.json e os hooks em ~/.kiro/hooks/.
Conclusão
A AWS demonstrou com esse tutorial como é possível resolver um dos principais pontos de atrito no uso de IDEs agênticas: a perda de contexto entre sessões. Ao combinar o Kiro CLI com um servidor MCP personalizado integrado ao Amazon Bedrock AgentCore Memory, a solução entrega persistência de contexto de forma confiável — sem que o desenvolvedor precise repetir as mesmas informações a cada nova sessão.
Recursos como busca semântica, expressões de tempo em linguagem natural e a estratégia de recuperação em cascata tornam o histórico conversacional acessível de forma inteligente, elevando significativamente a produtividade no desenvolvimento com agentes de IA.
