O problema: agentes de IA que precisam enxergar além de uma única conta
Empresas que operam em múltiplas contas AWS enfrentam um dilema clássico com agentes de IA: cada time mantém seus dados na própria conta por razões legítimas — isolamento de escopo, ciclos de deploy independentes e propriedade clara dos recursos. Mas um agente restrito a uma única conta entrega valor limitado. A alternativa tradicional de replicar ou centralizar dados cria problemas de governança, custo e conformidade.
A AWS publicou uma arquitetura de referência que resolve esse impasse usando o Amazon Bedrock AgentCore Gateway em conjunto com o Model Context Protocol (MCP). A ideia central é simples: os dados ficam onde já estão, em cada conta de linha de negócio (LOB — Line of Business), e apenas o resultado específico de uma consulta trafega para a conta central no momento da requisição. Nenhum dataset sai da conta que o possui.
Visão geral da arquitetura
A solução segue um modelo de três camadas: uma conta de plataforma central, contas LOB distribuídas e o AgentCore Gateway como camada de integração entre elas.
Conta de plataforma — o plano de controle do agente
A conta de plataforma executa o agente no AgentCore Runtime, um ambiente serverless e agnóstico de framework com isolamento de sessão em microVMs dedicadas, precificação por consumo e autenticação integrada. A inferência do Modelo de Linguagem de Grande Escala (LLM — Large Language Model) roda nessa conta via Amazon Bedrock, e o time de plataforma controla os Modelos Fundamentais (FM — Foundation Models) disponíveis, aplica o Amazon Bedrock Guardrails e consolida custos em um único limite de faturamento.
O AgentCore Gateway, também na conta de plataforma, funciona como o único endpoint MCP para o agente. Ele registra cada servidor MCP das contas LOB como um alvo e, a partir desse ponto único, oferece descoberta de ferramentas com busca semântica, autenticação centralizada via AgentCore Identity, autorização granular com Policy in AgentCore e observabilidade.
Além de agregar servidores MCP, o Gateway suporta outros tipos de alvo. Os alvos HTTP permitem incluir agentes AgentCore Runtime, serviços agente-a-agente (A2A) e outros endpoints HTTP no mesmo ponto governado. O time de plataforma pode ainda aplicar o Amazon Bedrock Guardrails para segurança de conteúdo e configurar o Policy in AgentCore com Cedar para controle de acesso granular — tudo isso na camada do Gateway, fora do código do agente.
Contas LOB — dados e ferramentas
Em vez de expor recursos AWS brutos como buckets do Amazon Simple Storage Service (Amazon S3), bancos de dados ou Amazon Bedrock Knowledge Bases, cada time LOB empacota seus dados e ferramentas como um servidor MCP. O time de banco de varejo, por exemplo, expõe ferramentas como get_balance e get_profile. O time de crédito oferece get_credit_score e search_lending_policies, sendo que esta última executa Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) sobre documentos PDF de políticas bancárias via Amazon Bedrock Knowledge Bases.
Para novas implementações, é possível conectar um Amazon Bedrock Managed Knowledge Base diretamente ao Gateway como conector nativo, eliminando a necessidade de operar infraestrutura de recuperação própria.
Cada servidor MCP roda no AgentCore Runtime da conta LOB, o que dá ao time completo controle sobre sua superfície de ferramentas: eles decidem o que expor e qual lógica de negócio roda por trás de cada ferramenta, podendo mudar a implementação sem afetar o agente da plataforma, desde que a interface MCP permaneça consistente.
Integração entre contas: como Gateway e Identity conectam as camadas
A arquitetura segue um padrão hub-and-spoke: cada LOB implanta um servidor MCP independente (o spoke) usando MCP sobre Streamable HTTP, enquanto o AgentCore Gateway (o hub) os agrega por trás de um único endpoint. Quando o agente invoca uma ferramenta, o Gateway recupera credenciais OAuth 2.0 máquina-a-máquina (M2M) do AgentCore Identity, as anexa à requisição de saída e a roteia para o servidor MCP LOB correto. Esse servidor valida o token contra o endpoint OpenID Connect (OIDC) do Okta antes de processar a requisição localmente. Os dados da fonte nunca são copiados ou relocados.
Fluxo completo de uma requisição
O fluxo a seguir ilustra como uma pergunta do usuário atravessa os limites de conta, invoca ferramentas distribuídas e retorna uma resposta unificada:
- O usuário faz login via webapp React, que redireciona para o Okta para autenticação. O Okta valida as credenciais e retorna um Token Web JSON (JWT — JSON Web Token) com claims de identidade.
- O usuário envia um prompt pelo webapp, que chega ao Amazon CloudFront via HTTPS. O CloudFront encaminha a requisição ao backend FastAPI rodando no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate.
- O backend aplica o Amazon Bedrock Guardrails para redação de Informações de Identificação Pessoal (PII — Personally Identifiable Information) na entrada do usuário e na saída do agente.
- O backend invoca o Strands Agent no AgentCore Runtime, encaminhando o JWT do usuário no cabeçalho Authorization para propagação de identidade.
- O agente envia o prompt ao Amazon Bedrock para raciocínio e determina quais ferramentas invocar.
- O agente encaminha o JWT do usuário ao AgentCore Gateway, que usa busca semântica para descoberta de ferramentas entre os alvos LOB. O Policy in AgentCore (quando um motor de políticas está associado ao Gateway) avalia os claims do JWT contra regras Cedar e permite ou nega cada chamada de ferramenta por identidade, papel ou ação.
- Para chamadas permitidas, o Gateway recupera credenciais OAuth 2.0 M2M do AgentCore Identity e encaminha a requisição ao servidor MCP LOB correto, que valida o token OAuth antes de processar.
- O servidor MCP LOB executa a lógica da ferramenta: contra tabelas locais do Amazon DynamoDB para consultas de dados estruturados e, para o LOB de Crédito e Patrimônio, também realiza recuperação RAG contra o Amazon Bedrock Knowledge Bases sobre PDFs de políticas armazenados no Amazon S3.
- Os resultados fluem de volta pela mesma cadeia (LOB → Gateway → Agente → Backend).
Em produção, o time LOB configura allowedWorkloadConfiguration para restringir invocações do runtime apenas a requisições cuja cadeia de identidade inclua o Gateway, reduzindo o risco de acesso direto que contorne as políticas e a autorização Cedar.
O Strands Agent descobre ferramentas LOB pelo método tools/list do Gateway e consulta o AWS Agent Registry (Preview) na inicialização para descobrir servidores MCP LOB registrados. Integrar um novo LOB é simples: basta adicionar um alvo ao Gateway — o agente descobre as novas ferramentas na próxima chamada tools/list.
Implementação técnica
Servidores MCP nas contas LOB
Cada time LOB constrói um servidor MCP com FastMCP e o implanta no AgentCore Runtime usando a AgentCore CLI, expondo os dados como ferramentas estruturadas com entradas e saídas tipadas. Cada servidor é configurado com um customJWTAuthorizer que autentica tokens OAuth de entrada contra o endpoint de descoberta OIDC do Okta.
O trecho abaixo mostra o servidor MCP do LOB de Crédito e Patrimônio, combinando consultas ao Amazon DynamoDB com recuperação via Amazon Bedrock Knowledge Bases:
REGION = os.environ.get("AWS_REGION", "us-east-1")
dynamodb = boto3.resource("dynamodb", region_name=REGION)
bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name=REGION)
KNOWLEDGE_BASE_ID = os.environ.get("KNOWLEDGE_BASE_ID", "")
mcp = FastMCP("lending-wealth", host="0.0.0.0", stateless_http=True)
@mcp.tool()
def get_credit_score(customer_id: str) -> dict:
"""Get credit score and contributing factors for a customer."""
table = dynamodb.Table("CreditScores")
resp = table.get_item(Key={"customer_id": customer_id})
item = resp.get("Item")
if not item:
return {"error": f"No credit score found for customer {customer_id}"}
return item
@mcp.tool()
def search_lending_policies(query: str) -> str:
"""Search the bank's lending policy documents for guidelines, eligibility criteria, and regulatory requirements."""
if not KNOWLEDGE_BASE_ID:
return json.dumps({"error": "KNOWLEDGE_BASE_ID not configured"})
resp = bedrock_agent_runtime.retrieve(
knowledgeBaseId=KNOWLEDGE_BASE_ID,
retrievalQuery={"text": query},
retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
)
chunks = []
for r in resp.get("retrievalResults", []):
text = r.get("content", {}).get("text", "")
source = r.get("location", {}).get("s3Location", {}).get("uri", "")
if text:
chunks.append({"text": text, "source": os.path.basename(source)})
return json.dumps({"results": chunks}, default=str)
if __name__ == "__main__":
mcp.run(transport="streamable-http")Para implantar o servidor MCP no AgentCore Runtime via CLI:
# Configure the MCP server
agentcore configure \
--entrypoint server.py \
--name lending_wealth_mcp \
--protocol MCP \
--disable-memory \
--non-interactive \
--authorizer-config '{
"customJWTAuthorizer": {
"discoveryUrl": "<OKTA_DISCOVERY_URL>",
"allowedAudience": ["lobfederation"]
}
}'
# Deploy to AgentCore Runtime
agentcore deploy --auto-update-on-conflict \
--env KNOWLEDGE_BASE_ID=<your-knowledge-base-id>Configuração do AgentCore Gateway
Na conta de plataforma, o Gateway é criado com um autorizador JWT customizado apontando para o endpoint de descoberta OIDC do Okta:
ctrl.update_gateway(
gatewayIdentifier=gateway_id,
name="lobfederation-gateway",
protocolType="MCP",
protocolConfiguration={
"mcp": {
"searchType": "SEMANTIC",
"supportedVersions": ["2025-03-26"],
}
},
authorizerType="CUSTOM_JWT",
authorizerConfiguration={
"customJWTAuthorizer": {
"discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
"allowedAudience": ["lobfederation"],
}
},
)Para autenticação de saída aos servidores MCP LOB, o Gateway usa o fluxo de credenciais de cliente OAuth 2.0 (M2M). O time de plataforma registra um provedor de credenciais OAuth no AgentCore Identity e o associa a cada alvo do Gateway:
# Register an OAuth credential provider (M2M / client_credentials)
resp = ctrl.create_oauth2_credential_provider(
name="lobfederation-okta-m2m",
credentialProviderVendor="CustomOauth2",
oauth2ProviderConfigInput={
"customOauth2ProviderConfig": {
"oauthDiscovery": {
"discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration"
},
"clientId": "<M2M_CLIENT_ID>",
"clientSecret": "<M2M_CLIENT_SECRET>",
"clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
}
},
)
cred_arn = resp["credentialProviderArn"]
# Create a Gateway target for the LOB MCP server with OAuth outbound auth
ctrl.create_gateway_target(
gatewayIdentifier=gateway_id,
name="lending-wealth",
description="Lending & Wealth --- loans, credit scores, eligibility, policy search",
targetConfiguration={
"mcp": {
"mcpServer": {
"endpoint": f"https://bedrock-agentcore.{REGION}.amazonaws.com/runtimes/{encoded_runtime_arn}/invocations",
}
}
},
credentialProviderConfigurations=[
{
"credentialProviderType": "OAUTH",
"credentialProvider": {
"oauthCredentialProvider": {
"providerArn": cred_arn,
"scopes": ["lobfederation.invoke"],
"grantType": "CLIENT_CREDENTIALS",
}
},
}
],
)Quando uma ferramenta LOB precisa aplicar controle de acesso por usuário (como segurança em nível de linha), o AgentCore Identity também oferece a troca de token on-behalf-of (OBO), onde o Gateway troca o token do usuário de entrada por um token com escopo downstream que carrega a identidade tanto do agente quanto do usuário. O AgentCore Gateway também suporta o fluxo de código de autorização e chaves de API — veja os exemplos de autenticação de saída do AgentCore Gateway.
Implantação do agente
O agente Strands é implantado no AgentCore Runtime com um autorizador JWT customizado para autenticação de entrada. Em tempo de execução, o agente lê o JWT do usuário nos cabeçalhos da requisição de entrada e o passa ao AgentCore Gateway, propagando a identidade do usuário final até o motor de políticas Cedar:
@app.entrypoint
def invoke(payload, context=None):
prompt = payload.get("prompt", "Hello")
# Read the user's JWT from inbound request headers (passed through by Runtime)
request_headers = context.request_headers if context else {}
user_jwt = request_headers.get("Authorization", "")
# Connect to Gateway with the user's JWT --- Cedar evaluates per-user policies
mcp_client = MCPClient(
lambda: streamablehttp_client(
url=GATEWAY_URL,
headers={"Authorization": user_jwt},
)
)
with mcp_client:
tools = mcp_client.list_tools_sync()
agent = Agent(model=MODEL_ID, system_prompt=SYSTEM_PROMPT, tools=tools)
result = agent(prompt)Operação do agente: avaliação, versionamento e observabilidade
Avaliação contínua
Em uma arquitetura multi-conta onde o agente orquestra ferramentas de vários LOBs, é essencial garantir que ele continue funcionando corretamente conforme ferramentas, modelos e prompts evoluem. O AgentCore Evaluations oferece um framework gerenciado para detectar regressões antes que cheguem aos usuários.
A avaliação online pontua continuamente uma amostra do tráfego de produção (por exemplo, 10% das sessões) usando avaliadores integrados como Acurácia de Seleção de Ferramentas, Corretude e Taxa de Sucesso de Objetivos. As pontuações aparecem no dashboard do AgentCore Observability, alimentado pelo Amazon CloudWatch, com alertas quando a qualidade cai — sem necessidade de alterações no código se o agente já emite traces OpenTelemetry. Isso permite detectar degradações silenciosas que o monitoramento de latência e taxa de erros não captura.
A avaliação sob demanda é uma API em tempo real para desenvolvimento e Integração e Entrega Contínua (CI/CD). O time define um dataset de avaliação uma vez e o AgentCore Evaluations o reproduz a cada mudança. Para fechar o ciclo, o AgentCore Optimization analisa traces de produção e recomenda melhorias de prompt e descrição de ferramentas.
Versionamento seguro e testes A/B
O agente é implantado com endpoints (prod, staging, dev) que apontam para versões específicas. Quando o time de plataforma atualiza o prompt ou o modelo, publica uma nova versão e atualiza o endpoint — os servidores MCP LOB não são afetados porque a interface de ferramentas não muda. Antes de promover uma mudança, o time pode executar testes A/B pelo AgentCore Gateway, dividindo o tráfego entre a versão atual e a candidata.
Segurança, governança e gestão de custos
Acesso com privilégio mínimo e aprovação dos donos de dados
Os times LOB controlam quem pode invocar seus servidores MCP via configuração do autorizador JWT no deployment do AgentCore Runtime. Uma requisição da conta de plataforma só chega às ferramentas LOB após o time ter configurado o servidor para aceitar tokens do provedor de identidade da plataforma — aprovação independente do time de plataforma.
Autorização com Policy in AgentCore
O Gateway executa o Policy in AgentCore em modo ENFORCE, avaliando regras antes de rotear cada chamada de ferramenta. O Policy in AgentCore usa a linguagem Cedar, com regras explícitas de permit e forbid. Por exemplo:
// Permit all authenticated users to invoke read-only tools
permit(
principal is AgentCore::OAuthUser,
action in [
AgentCore::Action::"retail-banking___get_customer",
AgentCore::Action::"retail-banking___get_accounts",
AgentCore::Action::"retail-banking___get_balance",
AgentCore::Action::"tools/list",
AgentCore::Action::"initialize"
],
resource
);
// Block destructive operations regardless of user
forbid(
principal,
action == AgentCore::Action::"retail-banking___delete_customer",
resource
);Como o Policy in AgentCore usa um modelo de negação por padrão, apenas ações com um permit explícito são executadas.
Conectividade de rede e VPC
A implementação de referência usa o modo de rede pública padrão do AgentCore Runtime, com tráfego via HTTPS com OAuth — adequado para desenvolvimento, mas não para produção. Em produção, o AgentCore Runtime suporta conectividade de Nuvem Privada Virtual (VPC — Virtual Private Cloud) via Interfaces de Rede Elástica (ENIs), endpoint VPC de interface via AWS PrivateLink para ingresso privado ao Gateway e allowedWorkloadConfiguration para restringir invocações ao Gateway. Veja os padrões de conectividade de rede para o AgentCore Runtime e o ingresso seguro ao AgentCore Gateway usando endpoints VPC de interface.
Guardrails
O Amazon Bedrock Guardrails é aplicado na conta de plataforma para filtragem de conteúdo, redação de PII e restrições de tópicos. Como a inferência é centralizada, uma única configuração de guardrail cobre as interações do agente com todas as ferramentas LOB. Também é possível aplicar Guardrails como políticas diretamente no AgentCore Gateway, executando verificações na camada do Gateway, fora do código do agente.
Auditoria e conformidade
Para habilitar o logging do plano de dados, configure a entrega de logs no Gateway para o Amazon CloudWatch Logs, que captura invocações de ferramentas e metadados de requisição. O AWS CloudTrail captura operações do plano de controle por padrão. Para auditoria centralizada, configure um trail no nível da organização que agrega logs das contas de plataforma e LOB em uma conta de logging dedicada.
Atribuição de custos
A arquitetura oferece fronteiras naturais de custo. Os custos do plano de dados de cada LOB (Amazon DynamoDB, Amazon Bedrock Knowledge Bases, computação do servidor MCP) ficam na própria conta e aparecem diretamente no AWS Cost Explorer. Inferência LLM e invocações do Gateway acumulam na conta de plataforma. Para atribuí-los de volta ao LOB de origem, a role de execução do agente carrega tags (como lob ou costCenter). Após ativar a tag de alocação de custos no console de faturamento, essas tags fluem para o AWS Cost and Usage Report para chargeback por LOB. Para uma abordagem mais detalhada, veja atribuição granular de custos para o Amazon Bedrock.
Como experimentar
Para testar o padrão, clone o repositório de referência e execute o script de implantação, que inicializa o AWS Cloud Development Kit (AWS CDK) nas quatro contas, provisiona os recursos de plataforma e LOB, implanta os servidores MCP e alvos do Gateway, e lança uma aplicação web React no Amazon ECS atrás do CloudFront.
Os pré-requisitos incluem: configuração multi-conta gerenciada via AWS Organizations, acesso a modelos do Amazon Bedrock na conta de plataforma, AgentCore configurado nas contas de plataforma e LOB, um provedor de identidade compatível com OIDC (como Okta, Amazon Cognito ou Microsoft Entra ID) e as fontes de dados LOB que os servidores MCP irão encapsular.
Para evitar cobranças após o teste, execute o script de limpeza incluído no repositório. Ele remove os recursos implantados nas quatro contas — componentes AgentCore, configuração Okta, deployments de servidores MCP e stacks CDK — em ordem inversa à implantação.
Recursos relacionados
- Amazon Bedrock AgentCore — documentação
- Conectar o Amazon Bedrock AgentCore a Knowledge Bases entre contas
- Transforme sua arquitetura MCP: unifique servidores MCP pelo AgentCore Gateway
Fonte
Build a multi-account AI agent with AgentCore Gateway and MCP (https://aws.amazon.com/blogs/machine-learning/build-a-multi-account-ai-agent-with-agentcore-gateway-and-mcp/)
Leave a Reply