Blog

O problema: agentes de IA que ignoram quem está perguntando

Imagine que você construiu um agente de dados que permite a usuários de negócio fazer perguntas em linguagem natural sobre um lakehouse. Você já tem políticas de governança definindo quem pode acessar quais conjuntos de dados. O desafio é fazer o agente respeitar essas regras sem precisar reconstruí-las no código da aplicação.

Quando um usuário faz uma pergunta, o agente mapeia a intenção para os dados e monta uma consulta. O problema está aqui: a ferramenta que executa essa consulta opera sob uma função do AWS Gerenciamento de Identidade e Acesso (IAM) própria. Isso significa que o AWS Lake Formation enxerga as credenciais da ferramenta — não a pessoa que fez a pergunta. Sobram duas saídas ruins: restringir o acesso da ferramenta (limitando a análise self-service) ou reconstruir os controles de acesso no código da aplicação (tirando a governança da camada de dados).

A AWS publicou um padrão diferente: agentes de IA com consciência de identidade, que propagam a identidade de cada usuário por todos os saltos — do usuário, passando pelo agente, chegando até a ferramenta — para que o Lake Formation avalie as permissões do usuário real. O código da aplicação não toma nenhuma decisão de autorização, as políticas existentes no Lake Formation funcionam sem modificações, e o AWS CloudTrail registra a pessoa real que acessou os dados.

O que esse padrão entrega na prática

O padrão, implementado com o Amazon Bedrock AgentCore, resolve três problemas de uma vez:

• Controle de acesso por usuário para agentes de IA que consultam o lakehouse, sem reescrever as políticas existentes do Lake Formation.
• Auditabilidade e conformidade garantidas por uma troca de token no servidor, dentro do AWS Lambda, que converte o token de identidade em credenciais com escopo do usuário real — com cada consulta registrada no CloudTrail.
• Validação ponta a ponta com múltiplos usuários, confirmando resultados distintos e evidências de auditoria por usuário.

Os blocos de construção — delegação de token OAuth 2.0, AWS IAM Identity Center, Lake Formation e Lambda — são bem documentados individualmente. A novidade é que um modelo de fundação (FM) agora está no meio da cadeia de propagação. O FM é o cérebro do agente: ele decide quais ferramentas chamar e quais argumentos passar. Qualquer coisa que entra no seu contexto (prompts, esquemas de ferramentas, argumentos) fica acessível dentro daquele limite de confiança. Por isso, o token de identidade do usuário precisa chegar à ferramenta, mas deve fazer isso na camada de transporte HTTP — completamente fora da camada de raciocínio do FM.

Como o fluxo funciona

Dois tokens percorrem o sistema. Um access_token autentica a requisição em cada fronteira de confiança. Um id_token carrega a identidade do usuário e é trocado, no servidor, pelo contexto de identidade que o Lake Formation avalia.

O fluxo completo da requisição funciona assim:

• Usuário → Interface: o usuário se autentica com um provedor de identidade OpenID Connect (OIDC). A implementação de referência usa o Amazon Cognito, mas qualquer provedor OIDC funciona. A interface recebe um id_token e um access_token.
• Interface → AgentCore Runtime: a interface chama o agente via HTTPS. O access_token vai no cabeçalho padrão Authorization. O id_token vai em um cabeçalho customizado: X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken. O corpo HTTP contém apenas o prompt do usuário.
• AgentCore Runtime → código do agente: o runtime valida o access_token e repassa a requisição ao container do agente com ambos os cabeçalhos acessíveis via context.request_headers.
• Agente → AgentCore Gateway: o agente abre uma conexão via Protocolo de Contexto de Modelo (MCP) com o gateway, incluindo ambos os cabeçalhos na conexão. O gateway valida o access_token e encaminha o cabeçalho customizado ao Lambda alvo.
• AgentCore Gateway → Lambda: os cabeçalhos propagados chegam em context.client_context.custom['bedrockAgentCorePropagatedHeaders'].
• Lambda → camada de dados: o Lambda valida o id_token, troca-o por um contexto de identidade, assume uma função com esse contexto e executa a consulta no Amazon Athena sob a identidade do usuário. O Lake Formation avalia as permissões do usuário real. O Athena retorna apenas as linhas e colunas que aquele usuário tem direito de ver. O CloudTrail registra a função assumida com uma entrada onBehalfOf identificando o ser humano.

Os três pontos de configuração no Bedrock AgentCore

1. Lista de permissão de cabeçalhos no runtime

Por padrão, o Bedrock AgentCore Runtime não repassa cabeçalhos de requisição ao container do agente. É necessário declarar uma lista de permissão explícita, seja via agentcore configure ou diretamente na configuração do runtime:

# .bedrock_agentcore.yaml
request_header_configuration:
  requestHeaderAllowlist:
    - Authorization
    - X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken

O runtime suporta dois tipos de cabeçalhos encaminhados: o cabeçalho padrão Authorization para autenticação JWT de entrada (access_token), e cabeçalhos customizados com prefixo X-Amzn-Bedrock-AgentCore-Runtime-Custom-. O id_token usa um cabeçalho customizado. Dentro do agente, os cabeçalhos permitidos chegam como um objeto dicionário no contexto da requisição. O código Python que roda no container do agente fica assim:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload, context):
    request_headers = getattr(context, "request_headers", None) or {}
    id_token = ""
    access_token = ""
    for key, value in request_headers.items():
        if key.lower() == ID_TOKEN_HEADER.lower():
            id_token = value
        elif key.lower() == "authorization":
            access_token = value.replace("Bearer ", "")
    # ... build MCP headers and call the Gateway

O código do agente lê o id_token da camada de transporte HTTP e o encaminha (também na camada de transporte) para o próximo salto. Ele não trata o token como argumento de ferramenta e não o injeta em um prompt. Ponto-chave: a lista de permissão do runtime é o primeiro portão. Sem ela, o id_token não chega ao código do agente.

2. Metadados do AgentCore Gateway para propagação de cabeçalhos

O Bedrock AgentCore Gateway é o endpoint MCP com o qual o agente se comunica. Por padrão, ao invocar um Lambda alvo, ele não encaminha cabeçalhos arbitrários. É necessário configurar quais cabeçalhos propagar usando metadataConfiguration.allowedRequestHeaders no alvo:

from aws_cdk import aws_bedrockagentcore as agentcore

self.gateway_target = agentcore.CfnGatewayTarget(
    self, "AthenaTarget",
    name="athena-executor",
    gateway_identifier=self.gateway.attr_gateway_identifier,
    target_configuration=agentcore.CfnGatewayTarget.TargetConfigurationProperty(
        mcp=agentcore.CfnGatewayTarget.McpTargetConfigurationProperty(
            lambda_=agentcore.CfnGatewayTarget.McpLambdaTargetConfigurationProperty(
                lambda_arn=lambda_function_arn,
                tool_schema=...  # execute_athena_query
            ),
        ),
    ),
    metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty(
        allowed_request_headers=["X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"],
    ),
    ...
)

Observe que o esquema da ferramenta não inclui um parâmetro id_token — não há parâmetro de token em nenhuma ferramenta. O FM não vê, seleciona nem passa um id_token, porque o token não faz parte do contrato da ferramenta. Ele viaja em paralelo à chamada de ferramenta, na conexão HTTP, via metadataConfiguration. Essa é uma propriedade crítica de segurança: se o id_token fosse colocado no esquema da ferramenta, o FM seria responsável por passá-lo — o que significa que o token apareceria em prompts, rastreamentos, memória e logs. Mantê-lo fora do contrato da ferramenta o mantém fora do FM completamente.

3. Leitura dos cabeçalhos propagados no Lambda

No lado do Lambda, o cabeçalho propagado chega não no corpo do evento, mas no contexto do cliente, sob uma chave específica:

ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"

def lambda_handler(event, context):
    client_ctx = getattr(context.client_context, "custom", {}) or {}
    propagated_headers = client_ctx.get("bedrockAgentCorePropagatedHeaders", {})
    id_token = propagated_headers.get(ID_TOKEN_HEADER)

    if not id_token:
        return {"statusCode": 400, "body": {"error": "missing id_token"}}

    # Tool arguments from the agent's call (no id_token here)
    query = event["query"]
    database = event["database"]
    workgroup = event["workgroup"]
    output_location = event["output_location"]

    # ... validate token, exchange, run query

O dicionário do evento contém apenas os parâmetros declarados da ferramenta — nada mais. O id_token é acessado exclusivamente via context.client_context.custom['bedrockAgentCorePropagatedHeaders']. O Lambda é o único componente que lê o token.

A troca de token no servidor

Depois que o Lambda tem o id_token, ele valida o token e o troca por um identityContext. Essa etapa usa a mecânica padrão de Propagação de Identidade Confiável (TIP) do IAM Identity Center. O fato de acontecer dentro do Lambda é o que impede que o contexto de identidade cruze fronteiras de processo:

import boto3, jwt, time

def exchange_and_assume(id_token: str, user_sub: str):
    # 1. Validate id_token against the OIDC IdP's JWKS.
    claims = validate_id_token(id_token)  # signature, exp, aud, iss, token_use

    # 2. Exchange for an Identity Center identityContext.
    sso_oidc = boto3.client("sso-oidc")
    resp = sso_oidc.create_token_with_iam(
        clientId=OAUTH_APPLICATION_ARN,
        grantType="urn:ietf:params:oauth:grant-type:jwt-bearer",
        assertion=id_token,
    )
    identity_context = resp["awsAdditionalDetails"]["identityContext"]

    # 3. AssumeRole with ProvidedContexts
    sts = boto3.client("sts")
    assumed = sts.assume_role(
        RoleArn=TIP_ROLE_ARN,
        RoleSessionName=f"agent-tip-{user_sub[:8]}-{int(time.time())}",
        ProvidedContexts=[{
            "ProviderArn": "arn:aws:iam::aws:contextProvider/IdentityCenter",
            "ContextAssertion": identity_context,
        }],
    )
    creds = assumed["Credentials"]
    return boto3.Session(
        aws_access_key_id=creds["AccessKeyId"],
        aws_secret_access_key=creds["SecretAccessKey"],
        aws_session_token=creds["SessionToken"],
    )

Dois aspectos importantes saem dessa troca: o identityContext é criado e consumido dentro de uma única invocação do Lambda — ele não volta para o agente, o gateway ou a interface. E a boto3.Session resultante contém credenciais de curta duração cuja asserção de identidade subjacente é o usuário real. Quando a sessão chama o Athena, a consulta roda com a identidade do usuário propagada. O Lake Formation enxerga o usuário, não a função do Lambda.

Configuração do Lake Formation

É necessária apenas uma permissão para o usuário ou grupo no IAM Identity Center. Esse é o único trabalho na camada do Lake Formation:

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ \
  --resource '{"Table":{"DatabaseName":"iceberg_db","Name":"trip_details"}}' \
  --permissions SELECT

Essa é a permissão que o Lake Formation avalia no momento da consulta. Filtros em nível de coluna e linha são adicionados ao mesmo usuário ou grupo da mesma forma. Nada aqui é específico para agentes de IA. Se você já tem um modelo de permissões do Lake Formation para usuários humanos, você já tem as permissões que esse padrão precisa.

A função TIP que o Lambda assume não tem permissões de dados no Lake Formation. Ela contém apenas permissões IAM para chamar as APIs de serviço: athena:* para execução de consultas, glue:* para leituras do catálogo, lakeformation:GetDataAccess para o handshake do plano de consulta, e acesso ao Amazon Simple Storage Service (Amazon S3) para o bucket de saída do Athena. Quando o Lambda assume essa função com um identityContext anexado via ProvidedContexts, o Lake Formation avalia apenas a identidade do usuário propagada. A função em si é transparente para a decisão de autorização.

Testando o padrão ponta a ponta

Dois usuários, mesma pergunta, resultados diferentes. O Usuário A tem permissão SELECT na tabela trip_details e solicita cinco registros — os dados são retornados. O Usuário B não tem permissão na mesma tabela e faz a mesma pergunta — o acesso é negado. Nenhum código mudou entre as duas interações. Nenhum parâmetro foi alterado. O Lake Formation tomou a decisão com base na identidade propagada.

O registro no CloudTrail para a chamada AssumeRole mostra a delegação:

{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "requestParameters": {
    "roleArn": "arn:aws:iam:::role/",
    "roleSessionName": "agent-tip--",
    "providedContexts": [{
      "providerArn": "arn:aws:iam::aws:contextProvider/IdentityCenter",
      "contextAssertion": ""
    }]
  },
  "userIdentity": {
    "type": "AssumedRole",
    "onBehalfOf": {
      "userId": "",
      "identityStoreArn": "arn:aws:identitystore:::identitystore/"
    }
  }
}

O bloco onBehalfOf fecha o ciclo de auditoria. Cada consulta que o agente executa em nome de um usuário tem um registro no CloudTrail com o nome desse usuário — sem nenhuma instrumentação adicional no código.

As quatro propriedades de segurança do padrão

• O id_token nunca chega ao modelo de fundação: ele trafega em cabeçalhos HTTP em cada salto, e o Lambda o lê via context.client_context.custom. Não é um parâmetro de nenhuma ferramenta. O FM não tem caminho para acessá-lo — nem em argumentos de ferramentas, nem em prompts, nem em memória, nem em rastreamentos.
• O contexto de identidade permanece dentro de uma única invocação do Lambda: é derivado do id_token, usado imediatamente em uma chamada AssumeRole e descartado. Não retorna ao agente, ao gateway ou à interface.
• As decisões de autorização vivem no Lake Formation, contra o usuário real: a função TIP que o Lambda assume não tem permissões de dados. O Lake Formation avalia a identidade propagada do usuário. Nenhum caminho de código no agente, gateway ou Lambda executa lógica de autorização.
• A trilha de auditoria não requer trabalho extra: o evento AssumeRole no CloudTrail com onBehalfOf identifica o usuário humano em cada consulta — com a mesma fidelidade de auditoria que você teria para usuários humanos acessando dados diretamente.

Implantando o padrão

Para implantar esse padrão, quatro configurações são necessárias:

