User's blog

Governe o acesso de agentes de IA com o Amazon Bedrock AgentCore Gateway

Written by

Make.com Service User

in

O problema que ninguém quer admitir

Imagine um engenheiro de infraestrutura abrindo o laptop de um colega para depurar uma build. Na pasta de configuração, um arquivo chamado mcp.json contém uma senha de banco de dados de produção em texto puro, ao lado de um comentário TODO: rotate this. A equipe de segurança não tem visibilidade de quais agentes de IA estão acessando ferramentas internas, quem concedeu esse acesso, nem qual seria o impacto se aquela credencial vazasse.

Esse cenário representa um padrão recorrente em empresas que adotam assistentes habilitados com o Protocolo de Contexto de Modelo (MCP) — como Kiro, Claude Code e Amazon Quick — sem uma camada centralizada de governança. A AWS identificou cinco padrões de falha estrutural nesse cenário: espalhamento de credenciais em configs locais, divergência silenciosa de políticas, lacunas de auditoria, opacidade de custos e Shadow IT.

Para endereçar isso, a AWS documentou uma abordagem progressiva usando o AgentCore Gateway, uma capacidade do Amazon Bedrock AgentCore que fornece um ponto de entrada único, seguro e auditável para o tráfego de agentes em direção às ferramentas corporativas.

A jornada de maturidade em quatro escopos

A proposta da AWS não é construir tudo de uma vez — é avançar conforme as dores reais aparecem. Cada escopo entrega valor independente e preserva o caminho para o próximo.

Imagem original — fonte: Aws

Escopo 1 — Connect: a porta governada mínima

Indicado para pilotos com 1 a 20 usuários e ferramentas de baixo risco. O objetivo é simples: criar um único ponto de entrada para que os agentes de IA cheguem aos recursos organizacionais, com autenticação via SSO (Entrada Única), credenciais centralizadas e auditoria pelo AWS CloudTrail.

Na prática, o gateway é provisionado com um autorizador JWT (Token Web JSON) apontando para um pool do Amazon Cognito. Uma função AWS Lambda de baixo risco — como uma busca de tickets somente leitura — é registrada como alvo MCP. O arquivo mcp.json dos assistentes passa a apontar para o endpoint do gateway em vez de servidores locais. As credenciais de backend nunca saem da AWS, e toda invocação aparece nos logs do Amazon CloudWatch.

O comando para criar o gateway com autorizador JWT é:

aws bedrock-agentcore-control create-gateway \
  --name pilot-gateway \
  --role-arn arn:aws:iam::<account-id>:role/GatewayRole \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration '{
    "customJWTAuthorizer": {
      "discoveryUrl": "https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/openid-configuration",
      "allowedClients": ["pilot-gateway-client"]
    }
  }'

O registro de um alvo Lambda como ferramenta MCP é feito assim:

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier pilot-gateway \
  --name TicketSearch \
  --target-configuration '{
    "mcp": {
      "lambda": {
        "lambdaArn": "arn:aws:lambda:<region>:<account-id>:function:ticket-search",
        "toolSchema": {"inlinePayload": "<tool-schema-json>"}
      }
    }
  }'

O resultado: o caminho fim a fim funciona, o mcp.json agora contém um endpoint que alcança recursos organizacionais, e produtividade e controles chegam juntos.

Escopo 2 — Control: autorização por identidade e guardrails

Com a porta aberta, o Escopo 2 identifica quem está chamando e filtra o que passa. É indicado quando a base de usuários cresce e a conformidade começa a perguntar “quem fez o quê, sob qual política?”

A mudança central é migrar de confiança no nível de máquina para confiança no nível de usuário. Os clientes passam a ser registrados dinamicamente via Registro Dinâmico de Clientes (DCR) — um shim Lambda que cria um app client no Cognito e o adiciona à lista de clientes permitidos do gateway. O usuário se autentica via SSO com fluxo de Código de Autorização (Authorization Code), e a partir daí cada requisição carrega a identidade real do usuário.

O AgentCore Policy aplica regras Cedar com controle de acesso baseado em papéis (RBAC) e atributos (ABAC). Por exemplo, a política abaixo restringe deploys de CI ao ambiente de staging para membros do grupo de pagamentos, enquanto mantém ferramentas de leitura abertas para qualquer principal autenticado:

// Payments deployers can deploy, but only to staging
permit (
  principal,
  action == AgentCore::Action::"DeployCI___invoke",
  resource
)
when {
  principal.hasTag("groups") &&
  principal.getTag("groups").contains("repo-payments-service")
  /* Note: for Cognito, the claim is cognito:groups, not groups.
     Refer to your deployed Gateway Cedar schema for the precise tag names. */
  && context.input.environment == "staging"
};

