A AWS publicou em 24 de setembro de 2026 um guia técnico que descreve como montar agentes de inteligência artificial capazes de consultar dados espalhados por diversas contas da nuvem sem copiá-los para um repositório central. A proposta combina o Amazon Bedrock AgentCore Gateway com o Model Context Protocol (MCP) para criar uma arquitetura multi-conta na qual cada equipe mantém seus conjuntos de dados exatamente onde eles já vivem.
O dilema dos dados distribuídos
Grandes empresas querem agentes que raciocinem sobre informações dispersas por muitos ambientes. Cada time guarda seus dados em uma conta própria por motivos sólidos: clareza de propriedade, isolamento de escopo e ciclos independentes de implantação.
O problema é que um agente que enxerga apenas uma conta entrega valor limitado. Conectá-lo a fontes distribuídas normalmente exige replicar dados ou desembaraçar permissões complexas do AWS Identity and Access Management.
A Meta apresentada no artigo é deixar os dados nas contas de linha de negócio (LOB). Apenas as informações necessárias a cada requisição saem de sua conta de origem, no momento da consulta.
A conta de plataforma como plano de controle
No desenho proposto, uma conta central de plataforma hospeda a camada de agentes e a inferência de modelos de linguagem por meio do Amazon Bedrock. O agente roda no AgentCore Runtime, ambiente serverless e agnóstico de framework, com isolamento de sessão em microVMs dedicadas, cobrança por consumo e autenticação embutida.
O exemplo do tutorial usa um único agente, mas o mesmo padrão suporta vários. A equipe de plataforma controla quais modelos de base estão disponíveis, aplica guardrails do Amazon Bedrock e acompanha custos em uma fronteira única de faturamento.
Isso evita gerenciar cotas de modelo em dezenas de contas. Em organizações maiores, a inferência pode ser distribuída entre contas dedicadas, com o Gateway atuando como Inference Gateway para rotear tráfego entre provedores e aplicar limites de taxa por equipe.
O gateway como ponto único de integração
O AgentCore Gateway instalado na conta de plataforma funciona como endpoint MCP único para o agente. Ele registra o servidor MCP de cada conta LOB como um alvo.
A partir desse ponto, oferece descoberta unificada de ferramentas com busca semântica, autenticação centralizada via AgentCore Identity, autorização granular com Policy in AgentCore e observabilidade.
A integração também aceita HTTP targets, que trazem agentes do AgentCore Runtime, serviços de agente para agente (A2A) e outros endpoints HTTP para o mesmo ponto governado. Cada um fica acessível por seu próprio subcaminho.
Na prática, guardrails de conteúdo e políticas de acesso escritas em Cedar são aplicadas na camada do Gateway, fora do código do agente.
Como as áreas de negócio entram no arranjo
As equipes de linha de negócio expõem dados e ferramentas como servidores MCP, em vez de liberar recursos brutos da AWS como buckets do Amazon S3.
O material descreve o uso de acesso seguro entre contas e autorização de grão fino. Assim, o agente na conta central alcança essas fontes sem que os conjuntos de dados deixem suas contas proprietárias.
A autenticação passa pelo AgentCore Identity combinado ao Okta, o que permite vincular identidades corporativas às chamadas de ferramenta.
Por que isso importa
O padrão ataca um gargalo prático da adoção corporativa de agentes: a tensão entre governança de dados e utilidade. Ao manter cada base sob a responsabilidade de quem a produz, a arquitetura reduz duplicação, simplifica auditorias e preserva requisitos de conformidade.
Ao mesmo tempo, oferece aos desenvolvedores um catálogo único de ferramentas pesquisáveis. Outro ganho apontado é operacional: limites de uso, políticas de acesso e filtros de segurança ficam concentrados no Gateway, e não replicados em cada agente.
Para times que já operam múltiplas contas AWS, o roteiro mostra um caminho viável para levar agentes de prova de conceito a ambientes de produção com controles de governança desde o início.
