Author: Make.com Service User

  • SageMaker AI agora aceita a API compatível com OpenAI nos endpoints de inferência

    O que mudou no SageMaker AI

    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"))

    Permissões IAM necessárias

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "sagemaker:InvokeEndpoint",
          "Resource": "arn:aws:sagemaker:::endpoint/"
        },
        {
          "Effect": "Allow",
          "Action": "sagemaker:CallWithBearerToken",
          "Resource": "*"
        }
      ]
    }

    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}")
    import time
    TIMESTAMP = str(int(time.time()))
    
    SME_MODEL_NAME = f"openai-compat-sme-model-{TIMESTAMP}"
    SME_ENDPOINT_CONFIG_NAME = f"openai-compat-sme-epc-{TIMESTAMP}"
    SME_ENDPOINT_NAME = f"openai-compat-sme-ep-{TIMESTAMP}"
    
    print(f"Timestamp suffix: {TIMESTAMP}")
    print(f"Model: {SME_MODEL_NAME}")
    print(f"Endpoint config: {SME_ENDPOINT_CONFIG_NAME}")
    print(f"Endpoint: {SME_ENDPOINT_NAME}")
    sagemaker_client.create_model(
        ModelName=SME_MODEL_NAME,
        ExecutionRoleArn=EXECUTION_ROLE,
        PrimaryContainer={
            "Image": VLLM_IMAGE,
            "Environment": {
                "HF_MODEL_ID": MODEL_HF_ID,
                "SM_VLLM_TENSOR_PARALLEL_SIZE": "1",
                "SM_VLLM_MAX_NUM_SEQS": "4",
                "SM_VLLM_ENABLE_AUTO_TOOL_CHOICE": "true",
                "SM_VLLM_TOOL_CALL_PARSER": "hermes",
                "SAGEMAKER_ENABLE_LOAD_AWARE": "1",
            },
        },
    )
    print(f"Model created: {SME_MODEL_NAME}")
    
    sagemaker_client.create_endpoint_config(
        EndpointConfigName=SME_ENDPOINT_CONFIG_NAME,
        ProductionVariants=[
            {
                "VariantName": "variant1",
                "ModelName": SME_MODEL_NAME,
                "InstanceType": INSTANCE_TYPE,
                "InitialInstanceCount": 1,
            }
        ],
    )
    print(f"Endpoint configuration created: {SME_ENDPOINT_CONFIG_NAME}")
    
    sagemaker_client.create_endpoint(
        EndpointName=SME_ENDPOINT_NAME,
        EndpointConfigName=SME_ENDPOINT_CONFIG_NAME,
    )
    print(f"Endpoint creation initiated: {SME_ENDPOINT_NAME}")
    print("Waiting for endpoint to reach InService status (this takes 5-10 minutes)...")
    
    waiter = sagemaker_client.get_waiter("endpoint_in_service")
    waiter.wait(
        EndpointName=SME_ENDPOINT_NAME,
        WaiterConfig={"Delay": 30, "MaxAttempts": 40},
    )
    print(f"Endpoint is InService: {SME_ENDPOINT_NAME}")

    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:

    IC_MODEL_NAME = f"openai-compat-ic-model-{TIMESTAMP}"
    IC_ENDPOINT_CONFIG_NAME = f"openai-compat-ic-epc-{TIMESTAMP}"
    IC_ENDPOINT_NAME = f"openai-compat-ic-ep-{TIMESTAMP}"
    IC_NAME = f"openai-compat-ic-qwen3-4b-{TIMESTAMP}"
    
    print(f"Model: {IC_MODEL_NAME}")
    print(f"Endpoint config: {IC_ENDPOINT_CONFIG_NAME}")
    print(f"Endpoint: {IC_ENDPOINT_NAME}")
    print(f"Inference comp: {IC_NAME}")
    sagemaker_client.create_model(
        ModelName=IC_MODEL_NAME,
        ExecutionRoleArn=EXECUTION_ROLE,
        PrimaryContainer={
            "Image": VLLM_IMAGE,
            "Environment": {
                "HF_MODEL_ID": MODEL_HF_ID,
                "SM_VLLM_TENSOR_PARALLEL_SIZE": "1",
                "SM_VLLM_MAX_NUM_SEQS": "4",
                "SM_VLLM_ENABLE_AUTO_TOOL_CHOICE": "true",
                "SM_VLLM_TOOL_CALL_PARSER": "hermes",
                "SAGEMAKER_ENABLE_LOAD_AWARE": "1",
            },
        },
    )
    print(f"Model created: {IC_MODEL_NAME}")
    
    sagemaker_client.create_endpoint_config(
        EndpointConfigName=IC_ENDPOINT_CONFIG_NAME,
        ExecutionRoleArn=EXECUTION_ROLE,
        ProductionVariants=[
            {
                "VariantName": "variant1",
                "InstanceType": INSTANCE_TYPE,
                "InitialInstanceCount": 1,
            }
        ],
    )
    print(f"Endpoint configuration created: {IC_ENDPOINT_CONFIG_NAME}")
    
    sagemaker_client.create_endpoint(
        EndpointName=IC_ENDPOINT_NAME,
        EndpointConfigName=IC_ENDPOINT_CONFIG_NAME,
    )
    print(f"Endpoint creation initiated: {IC_ENDPOINT_NAME}")
    print("Waiting for endpoint to reach InService status (this takes 5-10 minutes)...")
    
    waiter = sagemaker_client.get_waiter("endpoint_in_service")
    waiter.wait(
        EndpointName=IC_ENDPOINT_NAME,
        WaiterConfig={"Delay": 30, "MaxAttempts": 40},
    )
    print(f"Endpoint is InService: {IC_ENDPOINT_NAME}")
    
    sagemaker_client.create_inference_component(
        InferenceComponentName=IC_NAME,
        EndpointName=IC_ENDPOINT_NAME,
        VariantName="variant1",
        Specification={
            "ModelName": IC_MODEL_NAME,
            "ComputeResourceRequirements": {
                "MinMemoryRequiredInMb": 1024,
                "NumberOfCpuCoresRequired": 2,
                "NumberOfAcceleratorDevicesRequired": 1,
            },
        },
        RuntimeConfig={"CopyCount": 1},
    )
    print(f"Inference component creation initiated: {IC_NAME}")
    print("Waiting for inference component to reach InService status...")
    
    while True:
        desc = sagemaker_client.describe_inference_component(InferenceComponentName=IC_NAME)
        status = desc["InferenceComponentStatus"]
        if status == "InService":
            print(f"Inference component is InService: {IC_NAME}")
            break
        elif status == "Failed":
            raise RuntimeError(f"Inference component failed: {desc.get('FailureReason', 'unknown')}")
        time.sleep(30)

    É 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.

    import boto3
    
    sagemaker_client = boto3.client("sagemaker", region_name="us-west-2")
    
    sagemaker_client.delete_inference_component(InferenceComponentName="")
    sagemaker_client.delete_endpoint(EndpointName="")
    sagemaker_client.delete_endpoint_config(EndpointConfigName="")
    sagemaker_client.delete_model(ModelName="")

    Conclusão

    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.

    Para começar, basta fazer o deploy de um modelo em um endpoint de inferência em tempo real do SageMaker AI usando um container suportado, instalar o SDK Python do SageMaker e apontar o cliente OpenAI para a URL do endpoint. Para se aprofundar, consulte a documentação Use SageMaker AI with OpenAI-compatible APIs no guia do desenvolvedor, ou acesse o console do Amazon SageMaker AI para criar seu primeiro endpoint.

    Fonte

    Announcing OpenAI-compatible API support for Amazon SageMaker AI endpoints (https://aws.amazon.com/blogs/machine-learning/announcing-openai-compatible-api-support-for-amazon-sagemaker-ai-endpoints/)

  • AWS Security Hub Extended agora conta com 21 soluções parceiras em 9 categorias de segurança

    O que mudou no Security Hub Extended

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

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

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

    O que é o Security Hub Extended

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

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

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

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

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

    Modelo comercial: sem amarras de longo prazo

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

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

    Disponibilidade

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

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

    Fonte

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

  • Por que o Amazon Bedrock AgentCore escolheu o Cedar para proteger fluxos de trabalho agênticos

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

    Fonte

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

  • AWS Security Hub Extended: Por que produtos de segurança enterprise deveriam se vender por conta própria

    Uma nova forma de adotar segurança enterprise

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

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

    O problema com o modelo atual de aquisição

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

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

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

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

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

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

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

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

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

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

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

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

    Como funciona na prática

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

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

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

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

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

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

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

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

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

    Onde o produto está hoje e para onde vai

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

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

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

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

    Por que isso importa para equipes de segurança brasileiras

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

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

    Fonte

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

  • Chamada Programática de Ferramentas no Amazon Bedrock: três formas de implementar

    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.
    Imagem original — fonte: Aws

    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.

    Imagem original — fonte: Aws

    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.

    Imagem original — fonte: Aws

    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.

    Imagem original — fonte: Aws

    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.

    docker run --rm \
      --network none \
      --read-only \
      --tmpfs /tmp:size=64m \
      --user sandbox \
      --cap-drop ALL \
      --memory 256m \
      --cpus 0.5 \
      -v /path/to/code.py:/sandbox/user_code.py:ro \
      ptc-sandbox

    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.

    Imagem original — fonte: Aws

    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.

    Imagem original — fonte: Aws

    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
    • Grace Taylor: orçamento US$ 5.000, gasto US$ 6.474,46, excedeu em +US$ 1.474,46

    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.

    Para quem quiser explorar mais, a AWS disponibiliza a documentação oficial de PTC da Anthropic, o repositório de exemplos no GitHub com o padrão PTC, a documentação do AgentCore Code Interpreter e o repositório do proxy Anthropic-Bedrock.

    Fonte

    Implementing programmatic tool calling on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/implementing-programmatic-tool-calling-on-amazon-bedrock/)

  • Amazon SageMaker HyperPod passa a suportar captura de dados para cargas de trabalho de inferência

    O que foi anunciado

    A AWS anunciou que o Amazon SageMaker HyperPod passa a oferecer suporte nativo à captura de dados para cargas de trabalho de inferência. Com esse novo recurso, organizações que executam modelos de Inteligência Artificial Generativa (IA Generativa) e aprendizado de máquina no HyperPod conseguem registrar sistematicamente os payloads de requisição e resposta dos seus modelos em produção.

    Por que isso importa

    Quem opera modelos de machine learning em produção sabe que a visibilidade sobre o que entra e o que sai do modelo é fundamental. Sem esse registro, fica difícil detectar deriva de modelo (model drift), atender exigências de auditoria regulatória, investigar problemas em produção e construir datasets de ground-truth para fine-tuning.

    Antes desse recurso, as equipes precisavam aceitar uma visibilidade operacional limitada ou investir na construção de pipelines de logging customizados fora do HyperPod Inference Operator — o que representa custo, complexidade e retrabalho. Agora, a AWS oferece essa capacidade de forma integrada à plataforma.

    Como funciona a captura de dados

    O recurso permite escolher em qual ponto do fluxo o tráfego de inferência será registrado. As opções disponíveis são:

    • No endpoint do SageMaker — captura no ponto de entrada do serviço;
    • No load balancer — captura no balanceador de carga;
    • No pod do modelo — captura diretamente na unidade de execução do modelo.

    Essas opções podem ser combinadas para criar uma observabilidade em camadas, conforme o nível de visibilidade necessário para cada cenário.

    Os dados capturados são entregues de forma assíncrona para um bucket do Amazon S3 configurado pela própria equipe. O recurso suporta amostragem configurável e criptografia com chaves gerenciadas pelo cliente via AWS KMS (Serviço de Gerenciamento de Chaves), permitindo equilibrar cobertura com custo e manter dados sensíveis protegidos.

    Um ponto importante: a captura de dados é projetada para nunca bloquear a inferência, ou seja, a disponibilidade em produção é preservada independentemente do volume de dados registrados.

    Como habilitar o recurso

    A captura de dados pode ser ativada ao configurar o endpoint de inferência durante o deploy de modelos, seja pelo HyperPod Inference Operator ou pelo SageMaker JumpStart.

    O recurso está disponível para clusters SageMaker HyperPod que utilizam o orquestrador EKS (Elastic Kubernetes Service — Serviço Elástico de Kubernetes), em todas as regiões da AWS onde o Amazon SageMaker HyperPod é suportado.

    Para mais detalhes técnicos sobre configuração e uso, a AWS disponibiliza a documentação oficial: Captura de dados para inferência no HyperPod.

    Fonte

    Amazon SageMaker HyperPod now supports data capture for inference workloads (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-sagemaker-hyperpod-data-capture)

  • Amazon Inspector agora disponível na Região AWS Ásia-Pacífico (Taipei)

    Expansão do Amazon Inspector para Taipei

    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.

    Fonte

    Amazon Inspector is now available in the AWS Asia Pacific (Taipei) Region (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-inspector-taipei/)

  • CIRT da AWS: Como Prevenir a Remoção Não Autorizada de Contas do AWS Organizations

    O que é o CIRT da AWS e por que isso importa

    A Equipe de Resposta a Incidentes de Clientes da AWS (CIRT) atua diretamente com organizações que estão enfrentando incidentes de segurança ativos. Ao longo desse trabalho, a equipe identifica padrões e táticas emergentes usadas por agentes maliciosos — especialmente aquelas que exploram configurações e decisões de design dos próprios clientes.

    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.

    Um detalhe importante: o ataque não exige necessariamente credenciais root comprometidas. O invasor pode partir de qualquer credencial e escalar privilégios até obter essa permissão — seja assumindo uma role que já a possui, seja concedendo a permissão à credencial atual. Isso reforça por que a abordagem de menor privilégio é tão fundamental. Para aprofundar, a AWS disponibiliza a documentação do AWS Identity and Access Management (IAM) e orientações sobre design de unidades organizacionais (OU) e implementação de políticas de controle de serviço (SCP).

    O impacto: o que acontece quando uma conta sai da organização

    Quando uma conta é removida do Organizations, uma série de proteções deixa de existir imediatamente:

    • As SCPs que bloqueavam ações destrutivas, restringiam regiões ou impediam chamadas de API específicas deixam de ser aplicadas.
    • A conta sai do faturamento consolidado, e os alertas de custo e detecção de anomalias da organização param de monitorá-la.
    • As trilhas organizacionais do AWS CloudTrail param de capturar eventos da conta removida.
    • Os alertas do Amazon GuardDuty gerenciados via administrador delegado deixam de chegar à conta central de segurança.

    O resultado prático é que a organização perde visibilidade completa sobre a conta — enquanto ela ainda contém recursos e dados da empresa.

    Técnicas relacionadas no catálogo de ameaças

    O CIRT mapeou esse padrão de ataque em entradas específicas do catálogo de técnicas de ameaças para AWS:

    Como detectar essa técnica

    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.

    O Catálogo de Técnicas de Ameaças para AWS inclui orientações de detecção para as técnicas subjacentes a esse padrão de ataque.

    Recursos adicionais

    Fonte

    CIRT insights: How to help prevent unauthorized account removals from AWS Organizations (https://aws.amazon.com/blogs/security/cirt-insights-how-to-help-prevent-unauthorized-account-removals-from-aws-organizations/)

  • Design escalável de agentes de voz com Amazon Nova Sonic: multi-agente, ferramentas e segmentação de sessão

    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:

    • Streaming bidirecional via WebSocket com autenticação SigV4
    • 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.

    Fonte: Aws

    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.
    Fonte: Aws

    O Strands Agents tem suporte nativo para ambos os protocolos — MCP para acesso a ferramentas e A2A para comunicação agente-a-agente. Para um tutorial prático, consulte o guia da comunidade sobre Agent Collaboration: Strands Agents, MCP, and the Agent2Agent Protocol.

    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.

    Fonte: Aws

    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)
    • Reuso de agentes existentes: Ferramenta (alto) | Sub-agente (mais alto) | Segmentação (médio)
    • 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.

    Para um exemplo funcional de um assistente de voz Strands BidiAgent implantado no AgentCore Runtime com streaming WebSocket, consulte o exemplo de streaming bidirecional do AgentCore.

    Próximos passos e recursos

    É 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:

    Fonte

    Scalable voice agent design with Amazon Nova Sonic: multi-agent, tools, and session segmentation (https://aws.amazon.com/blogs/machine-learning/scalable-voice-agent-design-with-amazon-nova-sonic-multi-agent-tools-and-session-segmentation/)

  • Estendendo a memória conversacional do Kiro CLI com o Amazon Bedrock AgentCore Memory

    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.

    Pré-requisitos

    Para seguir o tutorial, é necessário ter:

    Passo a passo da configuração

    1. Clonar o repositório

    git clone https://github.com/aws-samples/sample-amazon-bedrock-agentcore-memory-mcp-server.git

    2. Criar ambiente virtual Python e instalar dependências

    cd sample-amazon-bedrock-agentcore-memory-mcp-server
    python3 -m venv venv; source venv/bin/activate; pip3 install -r requirements.txt;

    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}

    4. Configurar o agente Kiro

    mkdir -p ~/.kiro/agents/
    mkdir -p ~/.kiro/hooks/
    cp -p agent/kiro_memory.json ~/.kiro/agents/
    cp -p hooks/cache-prompt.sh ~/.kiro/hooks/
    cp -p hooks/load-preferences.sh ~/.kiro/hooks/
    cp -p hooks/store-conversation.sh ~/.kiro/hooks/
    chmod 755 ~/.kiro/hooks/*

    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.

    Fonte

    Extending conversational memory in Kiro CLI using Amazon Bedrock AgentCore Memory (https://aws.amazon.com/blogs/machine-learning/extending-conversational-memory-in-kiro-cli-using-amazon-bedrock-agentcore-memory/)