// Read-only tools are open to any authenticated principal with a group
permit (
  principal,
  action in [
    AgentCore::Action::"TicketSearch___invoke",
    AgentCore::Action::"DocsSearch___invoke"
  ],
  resource
)
when {
  principal.hasTag("groups")
};

O Amazon Bedrock Guardrails é integrado nativamente ao AgentCore Policy para aplicar filtros de Informações de Identificação Pessoal (PII), políticas de conteúdo e detecção de ataques de prompt na camada do gateway, sem código customizado. A configuração abaixo, por exemplo, bloqueia números de CPF/SSN e cartões de crédito, e anonimiza e-mails:

{
  "contentPolicyConfig": {
    "filtersConfig": [{
      "type": "PROMPT_ATTACK",
      "inputStrength": "HIGH",
      "outputStrength": "NONE"
    }]
  },
  "sensitiveInformationPolicyConfig": {
    "piiEntitiesConfig": [
      { "type": "EMAIL", "action": "ANONYMIZE" },
      { "type": "US_SOCIAL_SECURITY_NUMBER", "action": "BLOCK" },
      { "type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK" }
    ]
  }
}

A recomendação é implantar o AgentCore Policy primeiro em modo LOG_ONLY para monitorar quais decisões mudariam antes de ativar o modo ENFORCE. Quando um recurso downstream precisa da identidade do usuário em um sistema SaaS (como GitHub ou Slack), o AgentCore Identity gerencia o fluxo de três pernas (3LO), emitindo um erro de elicitação -32042 para que o assistente conduza o usuário pelo consentimento no navegador. Para recursos que compartilham a mesma cadeia de identidade, o On-Behalf-Of (OBO) token exchange substitui o redirecionamento pelo navegador, sem fluxo adicional de consentimento.

Escopo 3 — Catalog: autoatendimento, registro e alcance multi-ambiente

Quando os tickets de “adicione esta ferramenta” se acumulam ou é preciso alcançar sistemas fora da AWS, é hora do Escopo 3. Indicado para mais de 100 usuários, esse escopo elimina o gargalo de cadastro manual de ferramentas.

Imagem original — fonte: Aws

Os donos de ferramentas passam a criar um manifesto YAML e abrir um pull request. O pipeline de CI valida, escaneia e, no merge, chama create-gateway-target e atualiza a política Cedar automaticamente. Um exemplo de manifesto:

# registry/tools/payment-refund.yaml
name: PaymentRefund
owner: payments-platform@example.com
target:
  type: lambda
  arn: arn:aws:lambda:us-west-2:<account-id>:function:payment-refund
access:
  allowed_groups: [finance-ops, senior-support]
  environments: [staging] # prod requires separate approval
risk_tier: high

O AWS Agent Registry centraliza a descoberta de ferramentas e habilidades. Um servidor Resources MCP distribui automaticamente para todos os assistentes contextos organizacionais como padrões de código, runbooks de plantão e checklists de release — sem configuração por desenvolvedor.

Para sistemas fora da AWS, o gateway alcança bancos de dados on-premises via AWS Direct Connect ou VPN, e APIs SaaS via OAuth de saída. O Open Policy Agent (OPA) complementa o Cedar com regras que ele não expressa nativamente, como janelas de tempo e verificação de ticket de mudança. A política Rego abaixo, por exemplo, permite escrita em banco de dados somente em dias úteis, das 9h às 17h UTC, com ticket de mudança anexado:

package mcp.tools
import rego.v1

default allow := false

allow if {
  input.tool == "db_write"
  clock := time.clock(time.now_ns())
  clock[0] >= 9
  clock[0] < 17
  weekday := time.weekday(time.now_ns())
  not weekday in {"Saturday", "Sunday"}
  input.claims.change_ticket_id != ""
}

Para FinOps, tags por ferramenta no AWS Cost Explorer permitem que o financeiro atribua gastos ao time responsável. Um alerta de AWS Budgets pode ser configurado por ferramenta com um limite mensal de custo de invocação.

Escopo 4 — Harden: resiliência e governança de borda

Para workloads com mais de 1.000 usuários, indústrias reguladas ou requisitos de alta disponibilidade global, o Escopo 4 endurece o perímetro e prepara o gateway para falhas.

