Blog

  • Como Fazer Deploy e Avaliar Modelos com o Amazon SageMaker JumpStart

    Por que avaliar modelos antes de escolher?

    Escolher o modelo certo para uma aplicação vai muito além de ler benchmarks genéricos. O que realmente importa é testar o modelo com entradas representativas do seu caso de uso — e fazer isso de forma repetível. O Amazon SageMaker JumpStart oferece exatamente esse caminho: um catálogo amplo de modelos pré-treinados que podem ser implantados, testados e removidos de forma controlada, tudo via código ou interface gráfica.

    A abordagem descrita pela AWS usa um script Python reutilizável que percorre três etapas: descoberta e deploy do modelo, execução de prompts de exemplo com medição de latência e taxa de geração, e remoção do endpoint ao final. Vale lembrar que o tempo de deploy varia conforme o modelo, o tipo de instância, a cota disponível e a Região AWS utilizada.

    Novidades de 2026 no SageMaker JumpStart

    Em 2026, o SageMaker JumpStart recebeu duas melhorias relevantes. A primeira é a seção Model Hub no console do Amazon SageMaker AI, que permite navegar pelo catálogo, visualizar notebooks de exemplo e abri-los diretamente no SageMaker Studio. A segunda é a disponibilização de configurações de endpoint pré-definidas, otimizadas para diferentes prioridades — baixo custo, baixa latência ou cargas de trabalho de uso geral — incluindo configurações otimizadas para chips Neuron, cobrindo uma ampla gama de modelos de IA Generativa (Generative AI).

    Além disso, agora é possível ir da descoberta de um modelo no Hugging Face até o deploy no SageMaker AI com um único clique, graças à nova integração de deep link entre as duas plataformas.

    Pré-requisitos

    • Conta AWS com permissões para o SageMaker AI
    • Python 3+ com o SageMaker Python SDK v3 instalado (pip install "sagemaker>=3,<4")
    • Cota suficiente de instâncias GPU para o modelo desejado — caso necessário, é possível solicitar aumento de cota

    Passo 1a: Descobrindo modelos disponíveis

    Além de navegar pelo catálogo pela interface do SageMaker Studio, é possível listar os modelos disponíveis diretamente via código. O exemplo abaixo lista os modelos de geração de texto disponíveis na região us-east-1:

    from sagemaker.core.jumpstart.notebook_utils import (
        list_jumpstart_models,
    )
    
    REGION = "us-east-1"
    models = list_jumpstart_models(
        filter="task == textgeneration",
        region=REGION,
        list_versions=True,
    )
    print(f"Found {len(models)} text generation models")
    for model_id, model_version in models[:10]:
        print(
            f" - {model_id} "
            f"(version {model_version})"
        )

    Também é possível buscar por nome de modelo específico:

    from sagemaker.core.jumpstart.notebook_utils import list_jumpstart_models
    
    ids = list_jumpstart_models(
        filter="model_id contains qwen",
        region=REGION,
        list_versions=True,
    )
    print(f"{len(ids)} models matched in {REGION}\n")
    for model_id, version in ids:
        print(f"{model_id:<55} v{version}")

    Passo 1b: Fazendo o deploy do modelo

    Com o modelo identificado, o deploy pode ser feito via SDK. O código abaixo resolve automaticamente a configuração recomendada pelo JumpStart — incluindo o tipo de instância ideal — e sobe o endpoint:

    import time
    from sagemaker.core.jumpstart.accessors import JumpStartModelsAccessor
    from sagemaker.core.jumpstart.configs import JumpStartConfig
    from sagemaker.core.training.configs import Compute
    from sagemaker.serve import ModelBuilder
    
    MODEL_ID = "huggingface-vlm-qwen3-5-27b"
    MODEL_VERSION = "1.13.0"
    REGION = "us-east-1"
    ACCEPT_EULA = False  # Set True only after reviewing the model terms
    
    def get_field(value, name, default=None):
        if isinstance(value, dict):
            return value.get(name, default)
        return getattr(value, name, default)
    
    # Resolve the JumpStart-recommended deployment configuration.
    specs = JumpStartModelsAccessor().get_model_specs(
        region=REGION,
        model_id=MODEL_ID,
        version=MODEL_VERSION,
    )
    if isinstance(specs, list):
        if not specs:
            raise ValueError(
                f"No JumpStart specification found for {MODEL_ID}"
            )
        specs = specs[0]
    
    recommended_instance_type = get_field(
        specs,
        "default_inference_instance_type",
    )
    if not recommended_instance_type:
        raise ValueError(
            f"No recommended instance type found for {MODEL_ID}"
        )
    
    print(f"Model: {MODEL_ID}")
    print(f"Region: {REGION}")
    print(f"Recommended instance: {recommended_instance_type}")
    
    start = time.time()
    jumpstart_config = JumpStartConfig(
        model_id=MODEL_ID,
        model_version=MODEL_VERSION,
        accept_eula=ACCEPT_EULA,
    )
    model_builder = ModelBuilder.from_jumpstart_config(
        jumpstart_config=jumpstart_config,
        compute=Compute(
            instance_type=recommended_instance_type,
            instance_count=1,
        ),
    )
    model = model_builder.build()
    endpoint = model_builder.deploy()
    deploy_time = time.time() - start
    print(f"Deployed in {deploy_time:.1f} seconds")
    print(f"Endpoint: {endpoint.endpoint_name}")

    Um ponto importante: a variável ACCEPT_EULA deve ser definida como True apenas após a leitura e aceite dos termos de uso do modelo. Alguns modelos no JumpStart exigem esse aceite explícito antes do deploy.

    Passo 2: Executando prompts e medindo desempenho

    Com o endpoint ativo, o próximo passo é executar os prompts de exemplo disponíveis para o modelo e medir latência, volume de saída e taxa de geração por segundo. O código abaixo faz exatamente isso:

    from sagemaker.core.payloads import retrieve_all_examples
    import json
    import time
    
    MODEL_ID = "huggingface-vlm-qwen3-5-27b"
    MODEL_VERSION = "1.13.0"
    REGION = "us-east-1"
    
    example_payloads = retrieve_all_examples(
        region=REGION,
        model_id=MODEL_ID,
        model_version=MODEL_VERSION,
        serialize=True,
    )
    
    #you can re-create the endpoint pointer using the endpoint name:
    #from sagemaker.core.resources import Endpoint
    #endpoint = Endpoint.get(endpoint_name="<your_endpoint_name>",region=REGION)
    
    def read_response_body(result):
        body = result.body
        if hasattr(body, "read"):
            body = body.read()
        if isinstance(body, bytes):
            body = body.decode("utf-8")
        if isinstance(body, str):
            try:
                return json.loads(body)
            except json.JSONDecodeError:
                return body
        return body
    
    def extract_output(response):
        """Handle common JumpStart text-generation response formats."""
        if isinstance(response, list):
            response = response[0] if response else ""
        if isinstance(response, dict):
            choices = response.get("choices")
            if choices:
                choice = choices[0]
                message = choice.get("message")
                if isinstance(message, dict):
                    return message.get("content", "")
                return choice.get("text", "")
            for field in (
                "generated_text",
                "output_text",
                "text",
            ):
                if field in response:
                    return response[field]
        return response
    
    results = []
    for payload in example_payloads or []:
        start = time.perf_counter()
        result = endpoint.invoke(
            body=payload.body,
            content_type=payload.content_type,
            accept=payload.accept,
        )
        latency = time.perf_counter() - start
        response = read_response_body(result)
        output = extract_output(response)
        if not isinstance(output, str):
            output = json.dumps(output, indent=2)
    
        # This is an estimate based on whitespace-separated words.
        output_words = len(output.split())
        results.append(
            {
                "request_preview": payload.body[:50],
                "latency_s": round(latency, 2),
                "estimated_output_words": output_words,
                "words_per_second": round(
                    output_words / latency, 1,
                ) if latency > 0 else 0,
            }
        )
        print("Input:\n", payload.body, end="\n\n")
        print("Output:\n", output, end="\n\n")
        print(
            f"Latency: {latency:.2f} seconds\n"
            f"Estimated output words: {output_words}\n"
            f"Estimated single-request output generation rate: "
            f"{output_words / latency:.1f} words/second\n"
        )
        print("-" * 80)
    
    print("\nSummary:")
    for result in results:
        print(result)

    Um exemplo real de resultado obtido com o modelo huggingface-vlm-qwen3-5-27b, ao perguntar "What is deep learning?", retornou 153 palavras estimadas em 9,07 segundos — uma taxa de aproximadamente 16,9 palavras por segundo. Esses números servem como referência para comparação entre modelos diferentes.

    Passo 3: Removendo o endpoint

    Após os testes, é fundamental remover o endpoint para evitar cobranças desnecessárias. O processo é direto:

    print(f"Deleting endpoint: {endpoint.endpoint_name}")
    endpoint.delete()
    endpoint.wait_for_delete()
    print("Endpoint deleted")

    Considerações finais

    Esse fluxo funciona para a maioria dos modelos compatíveis com o SageMaker JumpStart, mas é importante estar atento a variações: o formato do payload, o tipo de instância necessário, os requisitos de Contrato de Licença de Usuário Final (EULA) e o esquema de resposta podem exigir ajustes específicos por modelo.

    Ao usar prompts consistentes e medir latência, throughput e qualidade de saída em diferentes modelos, equipes conseguem comparar opções de forma objetiva e escolher aquela que melhor equilibra qualidade, velocidade e custo para cada aplicação.

    Para aprofundar o tema, a AWS disponibiliza recursos adicionais: a documentação oficial do SageMaker Python SDK, um post sobre benchmark e otimização de deploys no SageMaker JumpStart, e um guia sobre a integração entre Hugging Face e SageMaker Studio em um clique.

    Fonte

    Deploy and evaluate models with Amazon SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/deploy-and-evaluate-models-with-amazon-sagemaker-jumpstart/)

  • Amazon SageMaker Studio simplifica o início para novos desenvolvedores de IA/ML com login social

    Acesso simplificado ao SageMaker Studio com login social

    A AWS anunciou uma mudança significativa na experiência de entrada do Amazon SageMaker Studio: novos usuários agora podem se cadastrar usando suas credenciais do Google, GitHub ou Apple e chegar diretamente a um ambiente de desenvolvimento de Inteligência Artificial e Aprendizado de Máquina (IA/ML) completamente configurado — sem precisar criar uma conta AWS tradicional, sem informar cartão de crédito e sem navegar pelo console da AWS.

    Como era o processo antes

    Anteriormente, quem descobria um modelo no Hugging Face ou em uma página de produto da AWS precisava passar por um processo longo antes de conseguir trabalhar de fato: criar uma conta AWS em múltiplas etapas, fornecer cartão de crédito, navegar pelo Console da AWS até encontrar o SageMaker AI, configurar o ambiente e definir permissões de Gerenciamento de Identidade e Acesso (IAM). Um caminho que afastava muitos iniciantes.

    Em lançamentos anteriores, a AWS já havia reduzido o tempo de configuração do ambiente para vinte segundos, pré-configurado permissões de personalização de modelos e introduzido links diretos a partir do Hugging Face e de páginas de produtos, permitindo que os usuários chegassem ao Studio com um modelo já carregado.

    O que muda com o login social

    Com a nova funcionalidade de login social, o fluxo de entrada foi ainda mais simplificado. Novos usuários:

    • Concluem o cadastro usando uma identidade já existente (Google, GitHub ou Apple);
    • Recebem créditos gratuitos como parte do Nível Gratuito da AWS (AWS Free Tier), sem necessidade de cartão de crédito;
    • Chegam diretamente a um ambiente SageMaker Studio pronto para uso, onde podem ajustar, avaliar e implantar modelos de fundação imediatamente.

    Colaboração em equipe sem configuração de permissões

    Outro ponto relevante é o suporte à colaboração. Usuários podem convidar membros da equipe por e-mail, e cada colaborador entra com suas próprias credenciais sociais para acessar o ambiente compartilhado — incluindo modelos, notebooks e endpoints — sem precisar configurar usuários ou permissões de IAM manualmente.

    Crescimento além dos créditos gratuitos

    Quando o projeto crescer além dos créditos gratuitos, os usuários podem migrar para um plano pago e definir um limite de gastos para manter o orçamento sob controle. Além disso, usuários verificados mantêm acesso padrão a instâncias GPU dos tipos G5, G6, G6e e G4dn para implantações de endpoints, jobs de treinamento e notebooks, sem precisar solicitar aumentos de cota.

    Disponibilidade e como começar

    O recurso está disponível em todas as regiões comerciais da AWS onde o Amazon SageMaker Studio é suportado. Para experimentar, basta acessar qualquer modelo compatível no Hugging Face e selecionar “Customize and Deploy on SageMaker AI” ou “Deploy on SageMaker AI”, ou clicar em Get Started na página do SageMaker Studio. Para mais detalhes, consulte a documentação de cadastro da AWS e o guia de configuração do SageMaker Studio.

    Fonte

    Amazon SageMaker Studio simplifies getting started for new AI/ML builders with social sign-in (https://aws.amazon.com/about-aws/whats-new/2026/10/sagemaker-studio-social-sign-in/)

  • Teste de Penetração em Cada Deploy com o AWS Continuum

    O problema com as ferramentas tradicionais de segurança no pipeline

    A maioria das ferramentas de segurança que se encaixam em um pipeline de Integração Contínua/Entrega Contínua (CI/CD) — como análise estática (SAST), análise de composição de software (SCA) e scanners dinâmicos (DAST) — identificam problemas potenciais com base em padrões e assinaturas conhecidas. Elas mostram onde olhar, mas não confirmam se algo é de fato explorável.

    Essa confirmação sempre veio de testes de penetração periódicos, realizados fora do ciclo de entregas — tipicamente uma vez por trimestre. O resultado prático: deploys feitos entre esses engagements chegam à produção sem que ninguém tenha validado se as mudanças introduziram uma brecha real.

    É exatamente esse gap que o AWS Continuum para testes de penetração (anteriormente chamado de AWS Security Agent) propõe resolver. O serviço usa agentes de IA para encontrar e confirmar vulnerabilidades exploráveis em aplicações em execução, e pode ser configurado como um gate automático no pipeline de CI/CD.

    Como funciona o gate de pentest no pipeline

    A ideia central é simples: após cada deploy em ambiente de staging, o pipeline chama o Continuum para executar um teste de penetração automaticamente limitado à mudança recém-implantada. Se o resultado estiver acima de um limiar de severidade configurado, a promoção para produção é bloqueada.

    O fluxo completo funciona assim: o pipeline faz o deploy em staging, o gate se autentica na conta AWS via OpenID Connect (OIDC) e aciona o Continuum, que executa o teste no ambiente de staging. O gate aguarda o resultado e decide se a promoção segue ou é bloqueada. Toda a lógica de teste roda no lado do servidor, dentro da conta AWS — nenhum código de pentest é executado no runner do CI/CD.

    Imagem original — fonte: Aws

    O padrão descrito pela AWS é compatível com quatro plataformas principais de CI/CD: GitHub Actions, GitLab CI/CD, Bitbucket Pipelines e Azure DevOps Pipelines.

    Por que limitar o escopo à mudança importa

    O que torna o gate viável para rodar em cada deploy é justamente o escopo reduzido. O Continuum determina o intervalo de commits — o head é o commit sendo avaliado, e o base é o último commit que já passou pelo gate — e testa apenas o que mudou. Isso mantém o teste rápido e econômico o suficiente para ser parte do pipeline, e não de um calendário trimestral.

    Cada execução retorna uma de três decisões de escopo:

    • In scope (dentro do escopo): a mudança alterou a superfície de ataque — os findings são avaliados contra o limiar de severidade configurado.
    • Scoped out (fora do escopo): a mudança estava no escopo, mas nada relevante para segurança foi alterado — o pipeline passa.
    • Scope conflict (conflito de escopo): a mudança ficou fora do escopo configurado e não foi testada — você decide se isso bloqueia ou não.

    Para entender os detalhes de como o intervalo de commits é calculado e validado, a AWS disponibilizou a documentação Como a integração de pipeline determina o escopo do teste.

    Configurando o gate: três passos

    Passo 1: Configurar o teste de penetração

    O primeiro passo é uma configuração única: verificar o domínio alvo, criar um teste de penetração no Agent Space, habilitar o modo CI/CD e conectar o repositório. Conforme descrito em Antes de começar, é necessário anotar o Agent Space ID (prefixo as-…) e o ID do teste de penetração (prefixo pt-…), pois ambos serão usados na configuração do gate.

    Passo 2: Criar a role IAM

    A autenticação usa federação via OIDC em vez de chaves de acesso armazenadas. O provedor de CI/CD emite um token de curta duração identificando o pipeline, e o AWS Security Token Service (AWS STS) o troca por credenciais temporárias quando o pipeline assume uma role do Gerenciamento de Identidade e Acesso (IAM) criada pelo time.

    Sem chaves de acesso de longa duração armazenadas como variáveis no CI/CD, elimina-se o vetor de vazamento de credenciais mais comum em pipelines. A segurança do gate depende de duas políticas: a trust policy da role IAM (quais pipelines podem assumir a role) e a permissions policy (o que o pipeline pode fazer após assumir a role).

    Para os JSONs exatos das políticas, URLs de OIDC por provedor e o formato do sub claim, a AWS recomenda seguir as referências de Escopo da trust policy para seu pipeline e Conceder permissões de menor privilégio.

    Um detalhe importante: repositórios GitHub criados ou renomeados a partir de 15 de julho de 2026 emitem um sub claim imutável com IDs numéricos — é necessário confirmar o sub exato que o pipeline emite antes de escrever a política.

    Passo 3: Adicionar o gate step ao pipeline

    A etapa é conceitualmente a mesma em todos os provedores — apenas a sintaxe varia. A AWS recomenda fixar a integração a uma versão imutável (tag de release, SHA de commit ou versão de componente fixada) para que uma mudança upstream não altere o que roda no pipeline.

    Antes de confiar no gate em produção, o recomendado é executá-lo uma vez em modo dry-run. Esse modo verifica autenticação, região e resolução do repositório sem iniciar um teste de penetração de fato. Se a validação falhar, o step falha imediatamente — o que faz com que erros de configuração apareçam cedo. Os valores padrão da integração estão documentados em Padrões da integração.

    Exemplo prático: GitHub Actions

    O workflow abaixo ilustra a topologia de três jobs que faz o gate funcionar: deploy faz o deploy em staging, security-pentest executa o gate, e deploy-prod promove para produção. Como deploy-prod declara needs: [security-pentest], o GitHub pula a produção sempre que o gate falha.

    jobs:
      deploy:
        runs-on: ubuntu-latest
        environment: staging
        steps:
          - uses: actions/checkout@v4
            with:
              persist-credentials: false
          - run: ./deploy.sh staging
    
      security-pentest:
        needs: [deploy]
        runs-on: ubuntu-latest
        permissions:
          id-token: write
          contents: write
          actions: read
          deployments: read
        steps:
          - uses: aws-actions/configure-aws-credentials@v4
            with:
              role-to-assume: arn:aws:iam::111122223333:role/my-pentest-gate-role
              aws-region: us-west-2
              role-duration-seconds: 7200
          - uses: aws-actions/aws-continuum-run-pentest@v1
            with:
              agent-space-id: as-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
              pentest-id: pt-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
              severity-threshold: HIGH
              on-scope-conflict: block
              timeout-minutes: "45"
    
      deploy-prod:
        needs: [security-pentest]
        runs-on: ubuntu-latest
        environment: production
        steps:
          - uses: actions/checkout@v4
            with:
              persist-credentials: false
          - run: ./deploy.sh production

    Dois pontos merecem atenção especial nesse exemplo. Primeiro, a permissão contents: write permite que o gate avance o marcador de baseline que ele mantém como referência no repositório — sem acesso de escrita, cada execução testaria um intervalo mais amplo do que o necessário. Segundo, o role-duration-seconds: 7200 no step de credenciais precisa ser maior que a duração do teste de penetração; o AWS STS rejeita uma requisição que exceda o máximo permitido pela role em vez de reduzi-la automaticamente — portanto, a duração máxima de sessão da role deve ser configurada para pelo menos (timeout + 10) x 60 segundos.

    Rollout gradual: do modo relatório ao bloqueio real

    Três configurações independentes determinam se o step falha, cada uma cobrindo um cenário diferente: severity-threshold (o que acontece com os findings), on-scope-conflict (o que acontece quando a mudança não foi testada) e fail-on-infrastructure-error (o que acontece quando o job não conseguiu rodar). Relaxar uma não afeta as outras.

    A abordagem recomendada é introduzir o gate em modo relatório primeiro — definindo o threshold como NONE para que o teste rode e publique findings sem bloquear o pipeline. Após observar o que ele encontra por um ou dois ciclos de release, o threshold é ajustado para HIGH.

    Há uma ressalva crítica nessa estratégia: uma execução que passa — incluindo execuções em modo relatório — avança o baseline. Os commits daquele intervalo são registrados como aprovados e não serão re-testados quando o threshold for ajustado. Se o gate rodar em modo relatório por um mês e depois for configurado para HIGH, ele avaliará apenas os commits após a última execução em modo relatório — não revisará o que já foi aprovado. Para forçar uma reavaliação de um intervalo já aprovado, é possível sobrescrever os SHAs de head e base usando os parâmetros base-commit-sha e head-commit-sha.

    Outro padrão que merece atenção: fail-on-infrastructure-error vem configurado como false por padrão (falha aberta). Para pipelines onde a promoção exige aprovação de segurança, a recomendação é definir como true desde o início. Para entender como o baseline avança em cada provedor, a documentação O que avança o baseline e por que isso importa traz a matriz completa.

    Atenção especial ao GitLab

    No GitLab CI/CD, uma variável de pipeline substitui o valor definido no .gitlab-ci.yml. Isso significa que qualquer pessoa com permissão para rodar um pipeline poderia fornecer uma variável que reduz o threshold, ativa o dry-run ou relaxa o tratamento de erros — e o gate obedece à variável, não ao arquivo de configuração. A recomendação é restringir quem pode sobrescrever variáveis nas configurações de CI/CD do projeto antes de confiar no gate para segurar um release.

    Proteção de credenciais no runner

    As credenciais temporárias e o token OIDC são sensíveis durante toda a duração do step. Três práticas são essenciais:

    • Manter o rastreamento de debug e verbose desativado para steps que lidam com credenciais — modos de shell-trace (como o CI_DEBUG_TRACE do GitLab) ecoam argumentos de comandos no log do job em texto puro.
    • Não persistir credenciais de controle de versão no workspace — definir persist-credentials: false no step de checkout para que um token não seja gravado na configuração .git do runner.
    • Não expor o token a steps não confiáveis — conceder permissão de token OIDC apenas aos jobs que precisam, e não executar código não confiável (como builds de forks) em um job que pode ler o token.

    Expandindo para múltiplas contas AWS

    O exemplo usa uma única conta para simplificar. Na prática, os ambientes de staging e produção frequentemente ficam em contas AWS separadas. O padrão se expande de forma limpa: cria-se a role IAM de gate na conta onde o teste de penetração e o Agent Space residem — a conta de segurança. O pipeline assume essa role via OIDC independentemente de qual conta de workload ele está fazendo deploy, mantendo uma única role bem delimitada em vez de cópias ou chaves de longa duração em cada conta.

    Para orientações mais amplas sobre o AWS Security Agent — incluindo testes contra ambientes não produtivos, validação de findings gerados por IA e IAM — a AWS disponibilizou o documento Melhores práticas de segurança para o AWS Continuum.

    Limpeza após os testes

    Quem seguir os tutoriais de cada provedor para experimentar o gate deve concluir a seção de limpeza correspondente: remover o ambiente de staging da aplicação de exemplo, a role IAM e o provedor de identidade OIDC e, se criados especificamente para o walkthrough, o teste de penetração e os Agent Spaces dedicados. Isso evita cobranças contínuas e retira do ar a aplicação de exemplo intencionalmente vulnerável.

    Conclusão

    Limitar o escopo dos testes de penetração à mudança deployada é o que torna viável usá-los como gate por deploy, em vez de um exercício trimestral. As decisões-chave para quem for implementar são:

    • Quão rigoroso: começar em modo relatório (NONE), mas lembrar que o baseline avança — apagar o marcador ao apertar o threshold.
    • Como falhar: definir fail-on-infrastructure-error como true para qualquer coisa que exija aprovação de segurança.
    • Como limitar a trust: fixar o sub claim o mais estreitamente que a realidade de deploy permitir.
    • Onde colocar a role: uma role em uma conta de segurança, assumida pelo pipeline de workloads via OIDC.

    Para construir o gate do início ao fim em cada plataforma, a AWS disponibilizou tutoriais específicos:

    Para os conceitos e referência completa, consulte Executar testes de penetração a partir do pipeline de CI/CD.

    Fonte

    Penetration testing every deployment with AWS Continuum (https://aws.amazon.com/blogs/security/penetration-testing-every-deployment-with-aws-continuum/)

  • AWS License Manager passa a suportar conversão de licenças para Ubuntu Pro comprado pelo AWS Marketplace

    O que foi anunciado

    A AWS anunciou que o AWS License Manager agora suporta conversões de tipo de licença para o Ubuntu Pro adquirido pelo AWS Marketplace. Na prática, isso significa que equipes com instâncias EC2 rodando Ubuntu LTS (Suporte de Longo Prazo) podem fazer o upgrade direto para o Ubuntu Pro — sem precisar reconstruir a frota, migrar cargas de trabalho ou trocar de instância e AMI.

    Por que isso importa para segurança e conformidade

    Com uma assinatura do Ubuntu Pro, os clientes passam a ter acesso a patches de segurança por até 10 anos — prazo que pode ser estendido para 15 anos com o complemento Legacy. E a cobertura vai além do sistema operacional base: ela se estende a milhares de pacotes adicionais, incluindo aplicações open-source amplamente usadas como NGINX, PostgreSQL, MongoDB e Redis.

    Outro ponto relevante é o suporte ao Kernel Livepatch, recurso que aplica correções críticas de segurança no kernel sem necessidade de reinicialização — o que reduz o tempo de inatividade e mantém os ambientes mais estáveis durante as atualizações.

    Como funciona o fluxo de conversão

    Para quem já possui uma assinatura Canonical Ubuntu Pro ativa pelo AWS Marketplace, o upgrade pode ser feito diretamente durante o fluxo de conversão. Já quem ainda não tem uma assinatura pode assinar o Canonical Ubuntu Pro diretamente pelo console do AWS License Manager, sem precisar sair do ambiente AWS para concluir o processo.

    Disponibilidade

    O novo recurso está disponível em todas as regiões comerciais onde o AWS License Manager já está presente.

    Como começar

    Para explorar a funcionalidade, basta acessar o console do AWS License Manager e consultar o Guia do Usuário do AWS License Manager para mais detalhes sobre o processo de conversão.

    Fonte

    AWS License Manager now supports license type conversions for Ubuntu Pro purchased through AWS Marketplace (https://aws.amazon.com/about-aws/whats-new/2026/10/aws-license-manager-conversions-ubuntu-pro-marketplace/)

  • Processamento de documentos que aprende sozinho com o Amazon Bedrock AgentCore

    O custo oculto do processamento manual de documentos

    Uma pesquisa do IDC revela que os desafios relacionados a documentos custam às organizações cerca de US$ 19.732 por trabalhador da informação por ano, além de reduzir a produtividade em 21,3%. Empresas que recebem faturas de centenas de fornecedores enfrentam um problema ainda maior: cada emissor usa um layout diferente, que muda sem aviso prévio.

    Sistemas baseados em templates exigem manutenção constante nessa escala. Funcionários chegam a gastar até 30% do tempo em tarefas relacionadas a documentos, e as taxas de erro na entrada manual de dados variam entre 1% e 4%. As soluções convencionais de Processamento Inteligente de Documentos (IDP) resolvem parte do problema, mas exigem configuração extensiva para cada formato e quebram quando os layouts variam entre fornecedores.

    Para endereçar esse cenário, a AWS publicou um guia técnico detalhando como construir um sistema de IDP agnóstico usando o Amazon Bedrock AgentCore — uma plataforma para criar, conectar e otimizar agentes de IA em escala, com qualquer framework ou modelo.

    Os três problemas centrais das abordagens baseadas em regras

    Antes de entrar na solução, vale entender por que os pipelines tradicionais de IDP falham em ambientes com alta variedade de documentos:

    • Rigidez de templates: cada novo formato de documento exige configuração manual, e até pequenas mudanças de layout podem causar falhas na extração.
    • Ausência de aprendizado: os mesmos erros de extração se repetem em documentos similares porque o sistema não retém o conhecimento de correções anteriores.
    • Escalabilidade comprometida: cada novo fornecedor ou variante de documento multiplica o esforço de manutenção, gerando custos operacionais contínuos para organizações que processam documentos de centenas de origens.

    A abordagem agêntica resolve esses três pontos. Em vez de templates estáticos, agentes de IA analisam cada documento, geram instruções de extração, validam os resultados e aprendem com as correções automaticamente. Com o tempo, o sistema constrói uma base de conhecimento sobre os formatos de documentos, processando documentos similares com mínima configuração adicional.

    Visão geral da solução

    A solução proposta pela AWS envolve oito agentes especializados que colaboram em dois fluxos de trabalho baseados em grafos, rodando sobre o Amazon Bedrock AgentCore. Os agentes são construídos com o Strands Agents, um SDK de código aberto para criação de agentes de IA.

    Fluxo de identificação

    O agente Analisador extrai o texto do documento usando o Amazon Textract e identifica o tipo e o remetente. Em seguida, o agente Combinador busca documentos similares por similaridade vetorial no Amazon S3 Vectors, uma funcionalidade do Amazon Simple Storage Service (Amazon S3).

    Fluxo de treinamento (novos tipos de documento)

    Quando nenhuma correspondência é encontrada, o agente de Instruções gera prompts de extração, o agente Extrator produz os dados estruturados, e o agente Validador verifica os resultados contra esquemas e regras de negócio armazenados no Amazon Aurora DSQL. Se a validação falhar, o agente Corretor de Instruções refina os prompts e tenta novamente. Com sucesso, o agente Salvar Instruções persiste as instruções para reutilização futura.

    Fluxo de automação (tipos de documento já conhecidos)

    Quando uma correspondência é encontrada, o agente Extrator aplica diretamente as instruções existentes. Se a validação falhar, o agente Solucionador de Problemas corrige os dados extraídos sem modificar as instruções.

    Arquitetura de infraestrutura

    Os documentos chegam via Amazon Simple Email Service (Amazon SES) ou por upload direto ao Amazon S3. O Amazon EventBridge dispara uma função AWS Lambda que cria um job de rastreamento no Amazon DynamoDB e invoca o AgentCore Runtime.

    Os agentes acessam recursos da AWS com segurança por meio de credenciais máquina-a-máquina gerenciadas pelo AgentCore Identity e pelo Amazon Cognito. As funções Lambda se tornam ferramentas compatíveis com agentes através da interface do Protocolo de Contexto de Modelo (MCP) do AgentCore Gateway.

    O monitoramento e a resolução de problemas são feitos por um dashboard com chat integrado, hospedado no Amazon Elastic Container Service (Amazon ECS). A visibilidade sobre o desempenho dos agentes é fornecida pelo AgentCore Observability e pelo Amazon CloudWatch.

    Como implantar a solução

    Pré-requisitos

    Passos de implantação

    Clone o repositório e configure o ambiente:

    git clone https://github.com/aws-samples/agenticidp-guidance.git
    cd agenticidp-guidance
    
    uv venv
    source .venv/bin/activate
    uv pip install -r requirements.txt
    cd ui/orchestrator
    npm install
    cd ../..

    Em seguida, implante as stacks:

    uv run deploy.py --admin-email your-email@example.com

    Esse comando implanta seis stacks do AWS CloudFormation: Core (S3, Cognito, DynamoDB), Gateway (ferramentas Lambda, AgentCore Gateway), Aurora (Amazon Aurora DSQL), Agent (AgentCore runtime, contêineres), UI Orchestrator (endpoints de API) e Modern UI (aplicação React no Amazon CloudFront). A implantação leva aproximadamente 15 a 20 minutos.

    Exemplos práticos de funcionamento

    Novo tipo de documento — fluxo de treinamento

    Imagine que uma ordem de compra de um novo varejista, “Two Wheel Store”, é enviada pela primeira vez. O agente Combinador busca no armazenamento vetorial, não encontra correspondência e direciona o job pelo fluxo de treinamento. O agente Analisador usa o Amazon Textract para extrair o texto bruto:

    # PURCHASE ORDER
    FROM: Two Wheel Store
    Order #: PO-2026-0102-2584
    Date: 2026-01-02
    
    ## Items Ordered
    AC-021 Advanced Computer Qty: 1 $75.61
    Colors: cr4321 @ $75.61
    ...
    SB-004 Folding Classic Qty: 8 $9634.32
    Colors: cb8901 I Sizes: S @ $1204.29
    TOTAL: $14931.54

    O agente de Instruções gera os prompts de extração a partir do esquema, e o agente Extrator produz um JSON estruturado:

    {
      "po_number": "PO-2026-0102-2584",
      "retailer_name": "Two Wheel Store",
      "order_date": "2026-01-02T00:00:00Z",
      "line_items": [
        {
          "sku": "AC-021",
          "product_name": "Advanced Computer",
          "quantity": 1,
          "unit_price": 75.61,
          "line_total": 75.61
        },
        {
          "sku": "SB-004",
          "product_name": "Folding Classic",
          "quantity": 8,
          "unit_price": 1204.29,
          "line_total": 9634.32
        }
      ],
      "order_total": 14931.54
    }

    O agente Validador verifica o resultado e detecta uma falha:

    validation_status: INVALID
    error: 'SB-004' does not match '^AB-[A-Z]{2}-\d{3}$'

    O formato de SKU do fornecedor (SB-004) não corresponde ao formato interno da empresa (AB-SB-004). O agente Corretor de Instruções diagnostica a incompatibilidade e adiciona uma regra explícita de transformação de SKU ao prompt de extração: prefixar os SKUs do fornecedor com AB-. Na segunda tentativa, os sete itens de linha são validados com sucesso, e o agente Salvar Instruções persiste o prompt refinado no armazenamento vetorial. O tempo total desse primeiro processamento foi de 3 minutos e 49 segundos.

    Tipo de documento já conhecido — fluxo de automação

    Quando uma segunda ordem de compra da Two Wheel Store chega, o agente Combinador encontra as instruções armazenadas da primeira execução com uma pontuação de confiança de 3,946 (limite: 3,7) e direciona o job pelo fluxo de automação. O agente Extrator aplica as instruções diretamente, a regra de transformação de SKU aprendida no treinamento é aplicada automaticamente (EL-002 → AB-EL-002, HB-071 → AB-HB-071, PD-002 → AB-PD-002), e os três itens de linha são validados na primeira tentativa com um total de US$ 5.979,19. O processamento completo levou 1 minuto e 30 segundos — uma redução significativa em relação aos 3 minutos e 49 segundos do primeiro processamento.

    Interface de chat para diagnóstico

    O dashboard inclui uma interface de chat para resolução de problemas. É possível perguntar quais ferramentas o agente possui, listar instruções armazenadas, verificar o status de um job específico ou diagnosticar falhas e sugerir atualizações nas instruções.

    Como a precisão melhora ao longo do tempo

    O sistema evolui por meio de dois ciclos de retroalimentação:

    • Ciclo de treinamento: quando o agente Corretor de Instruções refina os prompts após falhas de validação, as instruções melhoradas são salvas e reutilizadas para documentos similares.
    • Ciclo de processamento: quando o agente Solucionador de Problemas corrige erros de extração, ele fornece análises detalhadas que ajudam a identificar padrões nas variações de formato dos documentos.

    Ao trocar de modelo, a AWS recomenda usar o AgentCore Evaluations para confirmar que a qualidade de extração permanece aceitável.

    Estimativa de custo

    Como a solução roda em recursos serverless e sob demanda, não há custos ociosos. Para uma carga de trabalho de 10 documentos de treinamento e 1.000 documentos processados por mês na região US East (N. Virginia), o custo estimado é de aproximadamente US$ 58 por mês. A inferência de modelos de fundação (FM) pelo Amazon Bedrock representa cerca de 85% do custo total, a aproximadamente US$ 0,055 por documento. Consulte a página de preços do Amazon Bedrock para detalhes.

    Personalizando a solução para o seu caso de uso

    A solução já vem com um caso de uso de processamento de ordens de compra, um conjunto de dados sintético de uma empresa de bicicletas, um esquema JSON pré-construído e uma função Lambda de validação. Para processar seus próprios documentos, é necessário substituir os esquemas e a lógica de validação incluídos pelos seus próprios.

    Defina o esquema do seu documento

    Crie um esquema JSON que defina os campos que você deseja extrair para cada tipo de documento. O esquema de referência está em agents/orchestratorgraph/doc_schema/purchase_order_schema.json. O esquema deve especificar nomes de campos, tipos de dados e se cada campo está explicitamente declarado no documento ou inferido pelo contexto.

    Construa seu processo de validação

    Para adicionar um novo validador, crie uma função Lambda que aceite o JSON extraído e retorne um resultado de aprovação ou reprovação com mensagens de erro detalhadas, depois registre-a como ferramenta no AgentCore Gateway. Exemplos de validadores possíveis:

    • Um validador de faturas que verifica IDs de fornecedores no sistema de contas a pagar e confere se os totais dos itens batem com o total da fatura.
    • Um validador de contratos que verifica se o documento contém cláusulas obrigatórias e se datas e nomes das partes correspondem aos registros.
    • Um validador de sinistros que confere números de apólices, limites de cobertura e informações do solicitante no sistema de gestão de apólices.

    Atualize os prompts dos agentes

    Os prompts dos agentes em agents/orchestratorgraph/prompts/ fazem referência à terminologia de ordens de compra. Atualize-os para refletir seus tipos de documentos e requisitos de extração.

    Boas práticas de operação

    • Comece com amostras representativas: envie de 5 a 10 documentos por tipo durante o treinamento, incluindo casos extremos com variações de formato.
    • Use validação com regras de negócio: conecte os validadores aos seus dados de referência (listas de fornecedores, catálogos de produtos) no Aurora DSQL para capturar erros de extração cedo.
    • Monitore o desempenho dos agentes: use o AgentCore Observability e o CloudWatch para rastrear caminhos de execução, identificar gargalos e medir a precisão da extração ao longo do tempo.
    • Adicione tipos de documentos incrementalmente: crie um esquema JSON para cada novo tipo de documento e uma função Lambda de validação correspondente.
    • Adicione guardrails para produção: aplique o Amazon Bedrock Guardrails para impor filtragem de conteúdo e verificações de fundamentação nas saídas dos agentes — especialmente importante para documentos sensíveis como sinistros de seguros ou pedidos de empréstimo.
    • Revise o OWASP Top 10 para LLMs: consulte o OWASP Top 10 para LLMs e Apps de IA Generativa para considerações de segurança ao construir aplicações que usam grandes modelos de linguagem (LLMs).

    Limpeza dos recursos

    Para evitar cobranças contínuas, remova os recursos implantados com o comando:

    uv run destroy.py

    Importante: antes de executar a limpeza, exporte os dados que deseja manter. O script destroy.py exclui permanentemente documentos processados (S3), histórico de jobs (DynamoDB), dados de validação (Aurora DSQL) e instruções de extração aprendidas (armazenamento vetorial).

    Conclusão

    A abordagem agêntica apresentada pela AWS representa uma evolução significativa no processamento de documentos corporativos. Em vez de templates rígidos que quebram com qualquer variação de layout, o sistema se adapta automaticamente a novos formatos e melhora sua precisão ao longo do tempo por meio de ciclos de retroalimentação — substituindo a configuração manual por aprendizado autônomo.

    Para quem quiser explorar mais, a AWS disponibiliza a solução de exemplo para testes com as amostras de ordens de compra incluídas. Recursos adicionais de referência:

    Fonte

    Build self-improving document processing using Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-self-improving-document-processing-using-amazon-bedrock-agentcore/)

  • Gere apresentações automaticamente com o Amazon Bedrock AgentCore

    O problema: criar apresentações consome tempo demais

    Equipes de serviços financeiros costumam gastar horas toda semana produzindo apresentações PowerPoint para clientes — lendo relatórios trimestrais, documentos de conformidade e análises de mercado, extraindo dados relevantes, estruturando slides e gerando visuais de apoio. É um trabalho repetitivo, demorado e suscetível a erros humanos.

    A AWS publicou um guia técnico detalhado mostrando como automatizar esse fluxo de trabalho com um sistema de agentes de IA usando o Amazon Bedrock AgentCore. Em testes internos, a solução completa o processo em menos de 90 segundos — desde a consulta ao documento até a entrega da apresentação pronta.

    Visão geral da solução

    A arquitetura centraliza tudo em um único agente supervisor implantado no runtime do Amazon Bedrock AgentCore. Esse agente decide, com base na solicitação do usuário, qual ferramenta acionar: geração de documento ou sumarização de conteúdo.

    O pipeline de Geração Aumentada por Recuperação (RAG) usa o Amazon OpenSearch Serverless para armazenamento vetorial e busca semântica em conteúdo multimodal. A solução também inclui uma API REST construída com .NET 8 minimal APIs, permitindo integração com sistemas corporativos existentes via chamadas HTTP padrão.

    Os principais serviços e modelos utilizados são:

    • Anthropic Claude Sonnet 4.6 (disponível no Amazon Bedrock): geração de conteúdo textual
    • Amazon Titan Text Embeddings v2: busca vetorial semântica
    • Stability AI Stable Image Inpaint (disponível no Amazon Bedrock): geração de imagens para os slides
    • Strands Agents: framework open source de orquestração do agente supervisor

    A segurança é garantida com isolamento via Amazon Virtual Private Cloud (Amazon VPC), criptografia com AWS Key Management Service (AWS KMS) e controle de acesso com privilégio mínimo via AWS Identity and Access Management (IAM).

    Conceitos-chave da arquitetura

    Orquestração com Amazon Bedrock AgentCore

    Um único agente de IA que precisa gerar documentos a partir de grandes bases de conhecimento tem responsabilidades concorrentes: recuperar conteúdo, estruturar roteiros, gerar texto, criar imagens e montar arquivos. Em vez de concentrar tudo em uma função monolítica, a solução adota uma arquitetura baseada em ferramentas, onde o agente supervisor roteia cada tarefa para a ferramenta especializada correta.

    O Amazon Bedrock AgentCore runtime fornece a plataforma para construir, conectar e otimizar agentes em escala, com suporte a qualquer framework ou modelo. O código do agente roda em um contêiner isolado com gerenciamento de sessão, identidade integrada e observabilidade nativa.

    O agente supervisor expõe duas ferramentas:

    • generate_pptx: cria apresentações PowerPoint acionando uma função Lambda containerizada (PPTX Generator), que recupera conteúdo da base de conhecimento, gera o roteiro dos slides, cria imagens com IA e monta o documento final.
    • generate_summary: extrai e sintetiza informações da base de conhecimento via RAG para entregar respostas precisas e fundamentadas nos documentos-fonte.

    Novas capacidades podem ser adicionadas simplesmente definindo novas ferramentas no código do agente, sem modificar as existentes.

    RAG para conhecimento corporativo

    O RAG resolve um desafio fundamental em sistemas de IA: entregar informações precisas e atualizadas com base nos dados da empresa, em vez de depender apenas do conhecimento de treinamento do modelo. A implementação usa o Amazon Bedrock Knowledge Bases, que combina busca vetorial com grandes modelos de linguagem (LLMs) para recuperar contexto relevante antes de gerar respostas.

    O pipeline de RAG funciona da seguinte forma:

    1. Os documentos corporativos são enviados para o Amazon Simple Storage Service (Amazon S3).
    2. O sistema fragmenta e analisa os documentos, com tratamento especial para conteúdo multimodal (tabelas, gráficos e imagens).
    3. O Amazon Titan Text Embeddings v2 converte cada fragmento em vetores de alta dimensão que capturam o significado semântico.
    4. O Amazon OpenSearch Serverless armazena os vetores, criando um banco de dados vetorial pesquisável.
    5. No momento da consulta, a solicitação do usuário é convertida em um embedding e uma busca por similaridade recupera os fragmentos mais relevantes.
    6. Os fragmentos recuperados fornecem contexto ao modelo de linguagem, que gera respostas fundamentadas no material-fonte.

    Nota importante: a coleção do Amazon OpenSearch Serverless precisa permanecer acessível publicamente no plano de dados, pois o Amazon Bedrock Knowledge Bases a acessa a partir de infraestrutura gerenciada pela AWS — e não por endpoints de VPC do cliente. As políticas de acesso a dados do IAM protegem a coleção, e o acesso ao painel do OpenSearch Serverless fica restrito à VPC.

    Amazon Bedrock Guardrails para segurança de conteúdo

    Aplicações de IA corporativas precisam de moderação de conteúdo para atender a padrões organizacionais e requisitos de conformidade. O Amazon Bedrock Guardrails oferece filtragem de conteúdo e mecanismos de segurança integrados ao longo de todo o pipeline de geração de documentos.

    Os guardrails atuam em múltiplos estágios: no processamento da entrada (filtrando solicitações para evitar injeções e conteúdo inadequado), na geração de saída (monitorando respostas do modelo) e no tratamento de Informações de Identificação Pessoal (PII), detectando e anonimizando ou bloqueando dados sensíveis.

    A implementação cria guardrails personalizados via AWS Cloud Development Kit (AWS CDK), configurados com políticas específicas para criação de documentos corporativos. O agente aplica os guardrails no nível de invocação do modelo, garantindo segurança de conteúdo consistente sem exigir configuração manual a cada implantação.

    Arquitetura e fluxo de dados

    O fluxo de dados começa com solicitações dos usuários chegando pelo Amazon API Gateway, que as encaminha para uma Chat API baseada em .NET rodando no AWS Lambda. A API mantém o estado da conversa no Amazon DynamoDB e aciona o agente supervisor hospedado no Amazon Bedrock AgentCore runtime.

    O agente analisa a solicitação e seleciona a ferramenta adequada. Para geração de documentos, aciona o PPTX Generator Lambda (uma função Python containerizada). Para sumarização, aciona o Summary Generator Lambda, que consulta a base de conhecimento via API retrieve_and_generate.

    Os documentos armazenados no Amazon S3 são processados, fragmentados e transformados em embeddings com o Amazon Titan Text Embeddings v2. O Amazon OpenSearch Serverless indexa os embeddings para busca semântica rápida. Quando as ferramentas consultam a base de conhecimento, os fragmentos relevantes são recuperados e fornecidos como contexto ao Anthropic Claude Sonnet 4.6 para gerar respostas fundamentadas nos documentos-fonte.

    Os documentos gerados são armazenados no Amazon S3 e retornados ao usuário como URLs pré-assinadas para download seguro.

    As medidas de segurança da solução incluem:

    • AWS WAF com conjuntos de regras gerenciadas e limitação de taxa por IP no Amazon API Gateway
    • Amazon Cognito com plano Plus e modo de segurança avançada para proteção contra ameaças
    • Amazon Bedrock Guardrails provisionados via AWS CDK para filtragem consistente de conteúdo
    • Amazon DynamoDB com recuperação point-in-time, proteção contra exclusão e criptografia gerenciada pelo cliente via AWS KMS
    • Buckets do Amazon S3 com versionamento, registro de acesso e bloqueio de acesso público
    • AWS X-Ray para rastreamento distribuído nas funções Lambda
    • Validação de entrada com verificação de IDs de tenant e sessão por regex
    • Isolamento de tenant via assunção de função do AWS Security Token Service (AWS STS) por tenant

    Pré-requisitos para implantação

    Antes de implantar a solução, é necessário ter configurado no ambiente:

    • Uma conta AWS ativa com permissões para implantação de infraestrutura, AWS CLI configurado com credenciais e uma função IAM com políticas de acesso adequadas
    • .NET SDK 8 com Amazon.Lambda.Tools instalado globalmente
    • Python 3.12 ou superior para AWS CDK e funções Lambda
    • Node.js e AWS CDK CLI para implantação de infraestrutura
    • Docker ou Finch para construção de imagens de contêiner (suporte ARM64 obrigatório)
    • Acesso habilitado ao Amazon Bedrock para os modelos Anthropic Claude Sonnet 4.6, Amazon Titan Text Embeddings v2 e Stability AI Stable Image Inpaint. Confira a disponibilidade dos modelos por região no Amazon Bedrock
    • Amazon Bedrock AgentCore habilitado na conta
    • Timeout de integração do Amazon API Gateway Regional REST API configurado para pelo menos 300 segundos (o padrão é 29 segundos — veja as cotas do API Gateway)
    • Uma Amazon VPC existente com sub-redes privadas e um bucket S3 para artefatos de implantação

    Configuração e implantação

    O processo de configuração envolve clonar o repositório, criar o arquivo de parâmetros e inicializar o ambiente AWS CDK.

    Clone o repositório e navegue até o diretório do projeto:

    git clone https://github.com/aws-samples/sample-generating-powerpoint-presentations-with-amazon-bedrock.git

    Crie o arquivo de configuração pipeline-params.ini na raiz do repositório:

    environment=dev
    awscliprofile=
    ContainerRegistry=lambda-pptx-gen
    AgentContainerRegistry=agentcore-supervisor
    BucketDev=<amzn-s3-demo-bucket>
    VpcId=<your-vpc-id>
    ParsingInferenceProfileId=us.anthropic.claude-haiku-4-5-20251001-v1:0
    AgentInferenceProfileId=us.anthropic.claude-sonnet-4-6
    EmbeddingModelId=amazon.titan-embed-text-v2:0
    ImageGenerationModelId=stability.stable-image-inpaint-v1:0
    PPTXGenImageTag=latest
    AgentImageTag=latest

    Inicialize o AWS CDK (uma vez por conta e região):

    cdk bootstrap

    Torne os scripts executáveis:

    chmod +x ./pipeline-build.sh
    chmod +x ./pipeline-deploy.sh
    chmod +x ./deploy-agentcore.sh

    Fases de build e implantação

    A implantação ocorre em três fases: build dos artefatos, implantação da infraestrutura e implantação do agente no AgentCore runtime.

    Fase de build: execute o script de build para compilar os projetos .NET, empacotar as funções Lambda, construir a imagem de contêiner do PPTX Generator e enviá-la ao Amazon Elastic Container Registry (Amazon ECR):

    ./pipeline-build.sh

    Fase de infraestrutura: execute o script de implantação, que criará quatro stacks do AWS CloudFormation em ordem de dependência:

    ./pipeline-deploy.sh
    • VPCEndpointsStack: configura endpoints de VPC para serviços AWS, incluindo o Amazon Bedrock AgentCore
    • OpensearchStack: provisiona a coleção do Amazon OpenSearch Serverless para armazenamento vetorial
    • AgentCoreStack: cria guardrails, funções Lambda, funções IAM e armazena configurações no AWS Systems Manager Parameter Store
    • ChatApiStack: implanta o Amazon API Gateway e a Chat API Lambda

    Implantação do agente no AgentCore runtime: após as stacks de infraestrutura estarem implantadas, execute:

    ./deploy-agentcore.sh

    Esse script constrói o contêiner do agente supervisor (ARM64), envia para o Amazon ECR, cria o runtime e o endpoint do AgentCore, e atualiza o parâmetro no Systems Manager com o ARN do endpoint. A Chat API usa esse ARN para rotear as solicitações ao agente.

    Configurações personalizáveis

    A solução oferece alguns pontos de configuração relevantes:

    • Instruções do agente: edite agent/app.py para modificar o prompt de sistema e o comportamento do agente supervisor
    • Seleção de modelos: ajuste os identificadores de modelo no pipeline-params.ini — o Anthropic Claude Haiku 4.5 é recomendado para parsing (melhor custo-benefício) e o Claude Sonnet 4.6 para raciocínio do agente
    • Configuração das funções Lambda: Chat API (128 MB, timeout de 29s, concorrência reservada de 100), PPTX Generator (900 MB, timeout de 300s, concorrência de 50) e Summary Generator (512 MB, timeout de 300s, concorrência de 50)

    O uso de perfis de inferência em vez de IDs de modelo diretos permite que as solicitações utilizem um pool de capacidade multi-região mais amplo, aumentando o throughput e mantendo desempenho consistente sob carga.

    Resultados dos testes internos

    Em testes internos com o Relatório Anual da Amazon 2024 em PDF de 90 páginas, a solução apresentou os seguintes resultados:

    • Tempo de geração da apresentação: 70 a 90 segundos de ponta a ponta (incluindo recuperação da base de conhecimento, geração de conteúdo, criação de imagens e montagem do arquivo)
    • Número de slides: seis slides com formatos de título, pontos de destaque, imagem+texto, somente imagem e conclusões
    • Geração de imagens: duas imagens geradas por IA por apresentação usando o Stability AI Stable Image Inpaint
    • Custo por geração: aproximadamente US$ 0,04 em custos de invocação de modelos no momento da publicação em us-east-1 (geração de texto e imagem, sendo a geração de imagem responsável pela maior parte do custo)
    • Ingestão na base de conhecimento: menos de 2 minutos para um único PDF de 1,3 MB

    As apresentações geradas incluem slides de título com identidade visual personalizável, slides de conteúdo com pontos estruturados, slides com imagens geradas por IA, notas do apresentador e formatação consistente baseada em templates corporativos.

    Sobre as respostas da API: como a geração de apresentações leva de 70 a 90 segundos (excedendo o timeout padrão de 29 segundos do Amazon API Gateway), a Chat API usa um padrão de invocação assíncrona. Use streaming ou polling para receber o resultado final, em vez de aguardar em uma chamada REST síncrona.

    Limpeza dos recursos

    Para evitar cobranças contínuas, exclua os recursos implantados seguindo esta ordem:

    Exclua o runtime e o endpoint do AgentCore:

    aws bedrock-agentcore-control delete-agent-runtime-endpoint \
      --agent-runtime-id <runtime-id> \
      --agent-runtime-endpoint-id <endpoint-id>
    
    aws bedrock-agentcore-control delete-agent-runtime \
      --agent-runtime-id <runtime-id>

    Desative a proteção contra exclusão do Amazon DynamoDB (obrigatório antes de excluir as stacks):

    aws dynamodb update-table --table-name chat-sessions-dev --no-deletion-protection-enabled
    aws dynamodb update-table --table-name tenant-table-dev --no-deletion-protection-enabled

    Exclua as stacks do AWS CloudFormation em ordem reversa de dependência:

    aws cloudformation delete-stack --stack-name ChatApiStack
    aws cloudformation delete-stack --stack-name AgentCoreStack
    aws cloudformation delete-stack --stack-name OpensearchStack
    aws cloudformation delete-stack --stack-name VPCEndpointsStack

    Esvazie os buckets do Amazon S3 antes da exclusão (o AWS CloudFormation não consegue excluir buckets não vazios):

    aws s3 rm s3://amzn-s3-demo-bucket --recursive

    Exclua os repositórios do Amazon ECR com as imagens de contêiner:

    aws ecr delete-repository --repository-name lambda-pptx-gen --force
    aws ecr delete-repository --repository-name agentcore-supervisor --force

    Exclua também as sub-stacks da base de conhecimento criadas pelo provisionador de tenants:

    aws cloudformation delete-stack --stack-name bedrock-kb-<tenant-id>

    Considerações de segurança

    A solução usa variáveis de ambiente do Lambda para valores de configuração como IDs de modelo, nomes de buckets S3 e IDs de guardrail — que são identificadores de recursos, não segredos. Para implantações em produção, recomenda-se usar o AWS Secrets Manager para valores de configuração sensíveis, como chaves de API e credenciais de banco de dados.

    O agente no AgentCore runtime roda em um contêiner isolado com isolamento por sessão. Cada sessão de usuário opera em um ambiente dedicado, ajudando a evitar contaminação de dados entre sessões.

    Conclusão

    A solução demonstra como o Amazon Bedrock AgentCore pode automatizar a geração de documentos corporativos de forma eficiente e segura. O agente supervisor implantado no AgentCore runtime roteia solicitações para ferramentas especializadas de criação de documentos e sumarização, reduzindo a criação de apresentações para cerca de 90 segundos em testes internos. O pipeline de RAG fundamenta o conteúdo gerado nos documentos-fonte, e o Amazon Bedrock Guardrails garante a conformidade do conteúdo.

    Essa arquitetura pode ser adaptada para geração automatizada de relatórios em serviços financeiros, documentação técnica para equipes de engenharia ou criação de propostas para equipes de vendas. Para começar, clone o repositório no GitHub e siga as instruções de configuração. Para mais informações sobre os serviços utilizados, consulte a documentação do Amazon Bedrock AgentCore, o SDK do Strands Agents e o Guia do Desenvolvedor do AWS CDK.

    Fonte

    Generate presentations with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/generate-presentations-with-amazon-bedrock-agentcore/)

  • Parte 2 – Jornadas em Cibersegurança: Afinal, o Que é Essa Profissão?

    Além dos Papéis que Todo Mundo Conhece

    Se você já procurou vagas em cibersegurança e sentiu que nenhuma delas combinava com o seu perfil, talvez o problema seja a lista — e não você. A maioria dos guias de carreira da área cobre sempre os mesmos papéis: o analista monitorando alertas ou o pen tester (testador de penetração, profissional contratado para tentar invadir sistemas de forma legal e identificar vulnerabilidades). Essas funções existem e são importantes, mas representam uma fatia pequena de um campo muito mais amplo.

    O blog de segurança da AWS publicou a segunda parte de uma série sobre trajetórias reais na área. Na primeira parte, três pessoas contaram como chegaram à segurança partindo de lugares inusitados — um armazém logístico, uma mesa de marketing e o quarto de um adolescente. Agora, a série mostra onde essas jornadas podem chegar: medir o risco de um milhão de aplicações ao mesmo tempo, construir ferramentas de detecção a partir do setor de atendimento ao cliente, e pensar seriamente em como proteger infraestrutura lançada ao espaço.

    A Árvore de Habilidades: A Abordagem de Jason Lane

    Imagem original — fonte: Aws

    Jason Lane, Engenheiro de Segurança, planeja a carreira como quem monta um personagem em um RPG de turno. Ele usa literalmente o conceito de árvore de habilidades de videogame: você começa visualizando seu personagem no nível 20 — a versão de você mesmo com as competências e o papel que realmente quer — e então trabalha de trás para frente. O que precisa ser verdade no nível 19 para chegar ao 20? E no 18, para ter essas opções disponíveis? Você vai recuando até chegar ao nível 1, com um caminho construído de cima para baixo.

    Para Jason, o nível 20 era pesquisa de vulnerabilidades — encontrar falhas de segurança desconhecidas em softwares antes que atacantes o façam. Na época, ele era administrador de sistemas, o que lhe dava boa noção de como os sistemas se conectam, mas pouca exposição à análise das aplicações que rodam sobre eles. Essa lacuna — segurança de aplicações — era o próximo nó na sua árvore. Ele ligou para um recrutador de TI, explicou o plano e foi honesto sobre onde estava. O recrutador encontrou uma empresa de processamento de cartões que precisava de um engenheiro de segurança de aplicações e estava disposta a contratar alguém que ainda estava se tornando um.

    Para Jason, foi um aprendizado remunerado na habilidade exata que ele buscava. Para a empresa, um engenheiro motivado que cresceria no papel. Ele descreve como um acordo em que os dois lados saíram ganhando — e esse enquadramento importa: ele não estava aceitando menos, estava trocando uma curva de aprendizado mais íngreme por um caminho mais rápido até onde queria chegar.

    Após quatro anos desmontando aplicações para entender o que as tornava vulneráveis, ele aplicou o mesmo método novamente. Um amigo ofereceu indicá-lo para uma entrevista no Google. A reação honesta de Jason — de que não era inteligente o suficiente para trabalhar lá — é o tipo de dúvida que a maioria das pessoas reconhece (também conhecida como síndrome do impostor). O amigo não acreditou. Os entrevistadores também não, e ele foi contratado. A lição que ele tirou disso é valiosa: a voz que diz que você não pertence àquele ambiente frequentemente está errada, e a forma de silenciá-la é trabalhar até que as habilidades falem por si.

    Ele passou quase sete anos fazendo pesquisa de vulnerabilidades no Android — o tipo de trabalho técnico profundo que a maioria das empresas não tem orçamento para sustentar. Esse histórico abriu a porta para a Amazon. Hoje, Jason mede o risco de aproximadamente um milhão de aplicações na Amazon, avaliando quais causariam mais dano se comprometidas e quais têm maior probabilidade de ser alvo — para que a organização possa priorizar as mais críticas.

    Quando perguntado o que diria para alguém com uma grande visão e sem ideia de por onde começar, ele disse: fique obcecado com clareza sobre para onde está indo, porque as lacunas vão aparecer sozinhas. Ele comparou isso a planejar uma viagem de 160 quilômetros e perceber que você não está usando sapatos: uma vez que você vê, não consegue mais deixar de ver.

    “Se você pode esperar até o sábado, talvez deva só esperar o sábado. Não tem nada de errado com isso.” — Jason Lane

    Volta às Origens: A Trajetória de Jason Goodman

    Imagem original — fonte: Aws

    Se Jason Lane planejou a carreira a partir da linha de chegada, a trajetória de Jason Goodman se parece mais com uma máquina de pinball — saltando por três disciplinas de segurança em cerca de um ano e acumulando habilidades pelo caminho.

    A base foi construída muito antes de ele saber disso. Oito anos atrás, antes de a Amazon adquirir a Ring, ele trabalhava no atendimento ao cliente, ajudando usuários com seus dispositivos e contas. O que o direcionou para segurança foi, em parte, o incentivo do sogro — que trabalhava em TI — e, em parte, o que ele observava diariamente nas ligações: acessos a contas que não pareciam certos, sinais silenciosos de que algo estava errado. Esses padrões o fizeram querer entender os sistemas por trás deles. Então, ainda no atendimento ao cliente, ele voltou a estudar para se graduar em cibersegurança.

    Mas ele não esperou a formatura para começar a construir o caminho. Entrou em contato com o gerente do time interno de ameaças (os profissionais que investigam uso indevido de acessos dentro da organização) e fez uma pergunta que qualquer pessoa pode fazer: o que eu poderia fazer para continuar evoluindo enquanto ainda estou na faculdade? Isso se transformou em projetos extras. E aqui está o detalhe que vale notar: ele ganhou os projetos maiores entregando os menores primeiro.

    Seu projeto de destaque foi um painel de prevenção a fraudes que ajudava o time a identificar possíveis usos indevidos do acesso a contas de clientes — um ponto cego que ninguém tinha sinalizado antes. Ele tinha credibilidade para receber esse desafio porque já havia demonstrado comprometimento com o trabalho de menor visibilidade. Isso abriu a porta para seu primeiro cargo como engenheiro de segurança.

    De lá, ele migrou para um time de detecção de ameaças adversariais (os profissionais que monitoram atacantes externos tentando invadir sistemas), o que exigiu uma virada de mentalidade: em vez de perguntar o que alguém de dentro poderia fazer com seu acesso existente, ele passou a perguntar como alguém de fora tentaria entrar. Uma movimentação posterior o levou à segurança de aplicações, onde o foco mudou de responder a incidentes para incorporar segurança nos processos desde o início.

    “Estou na minha terceira disciplina em um ano desde que migrei do atendimento ao cliente para engenharia de segurança.” — Jason Goodman

    O que chama atenção é o quanto se transferiu de um papel para o outro. As consultas no Splunk (ferramenta para busca e análise de grandes volumes de dados de log) aprendidas no atendimento ao cliente serviram no trabalho com ameaças internas; a lógica de detecção das investigações internas serviu na detecção adversarial; e agora, em segurança de aplicações, ele voltou ao ponto de partida — trabalhando ao lado dos mesmos times de atendimento ao cliente de onde veio, mas desta vez ajudando a construir a segurança ao redor deles.

    Ao longo de tudo isso, ele contou com quatro mentores diferentes, cada um servindo a um propósito específico: um para navegar a graduação, um para projetos de expansão, um para aprender a pensar como um adversário, e um para se aprofundar em segurança de aplicações. A forma como ele os encontrou é replicável: ele não esperou ser designado a ninguém. Entrou em contato com pessoas cujo trabalho admirava, fez perguntas específicas e manteve o contato ao longo dos anos.

    Na Fronteira do Mapa: Harshvardhan Chunawala

    Imagem original — fonte: Aws

    Harshvardhan Chunawala ainda estava no ensino médio quando começou a encontrar falhas de segurança em produtos reais e a reportá-las às empresas responsáveis. Ele havia começado desenvolvendo sites e aplicações web e, depois de entender como o software era construído, não conseguia parar de pensar em como poderia ser desmontado. Em vez de esperar ter um diploma ou um emprego para explorar isso, ele começou a analisar produtos reais por conta própria — e quando encontrava uma falha, entrava em contato com a empresa e trabalhava com ela para corrigi-la.

    Hoje, como Arquiteto de Soluções para Startups na AWS, ele orienta fundadores sobre segurança e dedica parte do seu tempo a ensinar cursos de nuvem e segurança para estudantes. Uma das perguntas mais frequentes que recebe é: por onde começar, num momento em que parte do trabalho de nível básico está sendo automatizado?

    A resposta dele evoluiu ao longo do tempo. Agora que ferramentas de Inteligência Artificial Generativa (IA Generativa) conseguem responder às perguntas mais superficiais, ele acredita que a curiosidade importa mais do que as credenciais — porque quem se destaca são as pessoas que continuam fazendo perguntas depois que a ferramenta fica sem respostas.

    “As ferramentas de IA colocam todo mundo na mesma linha de partida. O interesse e a paixão se tornaram o diferencial.” — Harshvardhan Chunawala

    O que surpreende na trajetória dele é para onde sua curiosidade o levou. Enquanto estudava na Universidade Carnegie Mellon (CMU), ele acabou trabalhando em missões espaciais, incluindo como operador de missão do rover lunar Iris. Se a pergunta é se segurança pertence ao espaço, a resposta de Harshvardhan é imediata: qualquer coisa que pode ser comandada remotamente pode ser comandada pela pessoa errada.

    Quando o assunto é o futuro da segurança, ele vai além: fala sobre robôs entrando nas casas das pessoas, sobre data centers migrando de terra para o fundo do mar e depois para o espaço. Um satélite precisa ser protegido em órbita — onde ninguém pode alcançar fisicamente um sistema comprometido — e também no solo, onde as estações que o controlam também são alvos. Harshvardhan já escreveu um guia de duas partes sobre resposta a incidentes para operações de satélites na AWS, então para ele esse canto do mapa já faz parte do trabalho.

    O Fio que Une as Três Histórias

    As três trajetórias compartilham um ponto em comum: a função que você vai amar pode ser uma que você ainda não conhece. Jason Lane mapeou seus movimentos a partir do destino final. Jason Goodman carregou suas habilidades por três disciplinas em um único ano. Harshvardhan já está ajudando clientes da AWS a proteger satélites e os sistemas terrestres que os operam. Nenhum deles consegue explicar o que faz em uma única frase — e isso provavelmente vale para muita gente fazendo trabalho interessante nessa área.

    Para quem quer explorar os papéis que existem além dos mais conhecidos, algumas referências mencionadas no post original:

    A série continua: na Parte 3, o foco será no contraste entre o que as pessoas imaginam ser o dia a dia de segurança e o que ele realmente é.

    Fonte

    Part 2 – Cybersecurity journeys: What even is this job? (https://aws.amazon.com/blogs/security/part-2-cybersecurity-journeys-what-even-is-this-job/)

  • Construindo agentes de longa duração com Grok 4.7 no Amazon Bedrock

    Grok 4.7 chega ao Amazon Bedrock com foco em agentes complexos

    O Grok 4.7, modelo desenvolvido pela xAI, está disponível no Amazon Bedrock — plataforma da AWS que reúne Modelos de Fundação (FM — Foundation Models) de diferentes provedores em um único ponto de acesso. Segundo a xAI, o Grok 4.7 foi treinado para trabalhar por mais tempo em tarefas difíceis e para saber quando revisar o próprio raciocínio antes de responder. Essas características fazem diferença especialmente em cenários de agentes, onde o modelo precisa executar muitos passos encadeados e verificar o que encontrou ao longo do caminho.

    Um agente eficaz não apenas consulta dados — ele formula uma resposta candidata, confronta essa resposta com o que aprendeu e refina até que o resultado faça sentido. O Grok 4.7 expõe um parâmetro chamado reasoning effort (nível de esforço de raciocínio), que controla o quanto o modelo delibera antes de cada resposta. Para cargas de trabalho com agentes, escolher o nível certo é uma decisão prática com impacto direto no consumo de tokens.

    O que a xAI reporta sobre o Grok 4.7

    De acordo com a xAI, o Grok 4.7 usa um modelo base maior do que o Grok 4.6 e passou por um ciclo mais longo de Aprendizado por Reforço (RL — Reinforcement Learning) com um conjunto de tarefas mais desafiadoras — com ênfase em problemas que levam muitas horas para serem concluídos. A empresa também reporta melhorias na capacidade do modelo de verificar o próprio trabalho e de gerenciar contextos mais longos.

    Os benchmarks publicados pela xAI mostram os maiores ganhos em categorias que exigem trabalho sustentado, não apenas respostas de turno único:

    • Terminal-Bench 4.0 (trabalho em terminal por várias horas): de 20,3% para 37,6%
    • EEBench (engenharia elétrica): de 53,0% para 64,0%
    • Harvey Legal Agent Benchmark (trabalho jurídico): de 15,8% para 19,6%
    • CursorBench 4.0 (codificação de longa duração): de 40,4% para 46,3%
    • HealthBench (raciocínio clínico profissional): de 48,5% para 56,7%
    • AA Briefcase v1.1 (trabalho de escritório por várias horas): de 1.546 para 1.657

    Fonte dos dados: xAI, Introducing Grok 4.7. Pontuações publicadas pela xAI no lançamento do modelo.

    Benchmarks mostram desempenho em tarefas padronizadas. Para sua própria carga de trabalho, o próximo passo útil é medir em tarefas com o mesmo formato das suas — e é exatamente isso que a publicação original da AWS demonstra.

    A xAI informa uma janela de contexto de 500 mil tokens para o Grok 4.7, com suporte a entrada de texto e imagem, e saída em texto. No Amazon Bedrock, o modelo oferece esforço de raciocínio configurável, chamada de ferramentas (tool calling) e saída estruturada.

    Como acessar o Grok 4.7 no Amazon Bedrock

    O Grok 4.7 opera no endpoint bedrock-runtime e é acessado por meio de um perfil de inferência cross-region. Dois perfis estão disponíveis:

    • us.xai.grok-4.7: roteamento dentro da geografia dos EUA — indicado quando há requisitos de residência de dados nos EUA.
    • global.xai.grok-4.7: roteamento entre Regiões AWS comerciais — indicado quando não há restrições de residência e se deseja maior capacidade disponível.

    A inferência cross-region distribui as requisições entre múltiplas Regiões AWS, oferecendo maior throughput sem que você precise gerenciar capacidade região a região. As requisições referenciam um dos perfis de inferência, não um ID de modelo diretamente.

    O modelo suporta a API Chat Completions e Responses compatível com OpenAI, além da API Converse do Amazon Bedrock. Na API Converse, o raciocínio é retornado como um bloco reasoningContent ao lado do bloco de texto. Em inferenceConfig, defina apenas maxTokens; parâmetros específicos do modelo, como o nível de esforço de raciocínio, devem ir em additionalModelRequestFields.

    Para a lista atualizada de Regiões suportadas, camadas de serviço e preços por token, consulte o model card do Grok 4.7 no Guia do Usuário do Amazon Bedrock e a página de preços do Amazon Bedrock.

    Pré-requisitos e conexão com o modelo

    Para reproduzir os exemplos, você precisa de:

    • Uma conta AWS com acesso ao Amazon Bedrock e acesso ao modelo Grok 4.7 habilitado.
    • Python 3.9 ou superior, com os pacotes openai, boto3 e aws-bedrock-token-generator instalados.
    • Credenciais AWS configuradas no ambiente.
    • Sua identidade do IAM (Gerenciamento de Identidade e Acesso — Identity and Access Management) precisa de permissão bedrock:InvokeModel tanto no perfil de inferência quanto no projeto padrão da sua conta.

    Para uso em produção, a AWS recomenda gerar um token de curta duração a partir das suas credenciais IAM existentes, mantendo a autenticação vinculada à sua identidade IAM sem armazenar segredos de longa duração:

    from aws_bedrock_token_generator import provide_token
    from openai import OpenAI
    
    REGION = "us-west-2"
    MODEL_ID = "us.xai.grok-4.7"
    
    client = OpenAI(
        api_key=provide_token(region=REGION),
        base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
        timeout=360,
        max_retries=0,  # retries are handled explicitly, see "Build in retries" below
    )

    Um ponto de atenção importante: tokens de raciocínio contam como tokens de saída e consomem o limite de max_completion_tokens antes que o texto da resposta seja produzido. Se o limite for atingido durante o raciocínio, a resposta retorna sem texto de resposta. Os testes descritos no artigo original usaram um limite de 32.768 tokens, o que deixou margem suficiente em todos os níveis de esforço.

    O Grok 4.7 suporta quatro níveis de esforço: low, medium, high e xhigh. Como esses níveis podem mudar entre versões do modelo, vale confirmar os suportados diretamente no serviço em vez de codificá-los fixamente:

    def supported_effort_levels(candidates=("none", "low", "medium", "high", "xhigh", "max")):
        supported = []
        for level in candidates:
            try:
                client.responses.create(model=MODEL_ID, input="Say OK.", reasoning={"effort": level}, max_output_tokens=2048)
                supported.append(level)
            except Exception as exc:
                if "unsupported_value" not in str(exc) and "invalid_value" not in str(exc):
                    raise
        return supported
    
    print(supported_effort_levels())
    # ['low', 'medium', 'high', 'xhigh']

    Desenhando tarefas que exigem raciocínio real

    Muitas avaliações de agentes testam apenas diligência: ler um registro, filtrar, somar. Essas tarefas têm valor, mas para enxergar o que o esforço de raciocínio realmente contribui, a tarefa precisa exigir busca: a resposta não pode ser lida diretamente dos dados, ela precisa ser proposta e verificada. Para o experimento descrito no artigo original, foram construídas três tarefas sobre um ambiente sintético com 20 serviços e sete ferramentas disponíveis. Cada tarefa tem exatamente uma resposta correta, verificada por força bruta.

    • Diagnóstico de duas falhas (two_fault_diagnosis): dois serviços falharam silenciosamente às 03:00 e outros 12 geraram alertas. O agente precisa identificar os dois que falharam. Serviços com falha não geram alertas próprios, então a resposta não está entre os serviços que alertaram. São 190 pares possíveis; apenas um explica exatamente os alertas observados.
    • Agendamento de manutenção (maintenance_schedule): agendar oito serviços em quatro noites, dois por noite, respeitando dez restrições e uma regra que impede dois serviços do mesmo time de compartilhar uma noite. São 2.520 agendamentos possíveis; apenas um é válido.
    • Orçamento de migração (migration_budget): escolher candidatos para migração que maximizem a redução de risco dentro de um orçamento, incluindo pré-requisitos transitivos. São 53 conjuntos viáveis; apenas um é ótimo. Selecionar pelo melhor índice individual gera um conjunto nove pontos abaixo do ótimo.

    Quatro práticas mantêm uma avaliação como essa confiável:

    • Declarar cada regra que o avaliador usa explicitamente no prompt.
    • Provar que cada tarefa tem uma única resposta (o ambiente é pequeno o suficiente para enumerar todos os candidatos).
    • Avaliar apenas a linha final obrigatória da resposta, não o texto completo.
    • Rastrear erros de formato separadamente dos erros de conteúdo.

    O sistema de ferramentas usa enum para restringir parâmetros aos valores válidos conhecidos. O prompt de sistema do agente é deliberadamente curto e instrui o modelo a verificar a resposta antes de entregá-la:

    AGENT_SYSTEM = (
        "You are an infrastructure analyst agent. Use the tools to gather facts and never guess "
        "a value you can look up. Before answering, check your answer against every rule in the "
        "task. End with the FINAL line exactly as the task specifies."
    )

    Resultados: 72 execuções, 67 corretas

    O experimento rodou seis execuções de cada tarefa em cada nível de esforço, totalizando 72 execuções. O agente respondeu corretamente em 67 delas.

    • two_fault_diagnosis: low 5/6 | medium 6/6 | high 6/6 | xhigh 6/6
    • maintenance_schedule: low 5/6 | medium 5/6 | high 5/6 | xhigh 6/6
    • migration_budget: low 5/6 | medium 6/6 | high 6/6 | xhigh 6/6
    • Total: low 15/18 | medium 17/18 | high 17/18 | xhigh 18/18

    Em termos de consumo de tokens por execução:

    • low: média de 1.184 tokens de saída, mediana de 18 segundos
    • medium: média de 6.430 tokens de saída, mediana de 98 segundos
    • high: média de 6.778 tokens de saída, mediana de 89 segundos
    • xhigh: média de 9.147 tokens de saída, mediana de 106 segundos

    Três observações relevantes se destacam. Primeiro, o nível xhigh acertou todas as 18 execuções. Segundo, o esforço muda o quanto o agente raciocina, não o quanto ele explora: as chamadas de ferramentas ficaram praticamente estáveis entre 17,2 e 18,7 por execução em todos os níveis — o que variou foi o volume de raciocínio aplicado aos dados coletados. Terceiro, o nível low oferece uma ótima relação custo-qualidade: acertou 15 de 18 execuções usando cerca de um oitavo dos tokens de saída do xhigh, com mediana de apenas 18 segundos por execução.

    Monitorando o raciocínio em produção

    Em produção, você não tem uma resposta conhecida para comparar, mas tem o número de tokens de saída e chamadas de ferramentas por execução. Esses dados fornecem um sinal operacional útil. Todas as execuções corretas em medium ou acima usaram pelo menos 1.739 tokens de saída. Uma execução que não faz chamadas de ferramentas ou que produz muito menos saída do que o normal para aquele nível merece revisão:

    def flag_for_review(run, baseline):
        """baseline: output tokens of graded, correct runs at the same effort level."""
        reasons = []
        if run["tool_calls"] == 0:
            reasons.append("made no tool calls")
        if run["output_tokens"] < 0.2 * min(baseline):
            reasons.append(f"used {run['output_tokens']} output tokens, "
                           f"under a fifth of the lowest correct run ({min(baseline)})")
        return reasons

    Calibre o baseline a partir de execuções que você já avaliou, por tarefa e por nível de esforço, e aplique às execuções futuras. Em low, onde cada execução é breve, o volume de saída é um sinal mais fraco — combine com verificações pontuais.

    Como escolher o nível de esforço adequado

    Os resultados sugerem algumas regras práticas. Tarefas que envolvem busca, otimização ou teste de hipóteses se beneficiam mais de medium ou acima. Tarefas que seguem um caminho único ou cujas respostas são revisadas por downstream podem rodar eficientemente em low.

    Vale destacar que o esforço é um parâmetro de requisição, não de agente. Isso significa que um mesmo agente pode rodar seus passos de planejamento e verificação em nível mais alto e seus passos mecânicos — como formatar um resultado de ferramenta — em low. Essa combinação une boa parte da confiabilidade dos níveis mais altos com um custo de tokens menor.

    Controles operacionais para cargas de trabalho com agentes

    O artigo original da AWS também aborda boas práticas de operação. Para agentes que emitem alto volume de chamadas, retentativas devem ser parte do design: defina um timeout de requisição, faça retry apenas em erros recuperáveis, use backoff exponencial com jitter e respeite o cabeçalho Retry-After quando retornado:

    import random, time
    
    RETRYABLE = {408, 429, 500, 502, 503, 504}
    
    def call_with_backoff(fn, attempts=7, base=4.0, cap=180.0):
        for attempt in range(1, attempts + 1):
            try:
                return fn()
            except Exception as exc:
                status = getattr(exc, "status_code", None)
                retryable = status in RETRYABLE or "timed out" in str(exc).lower()
                if not retryable or attempt == attempts:
                    raise
                time.sleep(random.uniform(base, min(cap, base * 2 ** attempt)))

    Outras recomendações operacionais incluem:

    • Auditoria de execuções: o model invocation logging do Bedrock grava dados de requisição e resposta no Amazon S3 ou Amazon CloudWatch Logs, permitindo revisar transcrições completas depois.
    • Monitoramento de volume de raciocínio em escala: métricas do Amazon CloudWatch oferecem visão agregada do uso de tokens, onde os baselines por nível de esforço podem virar alarmes.
    • Atribuição de gastos por agente: o AWS Cost Explorer e o Relatório de Custo e Uso (CUR — Cost and Usage Report) detalham o uso por modelo.
    • Camadas de serviço por urgência: a camada de serviço é definida por requisição, então uma análise noturna pode usar a camada Flex enquanto uma requisição interativa usa a camada Priority.
    • Perfil de roteamento: o perfil Global serve a partir de qualquer Região AWS comercial e geralmente tem preço menor por token do que o roteamento geográfico. O perfil US mantém o processamento dentro dos Estados Unidos.

    Limitações da medição

    É importante contextualizar os resultados. Com seis execuções por tarefa e nível de esforço, as diferenças entre níveis são indicativas, não estatisticamente conclusivas. O ambiente é sintético — ferramentas lendo dados gerados em código — o que permite provar que cada tarefa tem exatamente uma resposta e avaliar automaticamente, mas não testa latência, resultados parciais ou erros de ferramentas reais. Os tempos medianos variaram de 18 segundos em low a 106 segundos em xhigh, sendo um proxy reduzido para trabalho de longa duração. Além disso, os resultados são para uma versão de modelo, uma Região e um prompt por tarefa — diferentes formulações podem alterar os números.

    Os experimentos relatam contagem de tokens, não valores em moeda. Para converter em custo, aplique as taxas atuais do seu perfil de inferência e camada de serviço na página de preços do Amazon Bedrock. Os perfis Global e US Geo têm preços diferentes, e as camadas Flex e Priority aplicam multiplicadores.

    Leitura complementar

    Fonte

    Build long-horizon agents with Grok 4.7 on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-long-horizon-agents-with-grok-4-7-on-amazon-bedrock/)

  • AWS Agent Registry passa a suportar metadados personalizados nos registros

    O que mudou no AWS Agent Registry

    A AWS anunciou uma nova capacidade para o AWS Agent Registry: o suporte a metadados personalizados nos registros do catálogo. O AWS Agent Registry é o catálogo centralizado e governado da AWS para gerenciar agentes, servidores MCP (Model Context Protocol), habilidades de agentes, gateways e recursos customizados dentro de uma organização.

    Até então, cada registro contava apenas com nome e descrição — informações que se tornam insuficientes quando uma organização passa a operar centenas desses recursos. Com a nova funcionalidade, é possível estender cada registro com campos estruturados definidos pela própria organização, tornando a descoberta e a governança muito mais eficientes tanto para pessoas quanto para sistemas automatizados.

    Como os metadados personalizados funcionam

    Com esse recurso, quem publica recursos no registro pode incluir campos como responsável pelo time, classificação dos dados ou status de revisão diretamente em cada registro.

    O funcionamento segue uma lógica de esquema em dois níveis:

    • Esquema comum por registry: define os atributos compartilhados entre todos os tipos de registro.
    • Campos específicos por tipo: permitem estender o esquema com informações relevantes para cada categoria — por exemplo, a família de modelo para registros de agentes.

    Cada campo suporta os seguintes tipos de valor: texto livre, URL, booleano ou seleção a partir de uma lista de valores permitidos. O próprio registry valida os campos obrigatórios e os valores aceitos sempre que um registro é criado ou atualizado.

    Filtragem e descoberta por metadados

    Uma vez configurados, os metadados personalizados podem ser usados como filtros nas buscas do registry. Essa filtragem está disponível por meio de:

    • Console de Gerenciamento da AWS (AWS Management Console)
    • Interface de Linha de Comando da AWS (AWS CLI)
    • Kits de Desenvolvimento de Software da AWS (AWS SDKs)
    • Endpoint MCP do registry

    Isso significa que tanto equipes de engenharia quanto fluxos automatizados de governança conseguem localizar e auditar recursos de forma consistente, sem depender apenas de buscas por nome.

    Disponibilidade

    O suporte a metadados personalizados está disponível em todas as regiões da AWS onde o AWS Agent Registry já opera: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio) e Europa (Irlanda).

    Para saber mais sobre o serviço, acesse a documentação do AWS Agent Registry. Para um guia detalhado de configuração, consulte como definir um esquema de metadados personalizados e como definir valores de metadados personalizados em um registro.

    Fonte

    AWS Agent Registry now supports custom metadata for registry records (https://aws.amazon.com/about-aws/whats-new/2026/10/aws-agent-registry-custom-metadata-registry-records)

  • Agentes de IA que pagam por recursos web: como o Anchor Browser se integra ao AgentCore Payments

    O problema: agentes que travam diante de um HTTP 402

    Agentes de Inteligência Artificial (IA) cada vez mais precisam acessar recursos web que têm preço por requisição. Conjuntos de dados premium cobram por consulta, Interfaces de Programação de Aplicação (APIs) de pesquisa medem o uso por chamada, e publishers fechados exigem pagamento para liberar conteúdo. Quando um agente encontra um desses recursos, o servidor devolve um HTTP 402 Payment Required — e o agente simplesmente trava.

    Sem um mecanismo de pagamento embutido, sem orçamento vinculado à sessão e sem uma forma programática de satisfazer a cobrança, a tarefa que deveria rodar de forma autônoma passa a exigir intervenção manual. É exatamente esse gap que a AWS buscou endereçar com a integração entre o Anchor Browser e o Amazon Bedrock AgentCore Payments.

    O que é o protocolo x402

    O x402 é um padrão aberto para pagamentos máquina a máquina via HTTP. Quando um servidor responde com 402 Payment Required, ele inclui no payload o valor cobrado, os métodos de pagamento aceitos e o endereço de destino. O agente usa essas informações para completar a transação e obter acesso ao recurso. Esse padrão é o núcleo de toda a integração descrita neste artigo.

    Anchor Browser e AgentCore Payments: o que cada um faz

    O Anchor Browser é uma solução de automação de navegador baseada em nuvem, construída especificamente para agentes de IA. Cada sessão de agente roda dentro de um ambiente de navegador gerenciado que mantém estado de autenticação, lida com navegação, captura requisições de rede e oferece uma visualização ao vivo das interações na página. A solução foi desenvolvida em colaboração com o AWS Generative AI Innovation Center Partner Agent Factory e está disponível no AWS Marketplace.

    O Amazon Bedrock AgentCore Payments é uma capacidade totalmente gerenciada dentro do AgentCore. Ele permite que agentes de IA descubram, acessem e paguem por APIs, servidores de Protocolo de Contexto de Modelo (MCP) e conteúdo web de forma autônoma. O serviço gerencia a conectividade com carteiras digitais, aplica limites de gasto configuráveis na camada de infraestrutura e processa pagamentos via protocolo x402. Toda a observabilidade — tentativas de pagamento, aprovações, negações e liquidações — é entregue pelo Amazon CloudWatch.

    Quando um agente rodando no Anchor Browser encontra uma resposta 402, o AgentCore Payments autoriza e completa a transação dentro do orçamento configurado. O fluxo de trabalho continua sem interrupção.

    Por que construir tudo do zero é um problema sério

    Sem uma solução gerenciada, os desenvolvedores precisam construir toda a pilha de pagamento internamente. Esse esforço se divide em quatro categorias de complexidade:

    • Tratamento do protocolo de pagamento: detectar e interpretar o desafio 402 na resposta HTTP, construir o cabeçalho de pagamento com prova criptográfica no formato exato esperado pelo comerciante, e suportar múltiplos esquemas de pagamento sem hardcodar lógica específica de fornecedor no agente.
    • Segurança e gerenciamento de chaves: armazenar uma chave privada para assinar pagamentos em um ambiente exposto a entradas não confiáveis, gerenciar o ciclo de vida da carteira, incluindo rotação de chaves e atualização de credenciais.
    • Resiliência operacional: reenviar a requisição original com o cabeçalho de pagamento preservando estado de sessão, cookies e contexto; garantir idempotência nas operações de carteira; e aplicar limites de gasto por sessão e por transação com rastreamento em tempo real.
    • Observabilidade e conformidade: capturar cada tentativa de pagamento, aprovação, negação e liquidação em logs de auditoria para fins de conformidade e reconciliação.

    Além do esforço de engenharia, há riscos de segurança relevantes. Sem limites rígidos de gasto aplicados na infraestrutura, um bug, um loop de retry, uma injeção de prompt ou um acesso inadvertido pode disparar pagamentos não intencionais. E quando chaves privadas residem dentro do runtime do agente, elas compartilham o ambiente de execução com páginas web não confiáveis, ferramentas de terceiros e dependências externas — vetores que podem expor as credenciais que controlam fundos reais.

    A solução: mover toda a pilha de pagamento para a infraestrutura

    A integração entre Anchor Browser e AgentCore Payments resolve essa complexidade movendo toda a pilha de pagamento para infraestrutura gerenciada. O agente passa a ter apenas dois componentes relacionados a pagamento: uma sessão de orçamento e a ferramenta x402 embutida. Autenticação, segredos de carteira, limites de pagamento, observabilidade e assinatura de provas ficam na camada do AgentCore Payments.

    No centro do serviço está o Payment Manager, o recurso de nível superior que coordena as operações de pagamento para a conta AWS. Ao criar um Payment Manager, é necessário especificar um tipo de autorizador e uma função do Gerenciamento de Identidade e Acesso (IAM). O AgentCore então provisiona uma identidade de carga de trabalho correspondente no Amazon Bedrock AgentCore Identity. Os demais componentes conectam o Payment Manager à infraestrutura de carteira externa:

    • Um PaymentConnector integra o Payment Manager com um provedor de carteira externo — Coinbase Developer Platform (Coinbase CDP) ou Stripe Privy.
    • Um PaymentCredentialProvider armazena as credenciais do provedor de carteira com segurança no AgentCore Identity.
    • Um PaymentInstrument identifica o endereço de carteira específico do qual os fundos serão debitados.

    Para descoberta de endpoints, o AgentCore disponibiliza um servidor MCP do Coinbase x402 Bazaar através do Amazon Bedrock AgentCore Gateway, permitindo que agentes descubram programaticamente endpoints x402 disponíveis para uso por requisição.

    Como o fluxo de pagamento funciona na prática

    O fluxo completo, do momento em que o navegador encontra um recurso protegido por x402 até o agente receber a resposta e continuar a tarefa, funciona assim:

    • O Anchor Browser cria uma PaymentSession dedicada no AgentCore para a sessão de navegador, vinculando-a ao instrumento de pagamento configurado e ao orçamento definido.
    • O agente navega para uma URL ou faz uma requisição fetch ou XMLHttpRequest (XHR). O servidor responde com um desafio 402 especificando valor, métodos aceitos e endereço de pagamento.
    • O Anchor Browser lê o payload do desafio 402 e verifica compatibilidade com o método de pagamento vinculado à PaymentSession.
    • O AgentCore Payments valida que o valor está dentro do limite de gasto da sessão, assina a transação usando o provedor de carteira configurado (Coinbase CDP ou Stripe Privy) e retorna a prova criptográfica. Nenhum material de chave entra no navegador ou no runtime do agente.
    • O navegador reenvia a requisição original com o cabeçalho de pagamento — PAYMENT-SIGNATURE para x402 v2 ou X-PAYMENT para x402 v1.
    • O comerciante valida a prova criptográfica, liquida a transação on-chain e entrega o conteúdo protegido. O agente continua a tarefa normalmente.

    Configurando pagamentos x402 automáticos no Anchor Browser

    Configurar pagamentos agênticos no Anchor Browser exige apenas uma propriedade de sessão: definir session.x402 como true. O valor padrão é false. Quando habilitado, a sessão de navegador passa a acessar automaticamente sites protegidos por x402, com pagamentos assinados pelo AgentCore Payments e reenvios dentro da mesma sessão.

    Atenção: habilitar session.x402 autoriza o navegador a realizar pagamentos reais a partir do instrumento de pagamento configurado.

    Os exemplos abaixo mostram como criar uma sessão habilitada para pagamento via cURL e JavaScript:

    cURL:

    curl --request POST \
      --url https://api.anchorbrowser.io/v1/sessions \
      --header "anchor-api-key: $ANCHOR_API_KEY" \
      --header "content-type: application/json" \
      --data '{"session":{"x402":true}}'

    JavaScript:

    const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
      method: 'POST',
      headers: {
        'anchor-api-key': process.env.ANCHOR_API_KEY,
        'content-type': 'application/json',
      },
      body: JSON.stringify({ session: { x402: true } }),
    });
    
    const { data: session } = await response.json();
    console.log(session.cdp_url);

    Após conectar via Protocolo Chrome DevTools (CDP), o agente navega normalmente. Não é necessário incluir chave de carteira ou cabeçalho de pagamento no código de automação. O navegador trata os desafios 402, a assinatura do pagamento e os reenvios de forma transparente para requisições de navegação, fetch e XHR.

    O código de automação permanece inalterado. O exemplo abaixo demonstra que nenhum código específico de pagamento é necessário:

    const { chromium } = require('playwright');
    
    // Connect to the x402-enabled session via CDP
    const browser = await chromium.connectOverCDP(session.cdp_url);
    const page = await browser.newPage();
    
    // Navigate to an x402-protected resource exactly as with a free page
    await page.goto('https://premium-research.example.com/market-report');
    
    // The page loaded, the payment was handled automatically
    // Extract content as normal
    const content = await page.textContent('article');

    Sem lógica de carteira, sem construção de cabeçalho de pagamento, sem código de retry. O agente navega para a URL. Se o servidor retornar 402, o Anchor Browser coordena com o AgentCore Payments para assinar a prova de pagamento, reenvia a requisição com o cabeçalho apropriado e entrega o conteúdo à página. O código de automação recebe a página final renderizada sem nenhuma indicação de que um pagamento ocorreu.

    Chamadas de API pagas com a ferramenta x402 embutida

    Recursos pagos não se limitam a páginas web. Muitos são APIs que esperam métodos POST, PUT ou outros. Exemplos comuns incluem serviços de enriquecimento de dados, endpoints de inferência premium e APIs de conteúdo licenciado.

    Para esses casos, os agentes do Anchor Browser incluem uma ferramenta x402 embutida que funciona como uma chamada HTTPS padrão dentro do contexto do navegador. Se o servidor retornar um desafio 402, o navegador coordena a assinatura do pagamento via AgentCore Payments e reenvia a requisição com o cabeçalho assinado. O código recebe a resposta como se o endpoint fosse gratuito.

    // Fetch call to a paid API endpoint within the x402-enabled session
    const response = await page.evaluate(async () => {
      const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify({ company_domain: 'example.com' }),
      });
      return res.json();
    });
    
    // If the API returned 402, AgentCore handled payment automatically
    // The response contains the enriched data
    console.log(response);

    Para consultar os limites específicos de gasto e expiração por sessão, a documentação técnica do Anchor Browser traz os detalhes atualizados. Se a resposta do comerciante for malformada, nenhum método de pagamento compatível for oferecido, o orçamento estiver esgotado ou o AgentCore Payments rejeitar o pagamento, o navegador devolve a resposta 402 original ao código de automação, que pode tratá-la como um erro HTTP padrão.

    Principais benefícios da integração

    • Sem infraestrutura de pagamento para construir: nenhum SDK de carteira para integrar, nenhum parser de resposta 402 para escrever, nenhum loop de retry para implementar e nenhum log de auditoria customizado para manter. O AgentCore Payments gerencia toda a pilha.
    • Sem alterações nas ferramentas existentes: scripts Playwright, automações Puppeteer, comandos CDP e fluxos de agentes no Anchor Browser continuam funcionando exatamente como antes. Pagamento é uma capacidade de sessão, não uma modificação na lógica do agente.
    • Chaves privadas fora do runtime: assinatura e liquidação acontecem dentro do AgentCore Payments. O serviço se comunica com Coinbase CDP ou Stripe Privy através de armazenamento seguro de credenciais no AgentCore Identity. O runtime do agente não tem acesso a material de chave que movimenta fundos.
    • Orçamentos aplicados na infraestrutura: cada sessão opera dentro de limites de gasto definidos que o AgentCore aplica antes de autorizar qualquer pagamento. Quando uma sessão atinge o limite, o AgentCore Payments nega o pagamento. A observabilidade completa é entregue via Amazon CloudWatch.
    • Faturamento consolidado: o Anchor Browser liquida cobranças x402 de terceiros em créditos na mesma fatura que o tempo de sessão do navegador. Não há custódia de criptomoeda separada para gerenciar, nem saldo de USDC para monitorar.

    Conclusão

    A integração entre Anchor Browser e AgentCore Payments equipa agentes de IA para lidar com desafios de pagamento x402 de forma autônoma — tanto para páginas web pagas quanto para endpoints de API pagos. As credenciais de carteira ficam fora do código do agente, e nenhuma infraestrutura de pagamento customizada é necessária.

    À medida que mais da web migra para precificação por requisição, agentes sem mecanismo de pagamento simplesmente não conseguem completar tarefas envolvendo recursos pagos. Essa integração endereça esse gap: os agentes completam fluxos de trabalho pagos de ponta a ponta, operando dentro de orçamentos definidos, com observabilidade completa e sem material criptográfico no runtime.

    Para começar, a AWS disponibiliza os seguintes recursos:

    Fonte

    Building agents that transact with Anchor Browser and AgentCore payments (https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)