• Um provedor de identidade OIDC com um emissor de token confiável (TTI) no IAM Identity Center aceitando seus tokens, e um aplicativo OAuth no Identity Center configurado para CreateTokenWithIAM.
• Bedrock AgentCore Runtime rodando o container do agente com requestHeaderAllowlist cobrindo Authorization e o cabeçalho customizado do id_token.
• Bedrock AgentCore Gateway com um alvo Lambda cujo metadataConfiguration.allowedRequestHeaders inclui o cabeçalho do id_token. O esquema de ferramenta do Lambda não tem parâmetro de id_token.
• Lambda lendo o id_token de context.client_context.custom['bedrockAgentCorePropagatedHeaders'], realizando a troca de token via sso-oidc:CreateTokenWithIAM, e chamando sts:AssumeRole com ProvidedContexts para obter a sessão com TIP.

Conclusão

Quando um agente de IA consulta um lakehouse governado, a camada de dados precisa saber quem está perguntando — não qual função o agente está usando. A abordagem apresentada pela AWS resolve isso tratando o agente como um ator delegado OAuth. O token do usuário trafega junto ao transporte HTTP do agente, mas não entra no contexto do modelo. A troca de token que produz as credenciais de consulta acontece no servidor, dentro do Lambda, com escopo de uma única invocação.

As três funcionalidades do Bedrock AgentCore que tornam isso possível — requestHeaderAllowlist no runtime, metadataConfiguration.allowedRequestHeaders no gateway, e bedrockAgentCorePropagatedHeaders no Lambda — são específicas para construção sobre o Bedrock AgentCore. Tudo o que está abaixo do Lambda é funcionalidade do IAM Identity Center e do Lake Formation.

O resultado é uma separação limpa: a identidade do usuário trafega de ponta a ponta, o modelo nunca a vê, e a camada de dados a aplica exatamente como se o usuário tivesse consultado diretamente.

Recursos relacionados

• Propagação de Identidade Confiável com AWS IAM Identity Center
• Guia do usuário do AWS Lake Formation
• Cabeçalhos customizados do Amazon Bedrock AgentCore Runtime
• Propagação de cabeçalhos no Amazon Bedrock AgentCore Gateway
• RFC 7523 – Perfis JWT Bearer para OAuth 2.0
• Contrato de protocolo A2A do Amazon Bedrock AgentCore Runtime

Fonte

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation (https://aws.amazon.com/blogs/security/identity-aware-ai-data-agents-with-aws-lake-formation-and-trusted-identity-propagation/)

O problema com credenciais estáticas em ambientes de nuvem

Em ambientes modernos de nuvem, estabelecer confiança entre workloads é um pré-requisito para proteger a comunicação máquina a máquina. Abordagens tradicionais — como chaves de API, segredos compartilhados e credenciais estáticas de contas de serviço — simplesmente não foram projetadas para a escala e a natureza efêmera dos workloads em nuvem. Isso cria uma necessidade organizacional clara: migrar de credenciais de longa duração para identidades criptográficas de curta duração.

É nesse contexto que o SPIFFE (Framework de Identidade de Produção Segura para Todos) entra em cena como componente central de estratégias de identidade de workload. O SPIFFE é um conjunto de padrões open source para identificar com segurança sistemas de software em ambientes dinâmicos e heterogêneos. Um dos problemas que ele resolve é o chamado “problema da tartaruga de baixo”: a dependência circular onde proteger uma credencial exige outra credencial — e assim por diante.

O SPIRE (Ambiente de Execução SPIFFE) é a implementação open source do SPIFFE. Ele permite que equipes experimentem o framework rapidamente, mas traz consigo considerações operacionais e de segurança importantes quando levado para produção:

• Onde as chaves criptográficas de assinatura de identidades de workload são gerenciadas
• Como garantir disponibilidade e resiliência do registro de identidade de workload
• Como a Autoridade Certificadora (CA) do SPIRE se integra à PKI corporativa existente
• Como workloads sem conectividade direta ao servidor SPIRE validam identidades
• Como identidades de workload são entregues a ambientes serverless
• Como autorização granular baseada em SPIFFE IDs é aplicada

A AWS publicou um guia detalhado mostrando como endereçar cada um desses pontos ao delegar as funções centrais do SPIRE para serviços gerenciados. O post é acompanhado por um repositório no GitHub com toda a infraestrutura necessária para seguir a arquitetura de referência.

Como o SPIRE funciona: conceitos essenciais

Uma implantação SPIRE é composta por pelo menos um SPIRE Server, pelo menos um SPIRE Agent e pelo menos um workload. O servidor fica em um plano de controle central e gerencia a emissão de identidades e o armazenamento de registros de workloads. Ele opera com cinco funções principais:

• RegistrationAPI: Cria, atualiza e remove entradas que definem quais workloads têm direito a quais SPIFFE IDs, com base em seletores (namespace Kubernetes, UID Unix, etc.)
• DataStore: Armazena os registros de identidade de workload e o status dos SVIDs emitidos
• KeyManager: Controla como o servidor gerencia as chaves privadas usadas para assinar X.509-SVIDs e JWT-SVIDs
• BundlePublisher: Publica o trust bundle local em um repositório. O trust bundle contém as chaves criptográficas do domínio de confiança
• UpstreamAuthority: Define qual autoridade certificadora raiz assina o certificado CA do SPIRE

O SPIRE Agent é distribuído junto aos workloads, seja em instâncias Amazon EC2, containers Amazon ECS ou Pods do Amazon EKS. Ele expõe a Workload API, realiza atestação de nó e de workload, e pode armazenar SVIDs em destinos externos como o AWS Secrets Manager.

Após servidor e agente estarem em execução, as aplicações recuperam Documentos de Identidade Verificável SPIFFE de curta duração — seja como certificados X.509 ou JSON Web Tokens (JWTs) — usando a Workload API.

Usando serviços gerenciados da AWS para cada função do SPIRE

A arquitetura proposta pela AWS substitui cada componente padrão do SPIRE por um serviço gerenciado correspondente. Veja como cada integração funciona.

SPIRE Key Manager com AWS KMS

O Key Manager do SPIRE controla as chaves criptográficas usadas para assinar os SVIDs. Por padrão, essas chaves ficam em memória ou em disco — o que apresenta riscos em produção. Usando o plugin AWS KMS para SPIRE, as chaves passam a ser gerenciadas pelo AWS KMS, trazendo os seguintes benefícios:

• HSMs validados: O AWS KMS usa módulos de segurança de hardware (HSMs) validados sob FIPS 140-3 Nível 2
• Proteção de chaves: As chaves KMS em texto simples nunca saem dos HSMs, não são gravadas em disco e são usadas apenas na memória volátil durante a operação criptográfica
• Auditoria completa: Cada solicitação de uso das chaves é autenticada via Signature Version 4 (SigV4) e registrada no AWS CloudTrail
• Controle de acesso granular: Use Políticas de Chave do AWS KMS para restringir quem pode usar as chaves de assinatura

O bloco de configuração abaixo indica ao SPIRE que as chaves AWS KMS devem ser usadas para assinar os SVIDs:

KeyManager "aws_kms" {
  plugin_data {
    region = "<your-region>"
    key_identifier_file = "./key_metadata"
  }
}

SPIRE DataStore com Amazon Aurora

Por padrão, o SPIRE usa um banco SQLite em memória para armazenar os registros de identidade de workload. A AWS recomenda substituir isso pelo Amazon Aurora, desacoplando o banco de dados do servidor e eliminando a carga operacional de gerenciá-lo manualmente. Os benefícios incluem alta disponibilidade com failover automático e implantações multi-AZ, backups automatizados com recuperação point-in-time, escalabilidade independente de computação e armazenamento, criptografia em repouso e em trânsito com AWS IAM, e atualizações e patches automáticos.

O stack CloudFormation provisiona um cluster Aurora PostgreSQL, um usuário de banco com autenticação via IAM e a conectividade de rede entre o servidor SPIRE e o banco. A configuração do DataStore muda de:

DataStore "sql" {
  plugin_data {
    database_type = "sqlite3"
    connection_string = "/opt/spire/data/server/datastore.sqlite3"
  }
}

Para:

DataStore "sql" {
  plugin_data {
    database_type "aws_postgres" {
      region = "<region>"
    }
    connection_string = "dbname=<dbname> user=spiffe host=<your_db_endpoint> port=<your_port>"
  }
}

Mais detalhes estão disponíveis na documentação do Plugin Datastore SQL.

Autoridade Certificadora do SPIRE com AWS Private CA

Na configuração padrão, o SPIRE gera um certificado autoassinado como CA raiz. Em produção, organizações geralmente precisam encadear essa CA à hierarquia PKI corporativa existente. Usando o plugin AWS Private Certificate Authority (AWS Private CA), o SPIRE passa a atuar como uma CA emissora que encadeia à CA raiz existente. Os benefícios são:

• Raiz de confiança respaldada por HSM: A raiz da hierarquia de CA é protegida por HSMs gerenciados validados FIPS 140-2 Nível 3
• Chaves privadas não exportáveis: As chaves privadas da CA raiz não podem ser exportadas
• Listas de Revogação de Certificados e endpoint OCSP totalmente gerenciados: Para casos em que o certificado da CA emissora precise ser revogado

Importante: se o certificado CA do SPIRE for assinado por uma CA emissora, é necessário garantir que o path length dessa CA seja de pelo menos 1. O código de exemplo provisiona uma CA raiz, então isso não é um problema ao seguir o sample.

Após a implantação, a configuração do servidor SPIRE inclui o plugin UpstreamAuthority:

UpstreamAuthority "aws_pca" {
  plugin_data {
    region = "<aws_region>"
    certificate_authority_arn = "<your_pca_arn>"
    ca_signing_template_arn = "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1"
  }
}

Mais detalhes estão disponíveis na documentação do plugin AWS Private CA upstream authority.

SPIRE Bundle Publisher com Amazon S3

No SPIFFE, trust bundles são conjuntos de chaves públicas usadas pelos workloads de destino para verificar a identidade dos workloads de origem. O SPIRE Server suporta publicar esse bundle no Amazon S3. Com isso é possível:

• Desacoplar: O acesso ao bundle deixa de depender da disponibilidade do servidor SPIRE
• Validação contínua: Workloads de destino podem validar identidades de origem sem precisar de acesso de rede direto ao servidor SPIRE
• Distribuição global: O bundle pode ser distribuído via Amazon CloudFront, com mais de 750 Pontos de Presença ao redor do mundo
• Redução de carga: O tráfego de recuperação do trust bundle é descarregado do servidor SPIRE
• Controle de versão: Versões históricas dos trust bundles podem ser mantidas com o versionamento do S3

Exemplo de configuração para este plugin:

BundlePublisher "aws_s3" {
  plugin_data {
    region = "<your_bucket_region>"
    bucket = "<your_bucket_name>"
    object_key = "<your_bundle_name"
    format = "spiffe"
  }
}

Mais detalhes na referência do Plugin S3 Bundle Publisher.

SPIRE Agent SVID Store com Secrets Manager

Em uma implementação típica do SPIRE, os SVIDs são recuperados da Workload API pelo agente SPIRE. Porém, em cenários serverless ou de container, não é viável executar o agente SPIRE — especialmente em workloads rodando no AWS Lambda ou em agentes de IA no Amazon Bedrock AgentCore Runtime.

Nesses casos, o plugin SVID store permite que o SVID seja enviado diretamente para o Secrets Manager. Um agente SPIRE ainda precisa estar rodando em algum nó para realizar a atestação de nó com o servidor SPIRE e entregar o SVID ao secrets store. O Plugin AWS Secrets Manager SVIDStore oferece:

• Criptografia em repouso com chaves KMS gerenciadas pela AWS ou pelo cliente
• Integração com múltiplos tipos de computação, incluindo AWS Secrets Manager Lambda Extension, Amazon ECS, Amazon EMR e outros 52 serviços AWS
• Bibliotecas de cache client-side para melhorar performance e reduzir chamadas de API
• Replicação multi-região integrada
• Controle de acesso granular via resource policies
• Trilha de auditoria com todas as acessos registrados no CloudTrail

Este plugin é configurado no agente, não no servidor SPIRE. As permissões necessárias estão documentadas no repositório GitHub do plugin. No arquivo agent.conf do código de exemplo, a configuração é:

SVIDStore "aws_secretsmanager" {
  plugin_data {
    region = "<your_region>"
  }
}

Para que o SVID de um workload específico seja enviado ao Secrets Manager, os parâmetros storeSVID e selector precisam ser adicionados ao criar a entrada no registro de workload. Em um ambiente Kubernetes, o comando fica assim:

kubectl exec -n spire spire-server-<postfix>-- \
  /opt/spire/bin/spire-server entry create \
  -spiffeID spiffe://example.org/<workload_name> \
  -parentID spiffe://example.org/ns/spire/sa/spire-agent \
  -selector aws_secretsmanager:secretname:<workload_name> \
  -storeSVID

Controle de acesso granular com Amazon Verified Permissions

Todos os serviços gerenciados mencionados até aqui tratam da criação e distribuição de SVIDs e trust bundles. Mas um dos grandes diferenciais do SPIFFE é permitir que donos de recursos protejam seus recursos com autorização granular. O Amazon Verified Permissions é o serviço gerenciado que atende a essa necessidade no contexto de implementações SPIFFE/SPIRE.

Com o Verified Permissions é possível:

• Definir políticas declarativas: Usando a linguagem de políticas Cedar, que oferece regras de controle de acesso legíveis por humanos
• Centralizar o gerenciamento de políticas: Separando a lógica de autorização do código da aplicação, com suporte a verificação formal e benefícios de performance do Cedar
• Tomar decisões em tempo real: Avaliando requisições de autorização com base em identidade do usuário, identidade do workload (SPIFFE ID), atributos do recurso e informações contextuais
• Integrar com provedores de identidade: Com suporte a provedores OpenID Connect (OIDC), habilitando validação de tokens JWT, incluindo JWT-SVIDs

Para usar o Verified Permissions, são necessários um policy store, uma fonte de identidade e políticas de autorização. O código de exemplo cria o policy store e configura a infraestrutura para que o SPIRE atue como fonte de identidade.

A política abaixo proíbe um workload específico de executar qualquer ação:

forbid(
  principal,
  action,
  resource
) when {
  context has sub &&
  context.sub like "spiffe://example.org/forbidden-workload/*"
};

E esta permite que um workload específico execute ações:

permit(
  principal,
  action,
  resource
) when {
  context has sub &&
  context.sub like "spiffe://example.org/allowed-workload/*"
};

Conclusão

A AWS demonstrou como organizações podem aprimorar suas implantações SPIRE substituindo implementações padrão por serviços gerenciados. As integrações cobrem AWS KMS para assinatura de SVIDs, Amazon Aurora para operações de datastore gerenciado, AWS Private CA para raiz de confiança, Amazon S3 e CloudFront para distribuição global de trust bundles, AWS Secrets Manager para armazenamento de SVIDs e Amazon Verified Permissions para autorização granular.

Ao adotar essas integrações, as organizações conseguem melhorar a postura de segurança, reduzir a complexidade operacional e aumentar a resiliência de suas implantações SPIRE. Para quem quer aprender mais, a AWS disponibiliza o repositório GitHub do SPIRE on AWS e o Workshop SPIFFE e SPIRE na AWS para aprendizado prático.

Fonte

Improving SPIRE security and resiliency with AWS managed services (https://aws.amazon.com/blogs/security/improving-spire-security-and-resiliency-with-aws-managed-services/)

O que mudou no AWS Certificate Manager

A AWS anunciou uma atualização relevante para quem utiliza o Gerenciador de Certificados da AWS (ACM): agora é possível emitir e renovar certificados públicos TLS via protocolo ACME utilizando o AWS PrivateLink. Na prática, isso significa que todo o fluxo de emissão de certificados pode permanecer dentro da rede privada da AWS, sem precisar trafegar pela internet pública.

Como funciona na prática

Para usar o recurso, é necessário criar um endpoint de interface de Rede Privada Virtual (VPC) apontando para o serviço ACME do ACM. A partir daí, qualquer cliente compatível com ACMEv2 pode rotear o tráfego de emissão de certificados diretamente pela sua VPC.

Um ponto importante: quem já utiliza o ACME com o ACM não precisa alterar nada na configuração dos clientes existentes. Após a criação do endpoint ACME gerenciado no ACM, basta criar o endpoint de interface VPC padrão — pelo console da VPC, pela Interface de Linha de Comando da AWS (AWS CLI) ou via AWS CloudFormation. O DNS privado resolve automaticamente a URL do diretório ACME já existente para o endpoint dentro da VPC, mantendo a mesma configuração e URL que o cliente já utiliza.

O que passa pelo PrivateLink

Com o PrivateLink habilitado, todas as operações de emissão passam pelo caminho privado. Isso inclui:

• Criação de conta
• Criação de pedido de certificado
• Validação de domínio
• Finalização da emissão
• Recuperação do certificado

Toda a atividade continua visível no console do ACM, com registros via AWS CloudTrail e métricas no Amazon CloudWatch, garantindo rastreabilidade e auditoria completas.

Disponibilidade e custos

O suporte ao AWS PrivateLink para emissão de certificados ACME está disponível em todas as regiões comerciais da AWS. As cobranças padrão do AWS PrivateLink se aplicam para os endpoints de interface. Para detalhes sobre preços, consulte a página de preços do ACM.

Como começar

Para quem quer entender melhor o recurso e dar os primeiros passos, a AWS disponibilizou um post no AWS News Blog com mais detalhes, além da documentação oficial completa sobre ACME com PrivateLink.

Fonte

AWS Certificate Manager now supports ACME issuance through AWS PrivateLink (https://aws.amazon.com/about-aws/whats-new/2026/10/AWS-Certificate-Manager-ACME-Privatelink)

O desafio de governar clusters compartilhados

O Amazon SageMaker HyperPod oferece a times de aprendizado de máquina (ML) acesso a grandes pools de compute acelerado para treinar e ajustar modelos. Quando várias equipes compartilham um mesmo cluster, a parte técnica costuma ser simples. O que complica é a governança: quem pode usar o cluster, quanto cada time recebe, o que acontece quando workloads competem por recursos e quem responde quando o uso se afasta da política definida.

O Amazon SageMaker Unified Studio adiciona mais uma camada a esse cenário: é possível conectar um cluster HyperPod a um projeto para que membros do time lancem workloads diretamente do workspace. Isso é conveniente, mas quando múltiplas equipes passam a enxergar o mesmo cluster, os controles sobre quem pode fazer o quê se tornam ainda mais críticos.

A AWS publicou um guia de boas práticas que mostra como administrar o SageMaker HyperPod pelo SageMaker Unified Studio preservando os controles de governança subjacentes. O modelo cobre quatro camadas de controle — organização, projeto, cluster e workload — e explica como estruturar políticas de identidade, capacidade e observabilidade em cada uma delas.

Vale lembrar: o SageMaker HyperPod é uma capacidade do Amazon SageMaker AI, enquanto o SageMaker Unified Studio é o ambiente de desenvolvimento de dados e IA onde os times trabalham com suas ferramentas. A separação entre os dois é justamente o que dá à equipe de infraestrutura um modelo operacional claro.

As quatro camadas de controle

Um ambiente bem governado separa administração organizacional, acesso por projeto e operações de cluster. Cada camada responde a uma pergunta diferente e usa um controle diferente:

• Organização: domínios e unidades de domínio do SageMaker Unified Studio, contas associadas, perfis de projeto e políticas de autorização. Define quem pode criar projetos, quais contas e regiões estão disponíveis e quais ferramentas são permitidas.
• Projeto: membros do projeto, papéis e conexões com o HyperPod. Define o contexto de colaboração e os recursos AWS que os membros podem acessar.
• Cluster: papéis de administrador do HyperPod, entradas de acesso ao Amazon EKS, Controle de Acesso Baseado em Papel (RBAC), EKS Pod Identity ou controles do Slurm. Governa configuração do cluster, acesso ao scheduler, namespaces, tarefas e operações de infraestrutura.
• Workload: alocações de compute, classes de prioridade, políticas de empréstimo e permissões de tarefa. Controla quem pode submeter trabalho e como a capacidade compartilhada é distribuída.

Um ponto importante: uma conexão do HyperPod adiciona um cluster aprovado a um projeto, mas não substitui os controles de Gerenciamento de Identidade e Acesso (IAM), Amazon EKS ou Slurm já existentes. Papéis de projeto, papéis de acesso de conexão, entradas EKS, RBAC, identidade de workload, políticas de dados e de chaves do AWS Key Management Service (AWS KMS), políticas de rede e controles do scheduler devem ser revisados em conjunto. O cluster só deve ser disponibilizado depois que todos esses controles estiverem alinhados.

Projetos do SageMaker Unified Studio são fronteiras de colaboração — não são fronteiras fortes de segurança em tempo de execução. O cluster HyperPod, o scheduler e a capacidade de aceleradores devem permanecer sob uma conta de capacidade designada. Para Amazon EKS, a recomendação é usar um namespace por tenant com RBAC, contas de serviço por tenant com papéis EKS Pod Identity, políticas de rede com negação padrão e permissões de armazenamento e KMS específicas por tenant. Para Slurm, usar contabilidade hierárquica com associações, Qualidade de Serviço (QoS), políticas de prioridade e partições.

Quando o SageMaker Unified Studio é a experiência certa

Com o SageMaker Unified Studio, times de ML que já trabalham em um projeto podem seguir um caminho aprovado para acessar o compute compartilhado do HyperPod — encontrar clusters conectados, revisar status e metadados, inspecionar tarefas e métricas, e abrir o JupyterLab sem precisar de um inventário de infraestrutura separado.

Mas essa experiência não substitui a administração do cluster. Cada persona tem seu papel:

• Administrador de domínio ou infraestrutura: usa o Unified Studio para unidades de domínio, políticas de criação de projetos e perfis. Continua usando ferramentas específicas para provisionamento de contas e automação de infraestrutura.
• Administrador do cluster HyperPod: usa o Unified Studio para apresentar conexões aprovadas e revisar metadados. Continua usando as interfaces do SageMaker AI para criação, atualização, resiliência e resposta a incidentes.
• Dono do projeto: gerencia membros e o contexto de compute aprovado. Solicita mudanças de infraestrutura por canais adequados.
• Engenheiro de ML ou cientista de dados: encontra compute aprovado, revisa status de workloads e abre o JupyterLab. Submete e gerencia workloads detalhados pelo HyperPod CLI, kubectl ou ferramentas Slurm.

Para mudanças no cluster e automação repetível, a recomendação é continuar usando APIs do SageMaker AI, infraestrutura como código e ferramentas de orquestração. Implementações de referência estão disponíveis no site AI on SageMaker HyperPod.

Decisões antes de conectar um cluster

Antes de aprovar uma conexão, a AWS recomenda documentar a conta de capacidade, contas de consumidor ou dados, região AWS, caminhos de rede, identidades, donos, fronteiras de workload e requisitos de isolamento. Para orientações sobre criação de cluster, consulte a documentação do Amazon SageMaker HyperPod.

Alguns princípios fundamentais para essa etapa:

• Separe identidades administrativas e de workload. Um papel voltado para o projeto não deve receber permissões de ciclo de vida do cluster só porque seus usuários executam workloads. Consulte AWS Identity and Access Management para SageMaker HyperPod para o modelo de permissões suportado.
• Trate a rede como controle de ponta a ponta. Restrinja o acesso ao endpoint da API Kubernetes do EKS a caminhos administrativos aprovados, controle ingresso e egresso de pods, e configure endpoints de VPC para serviços como Amazon S3, Amazon ECR e Amazon CloudWatch. Para configuração específica do orquestrador, consulte Orquestrando clusters SageMaker HyperPod com Amazon EKS.
• Crie um contrato de conexão. Esse é um registro de governança gerenciado pelo cliente — pode ser uma página de wiki, ticket, registro de service catalog ou arquivo em repositório de infraestrutura como código. Não é uma funcionalidade da plataforma. Deve registrar: dono de negócio, operações e custos; domínio e projeto no Unified Studio; conta, região, nome e orquestrador do cluster; papel do projeto e ARN do papel de acesso; tipos de workload aprovados e classificação de dados; namespaces EKS ou escopo de acesso Slurm; política de scheduling e dono de exceções; e expectativas de monitoramento e descomissionamento.

Governança de identidade e visibilidade de tarefas

Controlar tanto ações quanto visibilidade é essencial. Uma configuração incorreta de nomes de tarefas, namespaces e padrões de uso pode revelar informações sobre o trabalho de outra equipe.

A AWS chama atenção para um detalhe importante: por padrão, usuários do SageMaker AI Studio conseguem ver todas as tarefas de clusters Amazon EKS. Para clusters Slurm, todo usuário do Studio pode visualizar, gerenciar e interagir com tarefas disponíveis. Por isso, é necessário configurar restrições de visibilidade de tarefas antes de integrar múltiplas equipes — veja Restringir visibilidade de tarefas no Studio para clusters EKS e Restringir visibilidade de tarefas no Studio para clusters Slurm.

Para clusters Amazon EKS, cada time deve ser mapeado para um namespace aprovado com permissões RBAC, e cada conta de serviço de workload deve estar associada a um papel IAM específico do tenant. Para acesso a dados entre contas, o EKS Pod Identity realiza a assunção de papel entre contas automaticamente, sem que o código da aplicação precise chamar AssumeRole diretamente.

Manter visibilidade somente leitura separada das permissões para criar, atualizar ou excluir workloads é fundamental. O exemplo abaixo, presente no guia original, mostra um Role Kubernetes RBAC que concede a um time acesso somente leitura a jobs apenas em seu próprio namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-research
  name: research-job-viewer
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
  resources: ["pytorchjobs"]
  verbs: ["get", "list", "watch"]

Um papel separado é necessário para criar ou excluir workloads, mantendo “ver” separado de “agir”.

Traduzindo prioridades de negócio em política de scheduling

Para clusters Amazon EKS, a AWS recomenda aplicar a governança de tarefas somente depois que os controles de identidade e acesso de workload estiverem em vigor. A separação entre autorização e política de scheduling é um ponto central do guia.

RBAC do EKS ou listas de controle de acesso (ACLs) do Slurm determinam se um usuário pode submeter um workload. A governança de tarefas do SageMaker HyperPod para Amazon EKS ou os controles nativos do Slurm determinam quando esse workload autorizado recebe compute. Usar quota do scheduler como controle de acesso, ou usar controles de autorização como política de scheduling, gera comportamento ambíguo e dificulta o diagnóstico de incidentes.

A AWS recomenda documentar capacidade garantida e compartilhada, classes de prioridade e se um time pode usar a alocação ociosa de outro. Por exemplo: o time de treinamento de produção pode receber 60% de alocação garantida com classe de alta prioridade, enquanto o time de pesquisa toma capacidade ociosa em prioridade mais baixa e pode ser preemptado quando o time de produção submeter trabalho. Cada exceção a essa política deve ter um dono designado.

A governança de tarefas também se aplica aos SageMaker HyperPod spaces — ambientes JupyterLab ou Code Editor que rodam diretamente no cluster — portanto esses workloads interativos devem ser incluídos na política de alocação. O post Boas práticas para governança de tarefas do Amazon SageMaker HyperPod detalha pesos de fair-share, quotas, empréstimo e preempção para clusters EKS.

Observabilidade como ciclo de feedback de governança

Com o SageMaker Unified Studio, é possível visualizar detalhes do cluster HyperPod — tarefas, métricas, configurações e metadados. Para clusters EKS, as métricas de governança de tarefas incluem visões de hardware, time e tarefa, que ajudam a comparar a intenção da política com o consumo real.

A recomendação é tratar a observabilidade como um ciclo: monitorar sinais, comparar com a intenção da política, decidir uma resposta e ajustar política e alocações. Cada sinal monitorado deve ter um dono e uma resposta definidos. Alguns exemplos práticos do guia:

• Capacidade do cluster e utilização de aceleradores: verificar se baixa utilização é temporária, orientada por política ou causada por restrições de workload.
• Alocação e utilização por time: revisar se a capacidade reservada e compartilhada ainda reflete a demanda de negócio.
• Tempo de execução e espera de tarefas: investigar política de prioridade, dimensionamento de workload ou contenção de capacidade.
• Tarefas pendentes e preemptadas: confirmar que os resultados do scheduler correspondem ao modelo de prioridade aprovado.
• Saúde de nós e eventos de recuperação: acionar o processo de incidente do cluster e validar objetivos de recuperação.

O add-on Amazon CloudWatch Observability EKS é necessário para as visões de métricas documentadas. Ele requer versão 2.4.0 ou superior e a política IAM CloudWatchAgentServerPolicy anexada ao papel do nó worker Kubernetes. Métricas do Kueue, que alimentam as visões de governança de tarefas, podem gerar cobranças do CloudWatch após o nível gratuito. Consulte a documentação do dashboard do SageMaker HyperPod para considerações atuais de configuração e preços.

Revisando conexões ao longo do ciclo de vida

A AWS recomenda definir um calendário de revisão para cada conexão, além de revisões orientadas por eventos — mudanças de dono de projeto, papéis de acesso, conta ou região, capacidade do cluster, versão do orquestrador, classificação de dados ou cobertura de monitoramento. O contrato de conexão deve registrar cada decisão tomada.

O ciclo de vida de uma conexão passa por quatro fases: aprovação com contrato registrado, operação com monitoramento de uso e custo, revisão periódica e orientada por eventos, e por fim renovação ou revogação. Automação de inventário e coleta de evidências é bem-vinda onde reduz trabalho manual, mas a aprovação deve permanecer com administradores responsáveis. Conexões sem propósito de negócio ou dono responsável devem ser revogadas.

Por onde começar

O guia da AWS sugere começar com um cluster fora de produção e um projeto de teste. Antes de adicionar membros, configure identidade de workload, escopo de namespace ou Slurm, permissões de dados, política de rede, restrições de visibilidade de tarefas e governança de tarefas para EKS (ou controles nativos de scheduling para Slurm). Instale o add-on Amazon CloudWatch Observability EKS para que as visões de métricas sejam populadas, e registre a aprovação completa no contrato de conexão. Use papéis entre contas para contas de consumidor aprovadas e infraestrutura dedicada quando isolamento rígido for exigido. Para os passos de implementação, consulte o procedimento de conexão do SageMaker HyperPod.

Fonte

Best practices for Amazon SageMaker HyperPod administration and governance (https://aws.amazon.com/blogs/machine-learning/best-practices-for-amazon-sagemaker-hyperpod-administration-and-governance/)

O problema: promoção manual entre contas é lenta e arriscada

O Amazon Quick é o assistente de inteligência artificial agêntico da Amazon voltado para o ambiente corporativo. Com ele, as equipes constroem agentes que raciocinam sobre dados internos, acionam conectores e executam tarefas em múltiplas etapas. O problema surge quando esses recursos — agentes de chat, conectores de ação, bases de conhecimento, fluxos e espaços — precisam ser promovidos de uma conta AWS de desenvolvimento para uma conta de produção.

A maioria das empresas mantém contas AWS separadas para desenvolvimento e produção, às vezes com um ambiente de garantia de qualidade (QA) no meio. Quando os recursos são validados no ambiente de desenvolvimento, não existe um mecanismo nativo de “um clique” para promovê-los à próxima conta. As equipes precisam recriar cada recurso manualmente: reconfigurar agentes com as mesmas instruções e prompts iniciais, reconectar os conectores de ação, reatribuir permissões e reprovisionar o bucket do Amazon Simple Storage Service (Amazon S3), sua política e a fonte de dados de cada base de conhecimento.

Esse processo é lento, difícil de auditar e fácil de errar em detalhes sutis — o que compromete exatamente a governança que as empresas precisam demonstrar.

A solução: Quick Resource Migrator via servidor MCP

A AWS publicou um guia detalhado apresentando o Quick Resource Migrator, um servidor MCP (Protocolo de Contexto de Modelo) de exemplo hospedado no runtime do Amazon Bedrock AgentCore. Ele automatiza a promoção de recursos do Amazon Quick entre contas em uma única chamada de ferramenta.

O funcionamento é direto: você escolhe um tipo de recurso (agente, conector, base de conhecimento, fluxo ou espaço) e seleciona pelo identificador, pelo nome ou todos de uma vez. O servidor lê o recurso e suas permissões via API do Amazon Quick Sight e os replica na conta de destino exatamente como estavam. O código-fonte completo está disponível no repositório aws-samples.

Dois princípios norteiam o design:

• Idempotência: o migrador nunca emite um comando de exclusão contra a conta de destino. Cada execução apenas cria ou atualiza recursos. Rodar o processo várias vezes converge sempre para o mesmo estado, sem duplicatas nem falhas.
• Reversibilidade segura: antes de atualizar qualquer recurso existente na conta de destino, o servidor grava um snapshot versionado desse recurso em um bucket S3 dedicado. Se esse backup não puder ser gravado, a atualização é abortada. Isso garante um histórico completo e a possibilidade de rollback.

O que é migrado e como

Agentes de chat

Recriados com suas instruções personalizadas, identidade, tom, prompts iniciais e mensagem de boas-vindas. Os conectores de ação são reanexados com os identificadores de recurso (ARNs) remapeados para a conta de destino. Quando um espaço é migrado, seus agentes são automaticamente revinculados a ele.

Conectores de ação

Recriados com sua configuração. Valores secretos nunca são lidos da conta de origem — os conectores são criados com credenciais temporárias e reautenticados na conta de destino.

Bases de conhecimento

A base de conhecimento é registrada na conta de destino, sua fonte de dados é recriada e as permissões são copiadas. Para bases apoiadas em S3, o migrador também provisiona o bucket de destino e sua política. Os documentos em si (objetos S3) não são copiados.

Fluxos

Recriados na conta de destino a partir de sua definição. Como os identificadores de fluxo diferem entre contas, o matching é feito pelo nome: um fluxo com o mesmo nome na conta de destino é atualizado; caso contrário, um novo é criado. As permissões são copiadas.

Espaços

Recriados na conta de destino e revinculados a seus agentes, conectores e bases de conhecimento, com ARNs remapeados. As permissões do espaço são copiadas. A recomendação é migrar os recursos vinculados primeiro, para que os ARNs de destino já existam quando o espaço for criado.

Princípios de design e segurança

A solução adota um modelo de três contas: uma conta runner central hospeda o servidor MCP no runtime do Amazon Bedrock AgentCore. Essa conta assume um papel somente leitura na conta de origem e um papel de leitura e escrita na conta de destino usando o Serviço de Token de Segurança da AWS (AWS STS) — nenhuma credencial de longa duração é armazenada em lugar algum.

O runtime autentica os chamadores com um Token Web JSON (JWT) do Amazon Cognito e pode operar em modo de rede de Nuvem Privada Virtual (VPC). O papel na conta de origem tem apenas permissões de leitura. O papel na conta de destino possui somente as ações necessárias para a migração — sem privilégios excessivos.

A tabela abaixo resume as responsabilidades de cada componente da arquitetura:

• Runtime AgentCore (conta runner): hospeda o servidor MCP, assume papéis nas contas de origem e destino e orquestra a migração.
• Amazon Cognito (conta runner): emite o JWT que os chamadores apresentam ao AgentCore.
• Papel de execução runner: permissões para Amazon CloudWatch Logs, telemetria e sts:AssumeRole nas contas de origem e destino.
• Papel migrador (conta de origem): permissões de leitura somente para o Quick Sight e bases de conhecimento.
• Papel migrador (conta de destino): permissões de criação e atualização no Quick Sight, escrita em bases de conhecimento e S3, e ListUsers para resolução de principais.
• Bucket de backup (conta runner): bucket S3 criptografado que armazena snapshots versionados dos recursos antes de cada atualização.

As cinco ferramentas expostas pelo servidor MCP

preview_migration (somente leitura)

Recebe o ID da conta de origem, o tipo de recurso, o seletor e a região AWS. Retorna um inventário do que seria migrado — nomes e tipos — sem realizar nenhuma alteração. Quando o ID da conta de destino também é informado, a resposta adiciona um mapeamento indicando se cada recurso seria criado (CREATE) ou atualizado (UPDATE). Ideal como passo de aprovação antes de qualquer promoção.

migrate_resources (migração completa)

Executa a migração completa de criação ou atualização e retorna um relatório estruturado de tudo o que foi criado, atualizado e concedido, além de eventuais erros. Por ser idempotente, pode ser executado em cada release.

list_backups (somente leitura)

Lista as versões disponíveis de cada recurso no catálogo de backups — os snapshots gravados antes de cada atualização.

get_backup (somente leitura)

Retorna o backup completo de um determinado recurso e versão (por padrão, a mais recente), incluindo a configuração capturada e suas dependências.

restore_backup

Reaaplica uma versão de backup salva sobre o recurso de destino, atualizando-o no lugar ou recriando-o se não existir mais. Antes de restaurar, captura um novo backup — tornando o próprio rollback reversível.

Fluxo de migração passo a passo

O processo segue esta sequência lógica:

• Resolução de recursos: a partir do tipo e do seletor, o servidor identifica os IDs concretos na conta de origem.
• Descrição da origem: cada recurso selecionado é descrito para capturar configuração e permissões.
• Conectores: recriados com configuração de autenticação sanitizada e credenciais temporárias.
• Bases de conhecimento: bucket de destino criado, política aplicada, fonte de dados e base de conhecimento provisionadas, permissões copiadas.
• Agentes: recriados com conectores de ação reanexados e permissões copiadas.
• Fluxos: recriados por nome, com permissões copiadas.
• Espaços: recriados e revinculados a agentes, conectores e bases de conhecimento com ARNs remapeados.
• Relatório: retorno em JSON com recursos criados, atualizados, buckets, backups, permissões ignoradas e erros.

Implantação e uso via Quick App

As instruções completas de implantação estão no README do repositório aws-samples. Em linhas gerais, são implantadas três stacks do AWS CloudFormation: os papéis de Gerenciamento de Identidade e Acesso (IAM) entre contas, a rede VPC e o runtime AgentCore autenticado pelo Cognito que hospeda o servidor MCP. Em seguida, esse runtime é registrado como um conector de ação no Amazon Quick.

Ao registrar o runtime como conector de ação, é possível acionar o migrador diretamente do Amazon Quick em linguagem natural. Também é possível construir um Quick App — uma experiência web guiada sobre as mesmas ferramentas MCP. O repositório inclui um prompt de construção do app pronto para uso: basta colá-lo no construtor de apps do Amazon Quick, substituindo os IDs de conector e ação pelos seus próprios.

O app gerado transforma o fluxo de trabalho em uma experiência guiada: escolha as contas de origem e destino e os recursos a promover, visualize o que será criado ou atualizado, execute a migração e revise o histórico completo de cada promoção passada — cada entrada respaldada pelos snapshots versionados gravados no S3.

Para fazer rollback, basta selecionar a versão de backup desejada e acionar a restauração. O app reaaplica aquela versão salva no recurso de destino. Como ele captura um novo backup antes de restaurar, o próprio rollback é reversível.

Conclusão

A promoção entre contas é uma expectativa básica para software corporativo, e até agora era justamente a peça que faltava no Amazon Quick. Com o Quick Resource Migrator, a AWS transforma uma tarefa lenta, manual e difícil de auditar em um processo rápido, repetível e governado: uma única chamada de ferramenta recria agentes, conectores e bases de conhecimento na conta de destino, copia permissões fielmente e faz tudo de forma idempotente — podendo ser executado a cada release.

Para quem quiser experimentar, o ponto de partida é clonar o repositório de exemplo, implantar em uma conta runner e testar a promoção de um agente ou base de conhecimento do desenvolvimento para a produção.

Fonte

Making Amazon Quick enterprise-ready: Automated, auditable cross-account resource promotion (https://aws.amazon.com/blogs/machine-learning/making-amazon-quick-enterprise-ready-automated-auditable-cross-account-resource-promotion/)

Testes de segurança direto no fluxo de desenvolvimento

A AWS anunciou, em prévia pública, uma expansão importante para o AWS Continuum for Penetration Testing (anteriormente conhecido como AWS Security Agent): agora o serviço se integra diretamente a pipelines de Integração Contínua e Entrega Contínua (CI/CD), tornando o teste de penetração parte do próprio processo de deploy.

O que muda na prática

O AWS Continuum for Penetration Testing já oferecia testes de penetração contínuos e sob demanda, eliminando a necessidade de contratar fornecedores externos de pentest. Com essa novidade, a AWS dá mais um passo no conceito de shift left — ou seja, antecipar as verificações de segurança para as etapas mais iniciais do ciclo de desenvolvimento.

Na prática, o que acontecia antes era o seguinte: mesmo com testes sob demanda disponíveis, a validação de segurança costumava ocorrer fora do fluxo de deploy. Isso criava uma lacuna: o código era publicado antes de passar por uma checagem de segurança adequada. A integração com CI/CD fecha exatamente esse gap.

Como funciona a integração

Com a nova funcionalidade, os times de desenvolvimento passam a receber os resultados dos testes diretamente na saída do pipeline. As informações incluem:

• Severidade dos achados
• Endpoints afetados
• Orientações de remediação

Alterações que não envolvem mudanças de segurança são concluídas sem atrasos relevantes. Além disso, após uma correção ser aplicada, o pipeline re-executa os testes e verifica automaticamente se o problema foi resolvido — sem necessidade de acionamento manual.

Configuração acessível, sem exigir expertise em segurança

Um ponto de destaque é a facilidade de adoção. A AWS afirma que nenhum conhecimento prévio em segurança é necessário para começar. O serviço gera automaticamente um trecho de configuração (snippet) que pode ser colado em qualquer pipeline existente, com setup estimado em menos de cinco minutos.

Na primeira execução, o contexto da aplicação é carregado automaticamente — sem necessidade de realizar um teste de penetração completo anteriormente.

Disponibilidade

O teste de penetração contínuo com integração a CI/CD já está disponível em prévia pública. Para começar, a AWS disponibiliza a documentação oficial do serviço com todas as instruções necessárias.

Fonte

AWS Continuum for Penetration Testing now supports continuous penetration testing integrated directly into your CI/CD pipeline (https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-penetration-testing/)