O tráfego passa a fluir pela rede corporativa: Amazon CloudFront na borda → Application Load Balancer restrito ao CloudFront via header secreto → VPC Endpoint em subnet privada → PrivateLink → gateway. O DNS público é eliminado. Para agentes hospedados em Runtime, a AWS recomenda ativar enforcement de entrada exclusiva, de modo que o Runtime rejeite qualquer invocação que não venha pelo gateway, impedindo contornos à política e à auditoria.

O failover multi-região é configurado via Amazon Route 53 com health checks. O registro de failover abaixo alterna para a região secundária quando o health check primário falha, dentro de um TTL de 30 segundos:

[
  {
    "Name": "gateway.example.com.",
    "Type": "CNAME",
    "SetIdentifier": "primary-us-west-2",
    "Failover": "PRIMARY",
    "TTL": 30,
    "HealthCheckId": "hc-0123456789abcdef0",
    "ResourceRecords": [{"Value": "dxxxxxxxxxxxxx.cloudfront.net"}]
  },
  {
    "Name": "gateway.example.com.",
    "Type": "CNAME",
    "SetIdentifier": "secondary-eu-west-1",
    "Failover": "SECONDARY",
    "TTL": 30,
    "ResourceRecords": [{"Value": "dyyyyyyyyyyyyy.cloudfront.net"}]
  }
]

Uma Lambda noturna de deprecação lê métricas do CloudWatch e abre pull requests automaticamente para ferramentas com zero invocações nos últimos 30 dias. Após 90 dias sem uso, o alvo é removido — eliminando ferramentas zumbi do registry.

Para responder perguntas de conformidade como “quais principals tiveram maior taxa de negação na última semana?”, o Amazon Athena consulta os logs do CloudTrail:

SELECT
  attributes.`aws.agentcore.policy.determining_policies` as policies,
  COUNT(*) AS denies,
  DATE_TRUNC('day', from_iso8601_timestamp(event_time)) AS day
FROM aws_spans_export
WHERE
  attributes.`aws.agentcore.policy.authorization_decision` = 'DENY'
  AND from_iso8601_timestamp(event_time) > current_date - INTERVAL '7' DAY
GROUP BY principal, matched_policy, DATE_TRUNC('day', from_iso8601_timestamp(event_time))
ORDER BY denies DESC
LIMIT 25;

Referência de implantação: caso de serviços financeiros

A AWS documentou como uma organização de serviços financeiros percorreu os quatro escopos em seis meses: começou no Escopo 1 com dois analistas e uma ferramenta SQL de staging; evoluiu para o Escopo 2 em três semanas com 30 analistas, RBAC por mesa de operação e auditoria completa; chegou ao Escopo 3 no terceiro mês com 200 usuários e queda de ~40% na fila de tickets; e completou o Escopo 4 no sexto mês com 1.000 usuários, isolamento de rede exigido pela MiFID II e RTO de 4 horas via Route 53 failover. O gatilho para avançar cada escopo foi sempre uma pergunta organizacional concreta, não um prazo predefinido.

Considerações operacionais e de custos

A AWS recomenda tratar o gateway com as mesmas práticas operacionais de serviços de produção desde o primeiro dia. Ambientes de dev, staging e produção devem rodar em contas AWS separadas, promovidos via Infraestrutura como Código (IaC).

Em segurança, credenciais devem ser armazenadas no AWS Secrets Manager com rotação, ou eliminadas com autenticação por Chave Privada JWT (private key no AWS KMS). Nunca em variáveis de ambiente. O mcp.json deve ser distribuído centralmente via MDM. Políticas de Controle de Serviço (SCPs) do AWS IAM com a condição aws:ViaAWSMCPService bloqueiam operações destrutivas invocadas por servidores MCP gerenciados pela AWS.

Em custos, a referência da AWS aponta que ~50 desenvolvedores executando 572.000 operações mensais custam aproximadamente US$ 17 combinando Gateway e Policy (Gateway InvokeTool a US$ 5 por milhão + Policy authorization a US$ 25 por milhão; Identity custa US$ 0 quando consumido pelo Gateway). Consulte a página de preços do Amazon Bedrock AgentCore para valores atualizados.

Limpeza de recursos

Para evitar cobranças contínuas após testes, a AWS recomenda remover os recursos na ordem inversa da criação. Os comandos principais incluem deletar targets com DeleteGatewayTarget e o gateway em si:

aws bedrock-agentcore-control delete-gateway --gateway-identifier pilot-gateway

Veja DeleteGateway para a referência completa da API.

Leituras complementares

Fonte

Govern AI agent tool access with Amazon Bedrock AgentCore Gateway (https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts