AWS Maps Out a Multi-Account Agent Pattern That Leaves Data in Each Team's Account

AWS has published a reference architecture for a problem most large enterprises hit within weeks of putting an agent in front of real business data: the data is scattered across dozens of AWS accounts owned by different teams, and nobody wants to copy it into one place. The proposed answer is a hub-and-spoke design in which each line-of-business (LOB) team publishes its data as a Model Context Protocol (MCP) server, and a central platform account fronts all of them with Amazon Bedrock AgentCore Gateway. The interesting part is not the plumbing, which is fairly conventional, but where the architecture chooses to enforce authorization — and what it admits it cannot enforce.

The shape of the architecture

According to the AWS post, the design splits into three layers. A platform account runs the agent on AgentCore Runtime — described as a serverless, framework-agnostic environment with session isolation in dedicated microVMs, consumption-based pricing and built-in authentication — and handles large language model inference through Amazon Bedrock. The walkthrough uses a single Strands agent, though AWS says the pattern supports several agents in the same account.

Each LOB account hosts its own MCP server, also on AgentCore Runtime, built with FastMCP and deployed through the AgentCore CLI. AWS's example uses a retail banking team exposing tools such as get_balance and get_profile, and a lending team exposing get_credit_score plus a search_lending_policies tool that runs retrieval against Amazon Bedrock Knowledge Bases over policy PDFs stored in Amazon S3 with Amazon OpenSearch Serverless indexing. Structured lookups hit local Amazon DynamoDB tables.

Between them sits AgentCore Gateway, registered in the platform account, which aggregates each LOB MCP server as a target behind one endpoint. The agent connects to the Gateway as if it were a single MCP server and finds tools through tools/list, with semantic search over the aggregated tool set. AWS notes the agent also queries AWS Agent Registry — which the post labels a preview — at startup to discover registered LOB servers. Onboarding a new LOB means adding a Gateway target; the agent picks up the new tools on its next listing call.

Centralizing inference in the platform account is justified on governance grounds: one team controls which foundation models are available, applies Amazon Bedrock Guardrails once, and keeps a single billing boundary rather than managing model quotas in dozens of accounts. AWS mentions that larger organizations sometimes split inference across dedicated inference accounts with the Gateway acting as an "Inference Gateway" that routes across model providers and applies per-team rate limits. No detail on how that routing decision is made is given beyond "based on the request."

Two authorization layers, and one deliberate gap

The security story has two independent checkpoints, which is the strongest part of the design.

At the hub, the Gateway is configured with a Custom JWT authorizer pointing at Okta's OIDC discovery URL and validating the audience claim. The agent forwards the end user's JWT, and Policy in AgentCore — which uses the Cedar policy language — evaluates the token's claims in ENFORCE mode before any tool call is routed. AWS stresses that Cedar is default-deny: only explicitly permitted actions succeed. The sample policies permit read-only banking tools for all authenticated users and forbid a delete_customer action outright.

At the spoke, each LOB team configures a customJWTAuthorizer on its own Runtime deployment, validating inbound tokens against the identity provider. AWS makes the ownership point explicitly: a Gateway target alone is not enough, because the LOB server rejects requests it hasn't been configured to accept, and that decision belongs to the data owner rather than the platform team. For production, AWS recommends setting allowedWorkloadConfiguration to the Gateway's ARN so the Runtime only accepts calls whose identity chain includes that Gateway — closing the path where someone invokes a LOB server directly and skips Cedar entirely. The sample itself relies on OAuth audience validation as its primary control, which is weaker.

The gap is in outbound auth. The Gateway retrieves OAuth 2.0 machine-to-machine credentials from AgentCore Identity and attaches them to the call, so the LOB server sees the platform's service identity, not the user's. AWS is upfront that this is why user-level authorization has to happen at the Gateway. It points to on-behalf-of token exchange as the alternative for tools that need per-user enforcement such as row-level security, and says the sample uses M2M because the Okta developer account used for the walkthrough does not support the OBO flow. That is a meaningful caveat for anyone planning to reuse this pattern where the data itself is row-scoped: you would be re-implementing the user's entitlements in Cedar rules at the hub, away from the system that actually knows them.

What "data doesn't leave the account" really means

AWS frames the benefit as data staying in its owning account, with only the specific result a request needs flowing out at query time. That is accurate as far as it goes — the raw DynamoDB tables, S3 buckets and knowledge bases are not replicated — but the derived output does cross the account boundary and becomes context for inference in the platform account. For teams treating account boundaries as a compliance or residency control, the relevant question is whether tool outputs are in scope, not whether the source tables moved. The post does not address retention of that context, and no data-residency or regulatory claims are made.

The end-to-end request path adds more moving parts than the three-layer diagram suggests: a React web app authenticating through Okta, Amazon CloudFront, a FastAPI backend on Amazon ECS with AWS Fargate applying Bedrock Guardrails for PII redaction on both input and output, then the agent, then Bedrock, then the Gateway, then the LOB server. Each hop is a latency and failure contributor. AWS publishes no latency figures, cost figures or evaluation scores for the sample.

Operating it

The operations guidance is more concrete than most reference architectures. AWS describes AgentCore Evaluations with two modes: online evaluation that continuously scores a sample of production traffic — the post's example is 10 percent of sessions — using built-in evaluators including Tool Selection Accuracy, Correctness and Goal Success Rate, with results surfacing in the CloudWatch-backed AgentCore Observability dashboard; and an on-demand API for CI/CD that replays a fixed dataset of scenarios, expected responses and tool trajectories. Because both modes share evaluators, AWS argues teams gate on the same signal they monitor. The stated failure mode worth catching is an agent quietly routing queries to the wrong LOB — something latency and error-rate dashboards would miss.

Rollouts use Runtime endpoints pinned to versions, with A/B traffic splitting through the Gateway and promotion "once results reach statistical significance," a threshold the post leaves to the reader. A separate AgentCore Optimization capability is said to analyze production traces and recommend prompt and tool-description changes. AWS also notes that LOB servers are unaffected by agent prompt or model changes as long as the MCP tool interface holds — which quietly makes tool schemas the real contract to version.

One production caveat is stated plainly: the implementation uses the default public network mode, where traffic crosses the public internet over HTTPS with OAuth. AWS says that suits development but not production, and points to VPC connectivity via elastic network interfaces and interface VPC endpoints over AWS PrivateLink for private ingress.

The repository deploys via AWS CDK across four accounts and requires AWS Organizations, Bedrock model access, AgentCore in every account, and an OIDC provider with M2M app clients. Cost attribution back to the LOB that triggered a call is listed as a governance requirement, but the mechanism is not described in the available text.

What to watch

• Whether on-behalf-of token exchange becomes the default in this pattern. Until it does, per-user data authorization has to live in Cedar at the hub rather than in the system that owns the rows.
• Whether allowedWorkloadConfiguration gets promoted from production hardening advice into the sample itself. As shipped, audience validation is the primary gate.
• MCP version pinning. The Gateway config in the post declares support for a single protocol version, and MCP is still moving; spec churn across dozens of independently owned spokes is an operational cost nobody has priced yet.
• AWS Agent Registry's path out of preview, since dynamic discovery of LOB servers is what makes onboarding a config change rather than a code change.
• Real numbers. AWS discloses no latency, cost or evaluation results for this architecture, and consumption-based pricing across Runtime, Gateway, Bedrock inference and Evaluations makes the total hard to estimate from the post alone.