AWS AgentCore Gateway as a multi-account MCP hub

An agent that can only read one team's data is of limited use. The usual fixes are copying data into one place or wiring cross-account access by hand. AWS published a third option on September 24, 2026: each team keeps its data in its own AWS account and exposes it as an MCP server, and one AgentCore Gateway in a central platform account becomes the single MCP endpoint the agent talks to.

The source is the AWS Machine Learning blog post Build a multi-account AI agent with AgentCore Gateway and MCP, with a four-account reference repository built around a sample bank. Product scope comes from the AgentCore Gateway developer guide. This post explains the pattern and where it sits next to proxy gateways and self-hosted agents. It is not an AWS review.

Use a central gateway with per-team MCP servers when several teams own data that must stay put, and one agent has to query across them. The pattern gives you one endpoint for tool discovery, user identity carried to the gateway, a default-deny policy check before each tool call, and a second check at each team's server. Each team still decides what its tools expose and who may call them. The gateway does not replace server-side authorization, idempotency, or human approval for money-moving actions.

AWS splits the design into three parts:

• Platform account. The platform team runs the agent on AgentCore Runtime and runs model calls through Amazon Bedrock. Model access, Bedrock Guardrails, and the model bill all sit in this one account.
• Line-of-business (LOB) accounts. Each team packages its data as an MCP server instead of handing out raw S3 buckets, databases, or knowledge bases. In the sample, retail banking exposes tools like `get_balance` and `get_profile`, and lending exposes `get_credit_score` and `search_lending_policies`. Each server is built with FastMCP and runs on AgentCore Runtime in the team's own account.
• AgentCore Gateway. The gateway in the platform account registers each team's MCP server as a target. The agent connects to the gateway as one MCP server and finds tools through `tools/list` and semantic search. Adding a team means adding a gateway target. The agent sees the new tools on its next `tools/list` call.

AWS calls this hub and spoke. Each LOB server speaks MCP over Streamable HTTP. A tool returns only the result for that request, so the source tables and documents never leave the owning account.

The walkthrough traces a user question end to end:

1. 1The user signs in through Okta and gets a JWT with identity claims such as subject, groups, and audience.
2. 2The backend runs Bedrock Guardrails on the input for PII redaction, then calls the agent on AgentCore Runtime and forwards the user's JWT.
3. 3The agent asks the model which tools to call and sends the user's JWT to the gateway.
4. 4If a policy engine is attached, Policy in AgentCore checks the JWT claims against Cedar rules and permits or denies each tool call by user, role, or action.
5. 5For allowed calls, the gateway gets an OAuth 2.0 machine-to-machine token from AgentCore Identity and sends it to the right team's MCP server.
6. 6That server validates the token against Okta before running the tool. Results come back through the gateway to the agent, and Guardrails run again on the output.

The important detail is in step 5. The outbound call uses a machine-to-machine token, so the team's server sees the platform's identity, not the end user's. AWS says plainly that user-level authorization is enforced at the gateway in this setup. When a team's tool must enforce per-user access itself, such as row-level security, AgentCore Identity offers on-behalf-of token exchange so the downstream token carries both the agent and the user. The sample skips that only because the Okta developer account it used does not support the flow.

The design has two separate places that can say no.

The first is the gateway. Policy in AgentCore runs in ENFORCE mode with Cedar permit and forbid statements, and it is default-deny: only actions with an explicit permit succeed. The AWS example permits read-only tools such as `get_balance` for any signed-in user, keeps writes such as `transfer_funds` to a named role, and forbids `delete_customer` for everyone.

The second is the team's own server. Each LOB server has a JWT authorizer that only accepts tokens from the identity provider and audience the team chose. AWS notes that this approval is independent of the platform team. If the platform adds a gateway target the team never agreed to, the server still rejects the calls.

AWS also flags a gap in the sample. It relies on OAuth audience checks. For production, they recommend setting `allowedWorkloadConfiguration` on each team's runtime to the gateway's ARN, so the server only accepts calls whose identity chain includes that gateway. Without it, a caller holding a valid token could reach the server directly and skip the Cedar rules.

