Author: Make.com Service User

  • Amazon CloudWatch Pipelines ganha processadores de GeoIP, RDS e XML

    Novos processadores chegam ao CloudWatch Pipelines

    A AWS anunciou a adição de três novos processadores ao Amazon CloudWatch Pipelines: um parser de logs do Amazon RDS, um parser de XML e um processador de enriquecimento por GeoIP. A novidade amplia as capacidades de transformação de dados de telemetria diretamente na ingestão, sem a necessidade de gerenciar infraestrutura adicional.

    Para quem ainda não conhece o serviço: o CloudWatch Pipelines é um serviço totalmente gerenciado que ingere, transforma e roteia dados de telemetria para o CloudWatch. A proposta é eliminar a necessidade de pipelines customizados e servidores dedicados para esse tipo de processamento.

    O problema que esses processadores resolvem

    Fontes de log comuns produzem dados em formatos que não são consultáveis diretamente — é preciso reprocessá-los antes de qualquer análise. Três cenários clássicos ilustram bem o desafio:

    • Logs do RDS Aurora chegam no formato nativo do mecanismo de banco de dados, sem estrutura padronizada;
    • Logs de aplicação frequentemente carregam payloads em XML embutidos em campos de texto;
    • Endereços IP presentes nos logs não trazem nenhum contexto geográfico por padrão.

    Os três novos processadores foram criados exatamente para endereçar cada um desses casos.

    O que cada processador faz

    Parser de logs do Amazon RDS

    Converte logs de auditoria e de erros do Aurora em campos estruturados. Isso facilita, por exemplo, a geração de relatórios de conformidade a partir de logs de auditoria do banco de dados, sem precisar de etapas extras de transformação.

    Parser de XML

    Converte um campo que contém uma string XML em JSON. Um caso de uso prático é a extração do payload XML presente em logs do Windows Event Log, tornando os dados consultáveis de forma mais simples e eficiente.

    Processador de GeoIP

    Enriquece qualquer campo de endereço IP com contexto geográfico, incluindo cidade, país e coordenadas. Combinado com o parser de XML, por exemplo, é possível identificar a origem geográfica de eventos de segurança diretamente no pipeline.

    Como usar na prática

    Os processadores podem ser utilizados de forma independente ou combinados em um único pipeline. A AWS exemplifica dois cenários:

    • Fazer o parse de um log de auditoria do Aurora em campos estruturados para relatórios de conformidade;
    • Extrair o payload XML de um Windows Event Log em JSON e resolver o IP de origem para cidade e país, tudo em um único pipeline voltado à análise de segurança.

    Disponibilidade e custos

    Os três processadores estão disponíveis sem custo adicional em todas as regiões da AWS onde o CloudWatch Pipelines já está em disponibilidade geral. As taxas normais de ingestão e armazenamento de logs do CloudWatch continuam se aplicando.

    A configuração pode ser feita pelo Console de Gerenciamento da AWS, pela AWS CLI ou pelos AWS SDKs. Para começar, a AWS disponibiliza a documentação oficial do CloudWatch Pipelines com todos os detalhes sobre os novos processadores.

    Fonte

    Amazon CloudWatch pipelines adds GeoIP, RDS, and XML processors (https://aws.amazon.com/about-aws/whats-new/2026/08/cloudwatch-geoip-rds-xml/)

  • Amazon CloudWatch Centralization agora propaga tags dos grupos de log para contas de destino

    O que mudou no CloudWatch Centralization

    A AWS anunciou uma atualização importante no Amazon CloudWatch Centralization: a funcionalidade agora copia automaticamente as tags dos grupos de log das contas de origem para os grupos de log criados nas contas de destino pelas regras de centralização.

    Para quem não está familiarizado com o recurso, o CloudWatch Centralization permite agregar dados de log de múltiplas contas e regiões em uma única conta de destino — o que simplifica bastante o monitoramento em ambientes com múltiplas contas AWS.

    Por que a propagação de tags faz diferença

    Antes dessa atualização, as tags que as equipes mantinham nos grupos de log das contas de origem — como tags de custo, propriedade e conformidade — não acompanhavam os logs ao serem centralizados. Isso criava uma lacuna: os dados chegavam na conta central, mas sem o contexto de governança que as tags carregam.

    Com a propagação de tags, as tags do grupo de log de origem passam a ser aplicadas ao grupo de log correspondente na conta de destino, e ficam sincronizadas de acordo com o comportamento de propagação definido durante a configuração da regra de centralização.

    Exemplo prático de uso

    Um caso de uso direto mencionado pela AWS: uma equipe de plataforma pode preservar tags como Application e CostCenter nos grupos de log centralizados. Com isso, é possível:

    • Usar essas tags para definir escopo de acesso via condições do Gerenciamento de Identidade e Acesso (IAM);
    • Gerar relatórios de gasto centralizado de logs por equipe diretamente no AWS Cost Explorer.

    Ou seja, a atualização conecta dois pontos que antes exigiam trabalho manual: centralizar logs e manter a rastreabilidade de custos e responsabilidades por equipe.

    Disponibilidade e como ativar

    A propagação de tags está disponível em todas as regiões AWS onde o CloudWatch Centralization já está habilitado. Para verificar a lista de regiões suportadas, consulte a tabela de regiões AWS.

    Para ativar o recurso, basta habilitar a propagação de tags em uma regra de centralização existente pelo console do Amazon CloudWatch, ou via Interface de Linha de Comando (AWS CLI) ou SDKs da AWS.

    Para se aprofundar no funcionamento da centralização de logs com preservação de tags, a AWS disponibiliza o Guia do usuário de centralização de logs. Informações sobre preços estão na página de preços do Amazon CloudWatch.

    Fonte

    Amazon CloudWatch log Centralization now supports log group tag propagation (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cloudwatch-centralization-tag-propogation/)

  • Atualização Crítica de Segurança do Amazon Corretto — Agosto de 2026

    O que foi anunciado

    Em 18 de agosto de 2026, a AWS publicou uma Atualização Crítica de Patch de Segurança — em inglês, Critical Security Patch Update (CSPU) — para o Amazon Corretto. O pacote de correções abrange tanto as versões de Suporte de Longo Prazo (Long-Term Support, LTS) quanto as versões de Lançamento de Funcionalidades (Feature Release, FR) do OpenJDK distribuídas pelo Corretto.

    Versões corrigidas

    As seguintes versões já estão disponíveis para download:

    • Corretto 26.0.2.11.1
    • Corretto 25.0.4.8.1
    • Corretto 21.0.12.9.1
    • Corretto 17.0.20.10.1
    • Corretto 11.0.32.10.1
    • Corretto 8u504

    Ou seja, toda a família de versões ativamente mantidas pelo Corretto recebeu correções neste ciclo — do Corretto 8, ainda amplamente usado em sistemas legados, até o Corretto 26, a versão mais recente disponível.

    O que é o Amazon Corretto

    Para quem ainda não conhece: o Amazon Corretto é uma distribuição do OpenJDK sem custo, multiplataforma e pronta para uso em ambientes de produção. A AWS mantém o Corretto como uma alternativa robusta ao JDK padrão, com suporte de longo prazo e patches de segurança regulares — exatamente como este anunciado agora.

    Por ser baseado no OpenJDK, o Corretto é compatível com aplicações Java existentes sem necessidade de modificações, o que o torna uma escolha popular em workloads corporativas na nuvem e on-premises.

    Como obter as atualizações

    Há duas formas principais de aplicar as correções:

    • Download direto: acesse a página oficial do Corretto e baixe o instalador correspondente à sua versão — estão disponíveis o Corretto 26, 25, 21, 17, 11 e 8.
    • Via repositório Linux: para sistemas Linux, é possível receber as atualizações configurando um repositório Corretto via Apt, Yum ou Apk, dependendo da distribuição utilizada. Essa abordagem facilita a gestão de atualizações em ambientes automatizados e pipelines de CI/CD.

    Por que aplicar agora

    Atualizações classificadas como críticas de segurança merecem atenção imediata. Vulnerabilidades no runtime Java podem expor aplicações a riscos sérios, especialmente em ambientes que processam dados sensíveis ou ficam expostos à internet. A recomendação para equipes que utilizam o Corretto em produção é priorizar a atualização para as versões corrigidas o quanto antes.

    Contribuições e feedback

    A AWS convida a comunidade a enviar feedback e contribuições pelo repositório oficial do Corretto no GitHub.

    Fonte

    Amazon Corretto August 2026 Critical Security Patch Updates (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-corretto-august-2026-security-updates)

  • Amazon Bedrock passa a suportar o SpaceXAI Grok 4.6

    O que foi anunciado

    A AWS anunciou que o Amazon Bedrock passou a suportar o Grok 4.6, o mais recente modelo flagship da SpaceXAI. A adição amplia o catálogo de modelos disponíveis na plataforma gerenciada da AWS para construção de aplicações com Inteligência Artificial (IA) generativa.

    Principais capacidades do Grok 4.6

    O Grok 4.6 foi desenvolvido com foco em dois grandes pilares: agentes de longa duração e trabalho interativo e visual. Entre suas características técnicas, destacam-se:

    • Janela de contexto de 500K tokens — uma das maiores entre os modelos disponíveis atualmente, permitindo processar grandes volumes de informação em uma única chamada.
    • Níveis configuráveis de raciocínio — o modelo oferece quatro níveis de esforço de raciocínio: low, medium, high e xhigh, dando ao desenvolvedor controle sobre o equilíbrio entre velocidade e profundidade de análise.

    Para quais tarefas o Grok 4.6 se destaca

    Segundo a SpaceXAI, o Grok 4.6 foi projetado para se manter eficaz em tarefas complexas que envolvem muitas etapas consecutivas. Alguns exemplos de aplicação incluem:

    • Pesquisa e síntese de informações sobre um tema
    • Análise aprofundada de dados e documentos
    • Navegação e trabalho em bases de código extensas
    • Transformação de uma ideia em uma aplicação completa e refinada

    A empresa afirma que o modelo atinge inteligência de fronteira em benchmarks de codificação agêntica e trabalho com conhecimento, equiparando-se a outros modelos de ponta especializados em código.

    Benefícios de acessar o Grok 4.6 pelo Amazon Bedrock

    Ao utilizar o Grok 4.6 via Amazon Bedrock, as equipes aproveitam a infraestrutura gerenciada da AWS, que inclui:

    • Segurança e privacidade de nível empresarial
    • Monitoramento e registro de logs abrangentes
    • Flexibilidade de escala entre regiões AWS, com suporte a inferência entre regiões (cross-Region inference)

    Disponibilidade

    O Grok 4.6 já está disponível em todas as regiões AWS onde o Amazon Bedrock é oferecido. Para começar a utilizá-lo, a AWS recomenda consultar o model card do modelo na documentação oficial do Amazon Bedrock.

    Fonte

    Amazon Bedrock now supports SpaceXAI Grok 4.6 (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-grok-4-6/)

  • Autenticação customizada para integração de ferramentas com o interceptor Lambda no AgentCore Gateway

    O desafio: agentes modernos, ferramentas legadas

    Ao implantar agentes de IA com o Amazon Bedrock AgentCore, as organizações contam com suporte nativo a mecanismos modernos de autenticação — OAuth 2.0, Gerenciamento de Identidade e Acesso da AWS (IAM) e autenticação por chave de API — diretamente pelo Amazon Bedrock AgentCore Gateway. O problema é que muitos ambientes corporativos ainda operam com mecanismos legados, como a Autenticação Básica HTTP (Basic Auth), definida na RFC 7617.

    Para cobrir esse gap, a arquitetura extensível do AgentCore Gateway permite o uso de um interceptor Lambda de requisição — um código customizado executado toda vez que um agente chama uma ferramenta. A AWS publicou um guia detalhado mostrando como usar esse recurso para autenticar em APIs de ferramentas legadas com credenciais de sistema, sem expor essas credenciais ao agente.

    Aviso importante antes de começar

    A AWS é bastante direta no artigo: Basic Auth é uma tecnologia ultrapassada. Ela transmite credenciais como texto codificado em Base64 — o que não equivale à criptografia — e não deve ser adotada como estratégia de autenticação de longo prazo. A recomendação oficial é modernizar para OAuth 2.0, SAML, OpenID Connect ou IAM sempre que possível.

    No entanto, a realidade de muitas empresas é que a modernização da autenticação e a adoção de IA agêntica são projetos com cronogramas independentes. A solução apresentada existe como medida temporária para quem precisa integrar agentes a sistemas legados agora, sem esperar a modernização completa. Se esse for o seu caso, a AWS recomenda consultar um Arquiteto de Soluções para avaliar os riscos antes de avançar.

    Visão geral da solução

    A solução utiliza um interceptor Lambda de requisição no AgentCore Gateway para recuperar credenciais de sistema e construir o cabeçalho Basic Auth necessário para a API da ferramenta de destino. O fluxo completo funciona assim:

    • O agente de IA inicia uma chamada de ferramenta via Protocolo de Contexto de Modelo (MCP) para o gateway, acompanhada de um Token Web JSON (JWT) emitido por um provedor de identidade (IdP) configurado.
    • A camada de autenticação de entrada do gateway valida o token contra o IdP especificado na configuração do autorizador de entrada.
    • Após a autenticação de entrada ser bem-sucedida, o gateway invoca o interceptor Lambda de requisição, passando o payload original e os cabeçalhos da requisição — incluindo o JWT validado e seus atributos.
    • O interceptor revalida o JWT como medida de defesa em profundidade e, em seguida, recupera a credencial da conta de serviço do AWS Secrets Manager.
    • Com a credencial em mãos, o interceptor constrói um cabeçalho Basic Auth compatível e o adiciona à requisição de saída.
    • O AgentCore Gateway encaminha a requisição ajustada para a ferramenta de destino, que autentica, processa e retorna a resposta ao agente.

    Um ponto importante: como o Basic Auth transmite credenciais como texto Base64 (sem criptografia), é obrigatório garantir que toda comunicação com a API da ferramenta de destino ocorra sobre TLS. Além disso, alterações no código Lambda devem passar por revisão de duas pessoas como controle compensatório.

    Gerenciamento do ciclo de vida da credencial

    A credencial de sistema armazenada no Secrets Manager corresponde a uma conta de serviço no Active Directory (AD). O ciclo de vida exige uma semeadura manual única: um administrador cria a conta de serviço no AD e armazena a credencial inicial no Secrets Manager. Como o Secrets Manager não consegue ler uma senha diretamente do AD, esse passo inicial é necessário.

    Como boa prática de segurança, a AWS recomenda acionar uma rotação imediata após a semeadura, para descartar a senha conhecida por humanos. A partir daí, o Secrets Manager automatiza o processo: gera periodicamente uma nova senha e atualiza tanto o Secrets Manager quanto o AD de forma simultânea, eliminando o gerenciamento manual de credenciais em ambos os sistemas.

    Em tempo de execução, o interceptor Lambda recupera a credencial atual do Secrets Manager e a apresenta à ferramenta de destino, que a valida contra o AD. Para detalhes sobre como manter os dois repositórios sincronizados, a AWS disponibiliza documentação específica sobre rotação de credenciais do Active Directory armazenadas no AWS Secrets Manager.

    Implementação passo a passo

    O código de exemplo completo está disponível no repositório Implementando autenticação customizada para integração de ferramentas usando o Interceptor Lambda de Requisição. Os passos a seguir cobrem a configuração do interceptor e a lógica central de transformação de autenticação.

    Passo 1: Vincular o interceptor Lambda de requisição ao AgentCore Gateway

    O primeiro passo é configurar o AgentCore Gateway para invocar o interceptor Lambda antes de encaminhar a requisição à ferramenta de destino. Um detalhe crítico: é obrigatório habilitar a configuração passRequestHeaders. Sem ela, o interceptor não recebe o cabeçalho com o JWT de entrada, e todo o padrão de autenticação descrito aqui deixa de funcionar.

    import boto3
    
    bedrock_client = boto3.client('bedrock-agentcore-control', region_name='<your-region>')
    # e.g., region_name='us-west-2'
    
    bedrock_client.update_gateway(
        gatewayIdentifier='<your-gateway-id>',
        interceptorConfigurations=[
            {
                'interceptor': {
                    'lambda': {
                        'arn': 'arn:aws:lambda:<region>:<account-id>:function:<YourInterceptorFunction>'
                    }
                },
                'interceptionPoints': ['REQUEST'],
                'inputConfiguration': {
                    'passRequestHeaders': True
                }
            }
        ]
    )

    Passo 2: Validar o JWT de entrada

    O interceptor valida de forma independente a assinatura do JWT como medida de defesa em profundidade — protegendo contra cenários em que o interceptor poderia ser invocado por um caminho que contornasse a validação do gateway. Ele busca o Conjunto de Chaves Web JSON (JWKS) do provedor de identidade (com cache entre invocações Lambda aquecidas para evitar chamadas de rede repetidas), verifica a assinatura, expiração e emissor do token, e retorna os atributos decodificados.

    import jwt
    from jwt import PyJWKClient
    
    COGNITO_ISSUER = f"https://cognito-idp.{COGNITO_REGION}.amazonaws.com/{YOUR_COGNITO_USER_POOL_ID}"
    
    jwk_client = PyJWKClient(f"{COGNITO_ISSUER}/.well-known/jwks.json")
    
    def validate_jwt(token):
        """Validate JWT signature and return decoded claims."""
        signing_key = jwk_client.get_signing_key_from_jwt(token)
        return jwt.decode(token, signing_key.key, algorithms=["RS256"], issuer=COGNITO_ISSUER)

    Passo 3: Recuperar as credenciais de sistema do Secrets Manager

    O interceptor recupera a credencial da conta de serviço do Secrets Manager. Essa credencial é usada para autenticar o agente de IA na ferramenta de destino. O segredo é criptografado com uma chave gerenciada pelo cliente no Serviço de Gerenciamento de Chaves da AWS (AWS KMS) e armazenado em cache na memória pelo tempo de vida (TTL) configurado, minimizando chamadas à API enquanto garante que credenciais rotacionadas sejam capturadas rapidamente.

    import boto3
    
    secrets_client = boto3.client('secretsmanager')
    
    def get_system_credentials():
        """Retrieve the system service account credential from Secrets Manager."""
        response = secrets_client.get_secret_value(
            SecretId=os.environ['SYSTEM_CREDS_SECRET_NAME']
        )
        return json.loads(response['SecretString'])

    Em relação às permissões do IAM: a função de execução do interceptor precisa de secretsmanager:GetSecretValue com escopo para o Nome de Recurso Amazon (ARN) específico do segredo, e kms:Decrypt com escopo para a chave KMS usada na criptografia. O princípio do menor privilégio deve ser aplicado restringindo o ARN do recurso em vez de usar curingas.

    Vale destacar um ponto importante de segurança: o agente não tem acesso ao Secrets Manager. Apenas o interceptor Lambda de requisição — uma função determinística não influenciada pelo comportamento do modelo — recupera as credenciais. Esse isolamento é projetado para mitigar o risco de prompts adversariais instruindo o modelo a acessar ou exfiltrar segredos de autenticação, mesmo que o agente seja comprometido.

    Passo 4: Construir o cabeçalho Basic Auth

    Com o JWT validado e as credenciais em mãos, o interceptor constrói o cabeçalho Basic Auth para a ferramenta de destino.

    def build_system_auth_header(headers):
        """Validate JWT and construct Basic Auth header with system credential."""
        auth_header = headers.get('Authorization', '')
        if not auth_header.startswith('Bearer '):
            return _error_response(401, "No Bearer token found in request.")
    
        # Validate JWT (defense-in-depth)
        claims = validate_jwt(auth_header[7:])
        if not claims:
            return _error_response(401, "JWT validation failed.")
    
        # Retrieve system credential from Secrets Manager
        creds = get_system_credentials()
    
        # Construct Basic Auth header (RFC 7617)
        basic_auth_encoded = base64.b64encode(
            f"{creds['username']}:{creds['password']}".encode()
        ).decode()
        headers['Authorization'] = f"Basic {basic_auth_encoded}"
        return headers

    Conclusão

    O interceptor Lambda de requisição no Amazon Bedrock AgentCore Gateway oferece uma ponte entre os padrões de autenticação suportados nativamente pelo gateway e os requisitos de autenticação de APIs de ferramentas legadas que ainda não migraram para padrões modernos. Como demonstrado, o interceptor valida o JWT de entrada, recupera credenciais de sistema do Secrets Manager e constrói o cabeçalho Basic Auth para a ferramenta de destino — sem modificar os esquemas das ferramentas nem a implementação do agente.

    É importante reforçar: essa abordagem é um padrão de integração temporário, não uma arquitetura-alvo. Ela introduz uma credencial que precisa ser sincronizada entre o Secrets Manager e o repositório de identidades da ferramenta (como o Active Directory), adicionando sobrecarga operacional para rotação, detecção de desvios e gerenciamento de ciclo de vida. O caminho recomendado é modernizar a ferramenta de destino para aceitar OAuth 2.0, SAML ou OpenID Connect, eliminando completamente as credenciais armazenadas. Até que essa modernização seja concluída, o interceptor isola o tratamento de credenciais do runtime do agente, ajudando a garantir que o agente — um sistema não determinístico influenciado por prompts de usuários — não tenha acesso a segredos de autenticação.

    Fonte

    Implement custom authentication for tools integration using request Lambda interceptor in AgentCore Gateway (https://aws.amazon.com/blogs/security/implement-custom-authentication-for-tools-integration-using-request-lambda-interceptor-in-agentcore-gateway/)

  • Security Hub Extended adiciona Segurança da Cadeia de Suprimentos como sua décima categoria

    Security Hub Extended chega à décima categoria

    Desde fevereiro, a AWS expandiu o Security Hub Extended de 14 parceiros curados em 9 categorias para 23 parceiros distribuídos em 10 categorias. A novidade mais recente — e a mais pedida pelos clientes — é a chegada da categoria de Segurança da Cadeia de Suprimentos (Supply Chain Security), com Chainguard e Socket como os parceiros curados.

    Na Black Hat deste mês, 14 desses parceiros estiveram presentes no estande da Amazon Web Services (AWS) com demonstrações ao vivo. Quatro deles realizaram apresentações no palco e dez foram destaque na transmissão ao vivo do SecurityLive. O evento também contou com uma recepção exclusiva para parceiros, reunindo lideranças da AWS com executivos dessas empresas para alinhar os próximos passos.

    Por que Supply Chain Security virou prioridade de boardroom

    O risco na cadeia de suprimentos de software deixou de ser uma preocupação restrita às equipes de segurança e passou a ser pauta de diretoria. Três casos recentes ilustram bem a dimensão do problema:

    • SolarWinds mostrou o que acontece quando um sistema de build é comprometido.
    • Log4j expôs o impacto global que uma única vulnerabilidade em dependência transitiva pode causar.
    • xz utils revelou a paciência de um ataque de comprometimento de mantenedor executado ao longo de anos.

    Cada um desses incidentes demonstrou uma dimensão diferente do mesmo problema — e o ritmo está se acelerando. Atacantes sabem que uma rota rápida para dentro de uma empresa é justamente pelos pacotes open source que ela confia sem perceber.

    Na Black Hat, praticamente todos os clientes com quem a AWS conversou tinham esse risco no seu registro de ameaças. A maioria, porém, ainda não havia operacionalizado uma solução — porque fazer isso significava uma implantação isolada, um novo contrato, um novo console e trabalho de integração que a equipe de segurança simplesmente não conseguia priorizar. É exatamente essa fricção que o Security Hub Extended se propõe a eliminar.

    Chainguard e Socket: os parceiros curados para Supply Chain

    A nova categoria de Supply Chain Security segue o mesmo modelo já consolidado no Security Hub Extended: precificação por uso, uma única fatura, sem compromisso de longo prazo obrigatório. Para empresas que preferem o processo de compras tradicional, também estão disponíveis as Private Offers do Security Hub Extended — acordos com prazo definido, descontos maiores, possibilidade de consolidar gastos com múltiplos parceiros em uma única fatura AWS e opções de pagamento mensal ou anual.

    O que o Chainguard faz

    O Chainguard oferece dependências open source reconstruídas a partir do código-fonte em um processo de build verificado e reforçado. O resultado é que o que entra no seu ambiente é resistente a malware e tem proveniência rastreável. A pesquisa da própria empresa indica que reconstruir a partir do código-fonte teria bloqueado 98% dos pacotes maliciosos conhecidos antes de chegarem à produção. Se a origem não pode ser verificada, o pacote simplesmente não aparece no repositório do Chainguard — funcionando como um filtro entre o registro público e os desenvolvedores.

    O que o Socket faz

    O Socket analisa o comportamento real dos pacotes open source para bloquear dependências maliciosas no momento da instalação — não depois que uma Vulnerabilidade e Exposição Comum (CVE) é publicada dias ou semanas depois. No instante em que um pacote tenta entrar no ambiente, o Socket o sinaliza com base no que ele faz, não no que um banco de dados diz sobre ele. Além disso, a análise de alcançabilidade (reachability analysis) da ferramenta indica quais vulnerabilidades são de fato exploráveis a partir do seu código, em vez de afogar a equipe em alertas irrelevantes. A cobrança é feita pelos pacotes distintos verificados, não pela quantidade de vezes que os builds são executados.

    Por que as duas ferramentas funcionam juntas

    Juntos, Chainguard e Socket respondem às duas perguntas que realmente importam:

    • Posso confiar no que estou baixando?
    • Consigo bloquear componentes maliciosos antes que sejam incorporados às minhas aplicações?

    O Chainguard protege a base sobre a qual o código é construído. O Socket protege os pacotes que são incorporados a essa base. Ambos atuam independentemente de onde você faz o deploy — em múltiplas nuvens ou on-premises.

    Ao ativar os dois pelo Security Hub Extended, os alertas gerados fluem para o Security Hub no formato OCSF (Estrutura Aberta de Esquema de Cibersegurança — Open Cybersecurity Schema Framework), ao lado de todos os outros sinais. Assim, um risco na cadeia de suprimentos é correlacionado e priorizado junto com os alertas de endpoint, identidade e nuvem — e encaminhado para as ferramentas downstream já integradas ao pipeline existente.

    23 parceiros, 10 categorias — construídos a partir do que os clientes pediram

    Cada parceiro do Security Hub Extended está lá porque clientes sinalizaram que precisavam daquela capacidade e que aquela solução específica já funcionava para eles. As categorias evoluem conforme o cenário de ameaças muda, e novos parceiros entram quando os próprios clientes os indicam como referência.

    O conjunto completo hoje abrange: endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA, operações de segurança e, agora, cadeia de suprimentos. Os 23 parceiros curados são: 7AI, Britive, Chainguard, CrowdStrike, Cyera, Island, LayerX, Native Security, Noma, Okta, Oligo, Opti, Palo Alto Networks, Proofpoint, SailPoint, SentinelOne, Socket, Splunk, Sublime, Upwind, Varonis, Zenity e Zscaler.

    O que vem a seguir

    O foco atual da AWS é aprofundar as integrações e reduzir a fricção de ativação para que essas soluções trabalhem de forma conjunta, e não isolada. A integração mais prioritária é a correlação entre parceiros — transformar sinais de uma solução de endpoint, uma de identidade e uma de nuvem em uma única exposição e um único caminho de ataque, em vez de três alertas desconexos. Em paralelo, a AWS está reduzindo drasticamente o tempo entre a assinatura e a geração de valor: o objetivo é que clientes passem de “acabei de assinar” para “já estou vendo resultados” em horas, não semanas.

    Mais novidades devem ser anunciadas antes do re:Invent.

    Como começar

    Se você já roda open source em produção e ainda não tem visibilidade sobre a cadeia de suprimentos, esse é o ponto de partida. É possível ativar o Chainguard e o Socket diretamente pelo console do Security Hub. Para quem gerencia múltiplos relacionamentos com fornecedores de segurança e quer entender como seria a consolidação com o Security Hub Extended, o caminho é conversar com o time de contas da AWS. A precificação de todos os parceiros está publicada na página de preços — sem necessidade de contato comercial prévio. E para quem já usa o Security Hub para gerenciamento de postura e detecção de ameaças, o plano Extended está disponível no mesmo console.

    Fonte

    Security Hub Extended adds Supply Chain Security as its tenth category (https://aws.amazon.com/blogs/security/security-hub-extended-adds-supply-chain-security-as-its-tenth-category/)

  • Classificação de documentos com múltiplos agentes de IA usando Amazon Bedrock

    O problema: classificar documentos similares com precisão

    Empresas de seguros lidam diariamente com milhares de documentos — apólices, declarações juramentadas, endossos e formulários regulatórios. Classificar tudo isso corretamente é crítico para conformidade, processamento de sinistros e atendimento ao cliente. O problema é que documentos distintos muitas vezes compartilham terminologia parecida: um endosso de apólice e uma declaração regulatória podem usar linguagem semelhante, mas tratá-los de forma errada pode gerar violações de conformidade ou atrasos no processamento.

    Abordagens manuais são lentas e sujeitas a erros. Sistemas automatizados tradicionais, por sua vez, têm dificuldade com documentos que se parecem, mas têm propósitos diferentes. É justamente para resolver esse desafio que a AWS publicou um guia técnico demonstrando como construir um sistema de classificação baseado em múltiplos agentes de IA usando o Amazon Bedrock.

    A solução: arquitetura com múltiplos agentes especializados

    A solução proposta orquestra três agentes de IA especializados, cada um responsável por um aspecto diferente da análise de documentos. A coordenação entre eles é feita por meio do Strands Agents SDK, que permite tratar agentes como ferramentas chamáveis por um orquestrador central.

    A escolha pelo Strands Agents SDK se justifica porque ele implementa o padrão de agentes como ferramentas: o agente orquestrador pode invocar os agentes especialistas diretamente, sem precisar de código de orquestração personalizado. Isso traz vantagens claras:

    • Modularidade: cada agente pode ser desenvolvido, testado e melhorado de forma independente.
    • Transparência: cada agente fornece o raciocínio por trás de suas decisões, criando uma trilha de auditoria.
    • Flexibilidade: novos agentes podem ser adicionados sem reestruturar o sistema.
    • Confiabilidade: o orquestrador cuida da coordenação, tratamento de erros e síntese dos resultados.

    Agente de Análise de Documentos

    Este agente usa o Claude Haiku 4.5 da Anthropic no Amazon Bedrock para raciocínio textual avançado e interpretação de linguagem jurídica. O Claude se destaca em entender documentos complexos, extrair informações-chave e identificar padrões sutis no texto que indicam o tipo do documento.

    Agente de Busca por Similaridade Vetorial

    Este agente usa o Amazon Titan Multimodal Embeddings G1 para converter documentos em representações vetoriais de alta dimensionalidade, focando nas características visuais e estruturais — como layouts de formulários, estruturas de tabelas e convenções de formatação. Para a busca por similaridade, o agente utiliza o FAISS (Busca por Similaridade de IA do Facebook), que permite comparação rápida contra modelos de documentos conhecidos armazenados em um banco de dados vetorial.

    Agente de Validação (Orquestrador)

    No centro da arquitetura está o Agente de Validação, que atua como orquestrador. Ele invoca os dois agentes especialistas, compara os resultados, identifica concordâncias e discordâncias, e gera uma classificação final com uma pontuação de confiança associada. Quando a confiança cai abaixo de um limite definido, o sistema aciona automaticamente a revisão humana, evitando que classificações incertas se propaguem para os sistemas seguintes.

    Pré-requisitos

    Para implementar a solução, são necessários:

    Atenção: o uso dos serviços AWS pode gerar custos. Revise a tabela de preços do Amazon Bedrock antes de começar e siga as instruções de limpeza ao final para evitar cobranças contínuas.

    Implementando o sistema passo a passo

    Passo 1: Configurar os modelos de fundação

    O primeiro passo é configurar o acesso ao Claude via perfil de inferência do Amazon Bedrock. Isso garante desempenho consistente e disponibilidade entre regiões:

    def create_bedrock_model(
        model_id: str = "anthropic.claude-haiku-4-5-20251001-v1:0",
        # temperature: float = 0.1,
        max_tokens: int = 4096
    ) -> BedrockModel:
        """Create a configured Bedrock model instance."""
        return BedrockModel(
            model_id=model_id,
            region_name="us-east-1",
            temperature=temperature,
            max_tokens=max_tokens
        )

    Dica: para menor latência e maior disponibilidade, é possível usar um perfil de inferência entre regiões adicionando um prefixo geográfico (us., eu. ou ap.) ao ID do modelo.

    Passo 2: Criar o Agente de Análise de Documentos

    Este agente usa saída estruturada para retornar resultados de classificação consistentes e interpretáveis por máquina:

    class TextualAnalysisOutput(BaseModel):
        """Structured output for document text analysis."""
        classification: str = Field(description="Document category: POLICY, AFFIDAVIT, or MISCELLANEOUS")
        confidence: float = Field(description="Classification confidence score from 0.0 to 1.0")
        reasoning: str = Field(description="Explanation of textual features that led to this classification")
    
    @tool
    def analyze_document_text(document_text: str) -> str:
        """Analyze document text content to classify the insurance document."""
        TEXTUAL_ANALYSIS_PROMPT = """You are a Document Analysis Specialist for insurance documents.
        Analyze the provided document text and classify it into exactly one category:
        - POLICY: Insurance policies, endorsements, declarations, coverage documents
        - AFFIDAVIT: Sworn statements, notarized documents, legal declarations, regulatory filings
        - MISCELLANEOUS: Any document that doesn't clearly fit the above categories
        Provide your classification with a confidence score (0.0-1.0) and detailed reasoning explaining what textual features led to your decision."""
    
        text_agent = Agent(
            model=create_bedrock_model(),
            system_prompt=TEXTUAL_ANALYSIS_PROMPT,
            conversation_manager=NullConversationManager(),
        )
        result = text_agent(
            f"Classify this document:\n\n{document_text}",
            structured_output_model=TextualAnalysisOutput,
        )
        return str(result.structured_output)

    Passo 3: Construir o Agente de Busca por Similaridade Vetorial

    Este agente carrega um índice FAISS pré-treinado e analisa as características visuais do documento:

    # Load FAISS index once at module level.
    # allow_dangerous_deserialization=True is required because FAISS uses pickle internally;
    # safe here since we created the index ourselves from our own training documents.
    db = FAISS.load_local("hybrid_docs.vdb", embeddings=embeddings, allow_dangerous_deserialization=True)
    
    VECTOR_ANALYSIS_PROMPT = """You are a Vector Similarity Search Specialist.
    Analyze the similarity search results and determine the document classification.
    Consider the confidence scores and consistency of matches across pages."""
    
    @tool
    def analyze_document_vectors(pdf_path: str) -> str:
        """Classify document using vector similarity search with agentic reasoning."""
        base64_pages = pdf_to_base64(pdf_path)
        first_embedding = create_multimodal_embedding(image_base64=base64_pages[0])
        results = db.similarity_search_by_vector(embedding=first_embedding, k=3)
        labels = [r.metadata["label"] for r in results]
        classification = Counter(labels).most_common(1)[0][0]
        confidence = labels.count(classification) / len(labels)
    
        vector_agent = Agent(
            model=create_bedrock_model(),
            system_prompt=VECTOR_ANALYSIS_PROMPT,
            conversation_manager=NullConversationManager(),
        )
        result = vector_agent(
            f"Vector search results for {pdf_path}:\n"
            f"Top match: {classification} (confidence: {confidence:.2f})\n"
            f"All matches: {labels}\n"
            f"Provide final classification with reasoning.",
            structured_output_model=VectorAnalysisOutput,
        )
        return str(result.structured_output)

    Passo 4: Implementar o Agente de Validação

    O Agente de Validação coordena os especialistas usando o padrão de agentes como ferramentas:

    class OrchestratorOutput(BaseModel):
        """Structured output for the validation orchestrator."""
        textual_analysis: str = Field(description="Textual agent classification: POLICY, AFFIDAVIT, or MISCELLANEOUS")
        textual_confidence: float = Field(description="Textual agent confidence 0.0-1.0")
        vector_analysis: str = Field(description="Vector agent classification: POLICY, AFFIDAVIT, or MISCELLANEOUS")
        vector_confidence: float = Field(description="Vector agent confidence 0.0-1.0")
        final_classification: str = Field(description="Final validated classification")
        confidence: float = Field(description="Overall confidence score")
        requires_human_review: bool = Field(description="Whether edge case needs human review")
        decision_logic: str = Field(description="Brief explanation of decision")
        justification: str = Field(description="Detailed reasoning from both specialists")
    
    class MultiAgentDocumentClassifier:
        def __init__(self, model=None):
            self.model = model or create_bedrock_model()
            self.orchestrator = Agent(
                model=self.model,
                tools=[analyze_document_text, analyze_document_vectors],
                system_prompt="""You are a Document Classification Orchestrator.
                Your workflow:
                1. Use analyze_document_text for textual analysis
                2. Use analyze_document_vectors for visual similarity analysis
                3. Synthesize both into a final classification
                Reasoning guidelines:
                - Both agree → high confidence (0.85-0.95)
                - Disagree → textual is more reliable for content-rich docs, vector for visually distinctive formats
                - Very short text (<50 chars) or low textual confidence (<0.3) → defer to vector analysis
                - Endorsements are POLICY documents
                - Flag for human review when evidence is contradictory
                Always use both tools before deciding."""
            )

    Passo 5: Classificar documentos

    Com todos os componentes no lugar, o MultiAgentDocumentClassifier processa um documento de ponta a ponta da seguinte forma:

    # Method of MultiAgentDocumentClassifier
    def classify_document(self, pdf_path: str) -> OrchestratorOutput:
        """Classify a document using multi-agent orchestration."""
        filename = os.path.basename(pdf_path)
        text_content = extract_pdf_text(pdf_path, max_chars=3000)
        query = f"""Classify this insurance document: {filename}
        Document text content (first 3000 characters):
        {text_content}
        Document file path for vector analysis: {pdf_path}
        Use both analyze_document_text and analyze_document_vectors, then synthesize."""
        result = self.orchestrator(query, structured_output_model=OrchestratorOutput)
        return result.structured_output

    Para usar o classificador:

    classifier = MultiAgentDocumentClassifier()
    result = classifier.classify_document("documents/sample_policy.pdf")
    print(f"Classification: {result.final_classification}")
    print(f"Confidence: {result.confidence:.2f}")
    print(f"Reasoning: {result.justification}")

    Comparação de desempenho: por que múltiplos agentes?

    A AWS comparou o sistema multi-agente com três abordagens comuns. O objetivo era identificar a abordagem mais simples que atendesse aos requisitos de precisão para cargas de trabalho sensíveis à conformidade:

    • Amazon Textract + palavras-chave: 25% de precisão, ~2,88s por documento — baixo custo e complexidade, mas ineficaz para documentos com terminologia sobreposta.
    • Amazon Comprehend + entidades: 25% de precisão, ~3,26s — mesma limitação da abordagem anterior.
    • Amazon Bedrock Data Automation (BDA): 70% de precisão, ~25,7s — desempenho significativamente melhor, mas ainda classificou errado quase 1 em cada 3 documentos.
    • Sistema multi-agente: 100% de precisão, ~23,3s — única abordagem a acertar todas as classes.

    A diferença é mais evidente nos documentos de apólice: textos jurídicos densos com terminologia que se sobrepõe às outras classes. Apenas o sistema multi-agente classificou todos corretamente. Declarações juramentadas seguiram padrão semelhante. Documentos miscelâneos, que têm marcadores estruturais mais distintos, foram classificados corretamente por todas as abordagens.

    Dentro do framework multi-agente, o Claude Haiku 4.5 atingiu a mesma precisão que o Claude Sonnet 4.5, sendo 17% mais rápido — o que o torna a escolha mais adequada para cargas de trabalho em produção, onde velocidade e custo-benefício são prioridades.

    Importante: os testes foram realizados com um conjunto limitado de 20 documentos em 3 classes. A precisão em produção pode variar com conjuntos maiores e mais diversificados.

    Salvaguardas para produção

    Para implantações em produção com documentos sensíveis, a AWS recomenda o uso do Amazon Bedrock Guardrails, que oferece filtragem de conteúdo e controles de segurança para as interações com os modelos. As políticas configuráveis incluem tópicos negados, filtros de conteúdo, filtros de palavras e redação de informações sensíveis.

    As boas práticas recomendadas para esse tipo de pipeline incluem:

    • Aplicar filtros de redação de Informações de Identificação Pessoal (PII) para evitar que dados dos segurados se propaguem para os logs de classificação.
    • Configurar políticas de negação de tópicos para restringir os agentes ao escopo de classificação.
    • Ativar o registro de invocações de modelos do Amazon Bedrock para capturar a cadeia completa de requisição-resposta, incluindo eventos de intervenção do Guardrails, para fins de auditoria.

    O flag requires_human_review gerado pelo Agente de Validação aciona o escalonamento automático quando a confiança cai abaixo de um limite definido, garantindo que classificações incertas cheguem a um revisor humano em vez de se propagarem automaticamente.

    Limpeza dos recursos

    Para evitar cobranças futuras, remova os recursos criados durante a implementação:

    • Exclua os arquivos do banco de dados vetorial FAISS (hybrid_docs.vdb) do ambiente local.
    • Remova os documentos PDF de teste utilizados na classificação.
    • Se os documentos de treinamento foram armazenados no Amazon Simple Storage Service (Amazon S3), exclua o bucket e seu conteúdo.
    • Limpe os logs do Amazon CloudWatch gerados durante os testes.

    Instruções detalhadas de limpeza e scripts estão disponíveis na seção de cleanup do repositório GitHub da solução.

    Conclusão

    O artigo da AWS demonstra como a combinação de múltiplos agentes especializados — análise textual com Claude Haiku 4.5, análise visual com Amazon Titan Multimodal Embeddings e validação cruzada com um agente orquestrador — pode superar significativamente abordagens tradicionais de classificação de documentos.

    A arquitetura é modular, auditável e extensível: é possível começar implementando apenas o Agente de Análise de Documentos com seus próprios tipos de documentos e adicionar o Agente de Busca Vetorial posteriormente para melhorar a precisão em documentos visualmente distintos.

    Para explorar a implementação completa, acesse o repositório GitHub com o código da solução. Também vale conferir a lista de modelos de fundação disponíveis no Amazon Bedrock, a documentação do Strands Agents SDK e os posts relacionados sobre processamento inteligente de documentos e arquiteturas multi-agente.

    Fonte

    Implement vector-prompt document classification using Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/implement-vector-prompt-document-classification-using-amazon-bedrock/)

  • Como personalizar o chat embarcado do Amazon Quick na sua aplicação

    Por que o chat padrão cria uma experiência fragmentada

    O Amazon Quick oferece uma interface de chat com IA conversacional que pode ser embarcada diretamente em aplicações web. Com ela, os usuários conseguem explorar dados, fazer perguntas e obter respostas sem precisar sair da plataforma onde estão trabalhando.

    O problema é que, na configuração padrão, esse chat chega com visual genérico — paleta de cores diferente, branding próprio do Quick e uma aparência que destoa do restante da aplicação. O resultado é uma experiência fragmentada: o usuário percebe que aquele componente foi “colado” ali, e não que faz parte do produto. Para resolver isso, o Amazon Quick disponibiliza recursos de personalização em duas frentes: identidade visual e tom de comunicação.

    As duas dimensões da personalização

    Antes de entrar nas configurações, vale entender o que pode ser ajustado:

    • Identidade visual: o chat deve respeitar a paleta de cores, tipografia e layout da organização.
    • Tom de comunicação: além do visual, as respostas do assistente precisam refletir a personalidade e o contexto da empresa — não basta parecer bonito se o chat responde de forma genérica.

    Para ilustrar as configurações, a AWS usa como exemplo um assistente de análise financeira embarcado em um painel de performance financeira.

    Personalizando a identidade visual

    Como o chat é renderizado dentro de um iframe, não é possível estilizar seus elementos internos diretamente com CSS. A abordagem é trabalhar em dois níveis: estilizar o contêiner que envolve o iframe e usar as opções do SDK para remover elementos de branding padrão que conflitem com o design da aplicação.

    Configuração do frameOptions

    O parâmetro frameOptions controla como o iframe se comporta dentro do contêiner. Veja o exemplo de configuração:

    import { createEmbeddingContext } from 'amazon-quicksight-embedding-sdk';
    
    const embeddingContext = await createEmbeddingContext();
    
    const frameOptions = {
      url: chatEmbedUrl,
      container: document.getElementById('chat-container'),
      height: '100%',
      width: '100%',
      // Apply a custom CSS class directly to the iframe element.
      // Use this for border-radius, positioning, or z-index adjustments
      // to match your application's component design.
      className: 'anycompany-chat-iframe',
      // Display a loading placeholder while the chat content loads,
      // preventing a blank white rectangle during initialization.
      withIframePlaceholder: true,
      // Enable clipboard access so users can copy responses
      // or paste content into the chat input.
      framePermissions: {
        clipboardRead: true,
        clipboardWrite: true,
      },
    };

    CSS do contêiner e layout

    No exemplo do painel financeiro, o chat aparece como um painel lateral que desliza pela direita da tela. O CSS abaixo mostra como estilizar esse contêiner e aplicar a identidade visual da marca:

    /* Position the chat as a fixed side panel */
    .chat-side-panel {
      position: fixed;
      top: 0;
      right: 0;
      bottom: 0;
      width: 400px;
      z-index: 997;
      box-shadow: -4px 0 20px rgba(0, 0, 0, 0.15);
      animation: slideInRight 0.3s ease-out;
    }
    
    /* Brand-colored header matching the dashboard's gradient */
    .chat-panel-header {
      background: linear-gradient(135deg, #667eea, #764ba2);
      color: white;
      padding: 12px 16px;
    }
    
    /* Target the iframe via the custom className from frameOptions */
    .anycompany-chat-iframe {
      border-radius: 0 0 12px 12px;
    }
    
    /* Responsive: full-width on mobile */
    @media (max-width: 900px) {
      .chat-side-panel {
        width: 100%;
      }
    }

    Removendo o branding padrão

    Por padrão, o chat embarcado exibe a atribuição de marca do Amazon Quick e um link de política de uso no rodapé. Para uma experiência totalmente integrada à identidade da aplicação, esses elementos podem ser removidos via contentOptions:

    const contentOptions = {
      footerOptions: {
        showBrandAttribution: false,
        showUsagePolicy: false,
      },
    };

    Com o CSS do contêiner aplicado, a classe personalizada no iframe e o branding padrão removido, o chat passa a se comportar como uma extensão natural do painel — mesma paleta, rodapé limpo e aparência consistente com o restante da aplicação.

    A tabela abaixo resume as principais opções de personalização visual disponíveis:

    • className: classe CSS aplicada ao iframe (border-radius, sombras, z-index)
    • width / height: dimensões do iframe (use "100%" para layouts responsivos)
    • withIframePlaceholder: exibe um spinner de carregamento enquanto o conteúdo é inicializado
    • footerOptions.showBrandAttribution: exibe ou oculta o texto “Powered by”
    • footerOptions.showUsagePolicy: exibe ou oculta o link de política de uso
    • CSS do contêiner: posicionamento do painel, bordas, sombras e estilo do cabeçalho

    Configurando a persona e o tom do assistente

    Visual alinhado é metade do caminho. A outra metade é garantir que as respostas do chat reflitam o contexto e a linguagem da organização. Sem configuração de persona, o assistente tende a responder de forma genérica e descontextualizada.

    Por exemplo, no painel financeiro, a pergunta “Qual foi nossa receita no último trimestre?” produziria uma resposta assim sem personalização:

    “Receita é uma medida de renda gerada pelas operações do negócio. Para encontrar a receita da sua empresa no último trimestre, você normalmente consultaria seus demonstrativos financeiros ou sistema contábil. A receita pode ser detalhada por linha de produto, região ou período de tempo.”

    Essa resposta não tem contexto específico sobre a organização e usa um tom que não corresponde à forma como uma equipe de finanças se comunica. Com o agente de chat personalizado do Quick, é possível definir uma persona que controla o tom, o estilo de linguagem e o comportamento das respostas. A configuração acontece em dois lugares: nas opções de conteúdo do SDK e nas instruções de persona definidas no console do Quick.

    Opções de conteúdo do SDK

    const contentOptions = {
      // Lock to your custom finance agent --- removes the generic agent selector
      // so users only interact with your purpose-built assistant
      agentOptions: {
        fixedAgentId: 'your-finance-agent-id',
      },
      promptOptions: {
        // Auto-send a contextual greeting on first load.
        // The assistant proactively shares relevant insights
        // rather than waiting passively for a question.
        initialPrompt: 'What are the key financial highlights this quarter?',
        // Hide the user message bubble for the initial prompt.
        // This makes it appear as if the assistant initiated the conversation,
        // creating a more natural "advisor" experience.
        showInitialPromptMessage: false,
        // Enable file attachments --- users can upload spreadsheets
        // or reports for the assistant to analyze
        allowFileAttachments: true,
        // Show web search for supplementary market research
        showWebSearch: true,
        // Show chat history so users can resume prior conversations
        showChatHistory: true,
        // Display knowledge boundary indicator --- builds trust by showing
        // users what data sources the assistant can access
        showAgentKnowledgeBoundary: true,
      },
    };

    Instruções de persona do agente (console do Quick)

    Ao configurar o agente de chat personalizado no console do Amazon Quick, são definidas as instruções de persona que moldam como o agente responde. O bloco abaixo exemplifica como essas instruções podem ser estruturadas:

    You are the AnyCompany Finance Assistant, an AI embedded in AnyCompany's Finance Performance Dashboard.
    
    ## Your Role
    You help executive leadership, finance teams, and business leads explore financial data, understand performance trends, and take action on insights --- all without leaving the dashboard.
    
    ## Response Style
    - Lead with the direct answer and the key number
    - Provide context and comparison to prior period
    - Cite the source document when referencing qualitative information
    - Use bullet points for multi-part answers
    - Keep responses concise --- executives want the insight, not the explanation
    
    ## Boundaries
    - Only discuss AnyCompany financial data and business context
    - Do not speculate about future performance beyond stated targets
    - For questions outside your knowledge, direct users to finance@anycompany.com

    Com o agente financeiro personalizado configurado, a mesma pergunta sobre receita passa a produzir uma resposta direta, orientada a dados e contextualizada:

    “A receita do Q2 2025 foi de US$ 8,89M, alta de 12,5% em relação ao Q2 2024 (US$ 7,05M). O crescimento foi impulsionado por momentum consistente mês a mês em todas as regiões: Abril: US$ 2,89M / Maio: US$ 2,95M / Junho: US$ 3,05M. A América do Norte liderou com crescimento de 15%, seguida pela EMEA com 9%.”

    As principais opções de personalização de persona disponíveis via SDK são:

    • fixedAgentId: bloqueia o agente personalizado, removendo o seletor genérico de agentes
    • initialPrompt: define a abertura conversacional — proativa ou reativa
    • showInitialPromptMessage: false: faz o assistente parecer o iniciador da conversa, criando uma experiência de “consultor”
    • showAgentKnowledgeBoundary: indica ao usuário quais fontes de dados o assistente consegue acessar
    • Instruções de persona do agente: definem tom, vocabulário, estrutura de resposta e limites de atuação

    Interação programática com sendPrompt()

    Além da personalização visual e de persona, o SDK disponibiliza o método sendPrompt(), que permite à aplicação disparar perguntas contextuais a partir de interações na interface. Por exemplo: quando o usuário seleciona uma métrica em um gráfico, a aplicação pode enviar automaticamente uma pergunta relacionada ao assistente, conectando os visuais do painel com a interface conversacional.

    // Store the experience reference after embedding
    const chatExperience = await embeddingContext.embedQuickChat(
      frameOptions,
      contentOptions
    );
    
    // When a user selects a revenue metric card in your dashboard:
    chatExperience.sendPrompt(
      'Explain the revenue trend this quarter and what is driving it.'
    );

    No exemplo do painel financeiro, botões de ação rápida no cabeçalho do painel de chat implementam esse padrão:

    const askAboutMetric = (metricName) => {
      chatExperience.sendPrompt(
        `Explain the trend for ${metricName} and what's driving it.`
      );
    };
    
    // Quick-action buttons
    const metrics = [
      { metric: 'revenue', label: 'Revenue' },
      { metric: 'profit margin', label: 'Margins' },
      { metric: 'expenses', label: 'Expenses' }
    ];
    
    const container = document.getElementById('quick-actions');
    metrics.forEach(({ metric, label }) => {
      const button = document.createElement('button');
      button.type = 'button';
      button.textContent = label;
      button.setAttribute('aria-label', `Ask about ${metric}`);
      button.addEventListener('click', () => askAboutMetric(metric));
      container.appendChild(button);
    });

    Por onde começar

    Para colocar essas personalizações em prática, o ponto de partida é embutir o chat do Quick na sua aplicação. Em seguida, aplique a paleta de cores, tipografia e layout da marca por meio do CSS do contêiner e das opções de frame do SDK, para que o chat se comporte como um componente nativo. Por fim, crie um agente de chat personalizado no console do Quick com instruções de persona que definam o domínio de conhecimento e o estilo de comunicação desejado. A documentação oficial de personalizações do Amazon Quick traz todos os detalhes necessários para cada etapa.

    Fonte

    Customize Amazon Quick embedded chat into your application (https://aws.amazon.com/blogs/machine-learning/customize-amazon-quick-embedded-chat-into-your-application/)

  • Como melhorar a precisão na busca de contratos com filtros automáticos no Amazon Bedrock

    O desafio de buscar contratos com IA

    Empresas de setores como entretenimento e mídia gerenciam milhares de contratos jurídicos ao mesmo tempo — acordos de licenciamento, restrições geográficas, cláusulas de renovação, obrigações de conformidade. Hoje, grande parte desse trabalho ainda é feito manualmente: lento, caro e difícil de escalar.

    Para endereçar esse problema, a AWS publicou um estudo sobre a solução AIDA (AI-Driven Annotation), que transforma contratos não estruturados em inteligência pesquisável e acionável. A AIDA permite que usuários façam perguntas em linguagem natural sobre grandes repositórios de contratos — mas entregar respostas precisas exige muito mais do que uma busca semântica simples.

    Documentos jurídicos são altamente contextuais. Sistemas baseados em RAG (Geração Aumentada por Recuperação) podem retornar mais conteúdo do que um modelo de linguagem consegue processar com eficiência. Sem controle cuidadoso sobre quais trechos são recuperados — e sem contexto suficiente no nível do documento — cláusulas importantes correm o risco de serem ignoradas ou interpretadas de forma errada.

    Visão geral da arquitetura

    A AIDA é construída sobre uma arquitetura RAG usando o Amazon Bedrock Knowledge Bases. Toda a transmissão de dados entre os componentes é criptografada em trânsito via HTTPS/TLS 1.2+, incluindo uploads de documentos, chamadas a modelos de embeddings, consultas ao banco vetorial e entrega de respostas. Para dados armazenados no Amazon Bedrock, aplica-se o modelo de responsabilidade compartilhada da AWS.

    Imagem original — fonte: Aws

    O fluxo de implementação segue nove etapas bem definidas, divididas em dois grandes blocos: ingestão de dados e interação do usuário.

    Fluxo de ingestão de dados

    Etapa 1 — Ingestão de documentos e configuração de metadados: Os contratos são sincronizados no Amazon Bedrock Knowledge Bases junto com arquivos de metadados estruturados. Esses metadados devem conter atributos-chave como partes envolvidas, data de vigência, data de encerramento, jurisdição e outros campos relevantes para habilitar filtragens poderosas nas etapas seguintes.

    Etapa 2 — Implementação do mecanismo de chunking: A base de conhecimento é configurada com um mecanismo sofisticado de divisão de documentos em segmentos semanticamente significativos, otimizados para recuperação. Cada segmento precisa ter contexto suficiente para ser útil, mas ser conciso o bastante para processamento eficiente. Os metadados fornecidos na ingestão são essenciais para a filtragem implícita — o que diferencia essa arquitetura de implementações RAG padrão.

    Etapa 3 — Armazenamento no banco vetorial: Os segmentos processados são convertidos em embeddings vetoriais e armazenados em um banco vetorial. As opções disponíveis incluem o Amazon OpenSearch Service ou o Amazon S3 Vectors — ambos devem ser configurados com criptografia em repouso habilitada. O acesso à base de conhecimento é governado por políticas do AWS Identity and Access Management (IAM), com logging habilitado no Amazon CloudWatch para manter trilhas de auditoria para fins de conformidade.

    Fluxo de interação do usuário

    Etapa 4 — Geração de embeddings da consulta: Quando um usuário envia uma pergunta, a AIDA usa o Amazon Bedrock Guardrails para proteger contra injeções de prompt e vazamento de dados. Em seguida, a consulta é convertida em embeddings usando os modelos de embedding do Amazon Bedrock, permitindo comparação semântica com os segmentos armazenados.

    Etapa 5 — Filtragem implícita e explícita: Antes de executar a busca semântica, o sistema aplica dois mecanismos de filtragem — um ponto central desta arquitetura. A filtragem implícita aplica automaticamente condições baseadas em metadados (como faixas de data de vigência ou partes específicas) antes da busca vetorial. Essa abordagem em dois estágios primeiro restringe o espaço de busca por restrições de metadados, depois aplica correspondência semântica dentro desse subconjunto filtrado.

    Etapa 6 — Busca semântica e recuperação de documentos: O banco vetorial recupera os segmentos mais relevantes com base em pontuações de similaridade semântica, tipicamente usando métricas de similaridade de cosseno para identificar as correspondências mais próximas à consulta do usuário.

    Etapa 7 — Augmentação do prompt: Os segmentos recuperados são usados para enriquecer a consulta original em um prompt cuidadosamente formatado, combinando a pergunta do usuário com os trechos de contrato relevantes e o contexto de metadados.

    Etapa 8 — Geração de resposta pelo LLM: O prompt enriquecido é enviado a um LLM (Modelo de Linguagem de Grande Escala) via Amazon Bedrock, que gera uma resposta contextualmente precisa, fundamentada nos documentos reais — e não apenas no conhecimento de treinamento do modelo. O Amazon Bedrock Guardrails também é aplicado para filtragem de conteúdo, proteção de informações sensíveis (PII) e controles de segurança de prompt.

    Etapa 9 — Entrega da resposta com atribuição de fonte: A resposta final é retornada ao usuário pela Retrieve API, garantindo que as respostas sejam rastreáveis até os documentos-fonte específicos. Essa rastreabilidade reduz alucinações — um desafio comum em LLMs — e fornece inteligência contratual verificável.

    O problema do volume de informação no RAG jurídico

    Um dos principais desafios ao desenvolver um sistema RAG para análise de contratos é gerenciar o volume de informação potencialmente relevante. Considere a seguinte pergunta:

    “Por favor, identifique quaisquer acordos de licenciamento expirados regidos pela lei da Califórnia. Como esses acordos se renovam?”

    Essa consulta pode corresponder a centenas de trechos relevantes em múltiplos documentos. O Amazon Bedrock retorna os top-k (máximo 100) segmentos mais relevantes — mas os demais podem conter contexto crítico que ficará de fora. Como resultado, as respostas do LLM podem ser incompletas ou imprecisas.

    Documentos jurídicos são altamente estruturados e dependentes de contexto. Uma cláusula de renovação em um acordo de licenciamento regido pela lei da Califórnia pode funcionar de forma completamente diferente de uma cláusula similar em outra jurisdição. Se a etapa de recuperação não filtrar corretamente por tipo de contrato e lei aplicável, o sistema pode retornar contratos irrelevantes — como NDAs ou acordos de serviço — que até contêm linguagem de expiração ou renovação, mas não respondem à pergunta original.

    É importante destacar que, mesmo com todas essas melhorias de recuperação, interpretações de contratos geradas por IA devem sempre ser revisadas por profissionais jurídicos qualificados antes de serem usadas em decisões de negócio. A AIDA é projetada como uma ferramenta de suporte à decisão, não como substituta da expertise jurídica.

    Filtragem implícita

    A filtragem implícita é uma capacidade do Amazon Bedrock Knowledge Bases que permite filtrar automaticamente os resultados de busca com base em atributos de metadados, sem exigir expressões de filtro explícitas em cada consulta. O mecanismo opera em dois estágios:

    • Estágio 1 — Pré-filtragem por metadados: Antes de executar a busca por similaridade semântica, o sistema aplica condições baseadas em metadados automaticamente. É possível fornecer um arquivo de metadados customizado (até 10 KB por documento) para cada documento na base de conhecimento, contendo atributos como datas de vigência, tipos de documento, partes envolvidas ou campos personalizados relevantes para o caso de uso.
    • Estágio 2 — Busca semântica no subconjunto filtrado: Após restringir o conjunto de documentos pelos filtros de metadados, o sistema executa a busca por similaridade vetorial apenas dentro desse subconjunto. Isso reduz ruído e informações irrelevantes, melhorando a precisão da recuperação.

    Filtragem explícita

    A filtragem explícita é aplicada de forma consistente na camada de aplicação, independentemente da entrada do usuário. Essa abordagem garante que os resultados de busca permaneçam alinhados com políticas de negócio, requisitos de conformidade e restrições organizacionais. Casos de uso comuns incluem:

    • Restrições no nível da aplicação: Limitar resultados com base em regras predefinidas do sistema.
    • Restrições geográficas: Garantir que usuários em determinadas regiões acessem apenas documentos alinhados com regulamentações locais (ex: usuários europeus restritos a contratos da UE).
    • Restrições temporais: Retornar apenas documentos dentro de um período específico (ex: contratos ativos nos últimos dois anos).
    • Classificação e sensibilidade: Restringir resultados a documentos marcados com um nível de confidencialidade exigido.

    Exemplo de filtro explícito utilizado na solução:

    {
      "andAll": [
        {
          "listContains": {
            "key": "region",
            "value": "Germany"
          }
        },
        {
          "stringEquals": {
            "key": "confidentiality_level",
            "value": "Public"
          }
        }
      ]
    }

    Além da filtragem: enriquecimento de segmentos com metadados

    Embora a filtragem implícita e explícita restrinja o conjunto de segmentos candidatos, ela não fornece automaticamente ao LLM o contexto estruturado no nível do documento. Sem esses valores de metadados, o modelo pode gerar respostas incompletas ou menos precisas — especialmente em cenários com alto volume de contratos similares e complexos.

    Para análise de contratos jurídicos, campos de metadados comuns incluem: tipo de contrato, lei aplicável, data de vigência, data de expiração, partes envolvidas, unidade de negócio e nível de confidencialidade.

    Voltando ao exemplo da pergunta sobre acordos de licenciamento expirados regidos pela lei da Califórnia: suponha que um segmento recuperado contenha a seguinte cláusula:

    “Este Acordo será renovado automaticamente por períodos sucessivos de um ano, a menos que qualquer uma das partes forneça aviso por escrito de não renovação com pelo menos 60 dias de antecedência da data de expiração.”

    Se essa cláusula for fornecida ao LLM sem os metadados associados ao documento, o modelo não consegue determinar: se o acordo é um contrato de licenciamento; se é regido pela lei da Califórnia; se já expirou; ou qual é a data real de expiração. Sem esses valores, o modelo pode gerar respostas incompletas ou imprecisas.

    Para resolver essa limitação, a AIDA enriquece os segmentos candidatos com metadados no nível do documento. Em vez de duplicar metadados para cada segmento — o que desperdiçaria tokens de entrada — os segmentos são agrupados por documento e os metadados relevantes são anexados uma única vez. Isso dá a cada segmento um contexto mais rico e ajuda o LLM a raciocinar com mais eficácia.

    Avaliando o impacto da filtragem e do enriquecimento

    Para avaliar o impacto dessas técnicas, a AWS testou a pergunta-guia sobre acordos de licenciamento expirados usando o Contract Understanding Atticus Dataset (CUAD) (acordos de licenciamento e co-branding). Em cada teste, a profundidade de recuperação foi definida como top-k = 15. Quatro configurações progressivamente aprimoradas foram comparadas:

    • RAG base (sem filtros, sem metadados): O sistema recuperou 55 segmentos candidatos potenciais, mas apenas uma fração do contexto relevante chegou aos 15 resultados passados ao modelo. O modelo identificou corretamente um acordo expirado, mas as condições de renovação foram descritas de forma parcial e a resposta careceu de confiança e fundamentação contextual completa.
    • Apenas filtragem explícita: Reduziu o conjunto candidato, mas a precisão não melhorou de forma consistente. Um acordo foi incorretamente classificado como expirado e cláusulas de renovação foram mal interpretadas. A filtragem sozinha restringiu o espaço de busca, mas não forneceu contexto estruturado suficiente para raciocínio preciso.
    • Filtragem implícita e explícita combinadas: Reduziu o número de documentos concorrentes para 20 e melhorou o foco contextual. O modelo identificou o acordo correto, mas hesitou em classificá-lo definitivamente como expirado. Os mecanismos de renovação foram descritos, mas com ressalvas.
    • Filtragem com enriquecimento de metadados: Com os segmentos enriquecidos com metadados como lei aplicável, data de expiração e tipo de contrato, o sistema identificou corretamente apenas o acordo Snap/United como expirado, explicou claramente os termos de renovação e produziu a resposta mais precisa e confiável de todas as configurações.

    A qualidade das melhorias depende diretamente da relevância e adequação dos metadados escolhidos. A filtragem e o enriquecimento funcionam melhor quando as consultas estão alinhadas com os metadados disponíveis. Consultas não relacionadas a esses metadados podem não apresentar os mesmos benefícios — por isso, o design cuidadoso e a seleção criteriosa dos campos de metadados são essenciais.

    Conclusão

    A abordagem descrita pela AWS demonstra como a combinação de filtragem explícita, filtragem implícita e enriquecimento de segmentos com metadados no Amazon Bedrock Knowledge Bases pode melhorar significativamente a precisão de sistemas RAG aplicados à análise de contratos jurídicos. Ao incorporar esses controles diretamente no pipeline de recuperação, a AIDA consegue fornecer aos usuários insights derivados dos contratos que estão autorizados a acessar, preservando o contexto jurídico e de negócio necessário para tomadas de decisão confiantes.

    O resultado é uma abordagem prática e pronta para uso empresarial que reduz o esforço de revisão manual, melhora a qualidade das respostas e ajuda organizações a extrair valor real de seus dados contratuais.

    Para começar, a AWS recomenda consultar a documentação do Amazon Bedrock Knowledge Bases e explorar o Amazon Bedrock no Console de Gerenciamento da AWS.

    Fonte

    Improve contract search accuracy with auto-generated filters in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/improve-contract-search-accuracy-with-auto-generated-filters-in-amazon-bedrock/)

  • AgentCore Payments chega à disponibilidade geral no Amazon Bedrock AgentCore

    O que é o AgentCore Payments?

    A AWS anunciou, em 18 de agosto de 2026, a disponibilidade geral do AgentCore Payments, uma capacidade nativa do Amazon Bedrock AgentCore voltada para agentes de IA que precisam realizar transações financeiras de forma autônoma. Com poucas linhas de código, esses agentes passam a ser capazes de descobrir, acessar e pagar por APIs pagas, servidores MCP e conteúdos sob demanda — sem intervenção humana a cada operação.

    Trata-se de um avanço relevante para equipes que desenvolvem agentes autônomos em produção, pois a solução já vem com os controles de segurança, limites configuráveis e rastreabilidade que ambientes corporativos exigem.

    Principais capacidades

    O AgentCore Payments foi construído com foco em segurança e flexibilidade operacional. Veja o que a funcionalidade oferece:

    • Integração com carteiras digitais: suporte às carteiras Coinbase e Stripe Privy para microtransações, permitindo pagamentos ágeis em baixo valor.
    • Orquestração de pagamentos entre protocolos: o serviço gerencia o fluxo de pagamento independentemente do protocolo utilizado.
    • Limites de pagamento configuráveis na camada de infraestrutura: as equipes podem definir tetos de gasto diretamente na infraestrutura, sem depender da lógica do agente.
    • Observabilidade de ponta a ponta: integração com o AgentCore Observability para rastrear cada transação realizada pelos agentes.

    Novidades na disponibilidade geral

    Com o lançamento em disponibilidade geral, a AWS incluiu um conjunto de recursos adicionais:

    • Quick Create para Coinbase: provisionamento de credenciais Coinbase diretamente pelo console do AgentCore, simplificando a configuração inicial.
    • Coinbase Bazar MCP Server: um servidor MCP curado com endpoints pagos por uso no padrão x402, acessível via gateway do AgentCore.
    • Suporte ao MPP (Machine Payment Protocol — Protocolo de Pagamento entre Máquinas): protocolo voltado especificamente para transações entre sistemas automatizados.
    • Esquema “upto” no protocolo x402: voltado para casos de uso de pagamento por inferência e precificação dinâmica.

    Como começar

    Desenvolvedores podem iniciar a exploração do AgentCore Payments por diferentes caminhos: usando assistentes de código como Claude Code, Kiro e Codex, pela AgentCore CLI ou diretamente pelo AWS Management Console. A AWS disponibilizou um repositório de exemplos para facilitar os primeiros passos — acesse os exemplos no GitHub.

    O serviço está disponível nas regiões listadas na página oficial de regiões do AgentCore. Para detalhes técnicos aprofundados, a documentação do AgentCore Payments e o AWS News Blog são os recursos recomendados. Informações sobre preços estão disponíveis na página de preços do AgentCore.

    Fonte

    AgentCore payments is now generally available in Amazon Bedrock AgentCore (https://aws.amazon.com/about-aws/whats-new/2026/08/bedrock-agentcore-payments-ga/)