• Network. The sample uses public endpoints over HTTPS with OAuth. AWS says that suits development, not production, and points to VPC connectivity for Runtime and PrivateLink endpoints for gateway ingress.
• Guardrails. Because model calls are central, one Guardrails setup covers the agent. AWS also describes a newer option of attaching Guardrails as policies on the gateway itself.
• Audit. Gateway log delivery to CloudWatch Logs captures tool calls and request metadata. CloudTrail records control-plane changes by default, and per-call data events need an advanced event selector. An organization trail can pull every account's logs into one logging account.
• Cost. Each team's data and server costs stay in its own account. Model and gateway costs land in the platform account and can be charged back with cost allocation tags on the agent's execution role.
• Change safety. AgentCore Evaluations can score a sample of live sessions and replay a fixed test set on every change, and the gateway can split traffic between agent versions for A/B tests.

The gateway guide also lists other target types: OpenAPI, Smithy, and Lambda converted into MCP tools, HTTP and agent-to-agent passthrough, and model routing across providers. The multi-account post only needs MCP server targets.

Our post on MCP gateway enforcement before tool calls covered a proxy that sits between developer tools such as Cursor or Claude Code and the MCP servers they already use. That design prunes risky tools, keeps raw secrets away from the agent, and audits every call across a company's laptops.

The AgentCore pattern starts from the other end. The platform team builds one agent, and the gateway decides which team servers that agent may reach for which user. Both put a check in front of the tool call. The proxy governs many clients pointing at many servers. The AgentCore hub governs one agent tier reaching servers that other teams own, across AWS account lines.

AWS's walkthrough uses a Strands agent on AgentCore Runtime. It does not name OpenClaw, Hermes, or Grok Bot, and this post does not claim they are supported AgentCore clients.

The design question still carries over. OpenClaw and Hermes are runtimes you operate, and you already decide which tools and MCP servers they can reach. See OpenClaw vs Hermes Agent and trust boundaries for self-hosted agents. If a self-hosted agent has to reach data owned by several teams, the same split is worth copying: one place that checks the user before each tool call, and each team's server checking the caller again. Pick that place on purpose instead of letting every agent config hold its own list of servers and tokens.

1. 1List the teams whose data the agent needs and confirm each one will own and run its MCP server.
2. 2Keep tools narrow and typed. A tool should return the answer for one request, not a dataset export.
3. 3Decide whether user identity must reach the team's server. If a tool needs row-level rules, plan for on-behalf-of exchange instead of a shared machine token.
4. 4Write Cedar rules as default-deny. Permit reads broadly, limit writes to named roles, forbid destructive tools outright.
5. 5Set `allowedWorkloadConfiguration` on each team runtime so calls must come through the gateway.
6. 6Move off public endpoints before production.
7. 7Turn on gateway data logging and an organization trail so cross-account calls can be traced.
8. 8Keep human approval for money-moving or irreversible actions. See finance AI agents and human approval gates and AI agent permissions and human approval.

For the server side, how to secure an MCP server for production covers authorizing every request, and local vs remote MCP servers covers when a remote server is the right shape.

OrchestriAI does not operate AWS accounts for this pattern. MCP development builds the narrow, typed team servers the gateway routes to. AI agent systems define which tools the agent may call and where a person approves. Systems integration handles the identity, token, and logging work between accounts.

OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Amazon Web Services, Okta, OpenClaw, or Nous Research / Hermes. This article summarizes the AWS Machine Learning blog post Build a multi-account AI agent with AgentCore Gateway and MCP (September 24, 2026), its reference repository, and the AgentCore Gateway developer guide as of early October 2026. Some pieces the post mentions, such as AWS Agent Registry, are labeled preview. Features, limits, and pricing can change, so confirm current AWS documentation before you size a rollout. This is not a security certification or a compliance conclusion.