Amazon Bedrock AgentCore now supports a cross‑account AgentCore Gateway that lets a single agent query data and tools residing in many AWS accounts without moving the underlying datasets. This change gives platform teams a unified endpoint while keeping each line‑of‑business (LOB) account’s data under its own ownership and control.
Solution Overview
The new pattern introduces three logical layers: a central platform account that runs the agent runtime and Bedrock inference, distributed LOB accounts that host Model Context Protocol (MCP) servers, and the AgentCore Gateway that bridges them. The gateway registers each LOB’s MCP server as a target, exposing a single https://gateway.example.com endpoint for tool discovery and invocation.
Platform Account Responsibilities
In the platform account, the agent runs on AgentCore Runtime, a serverless environment that isolates sessions in microVMs and charges per use. All LLM calls are made through Amazon Bedrock in the same account, allowing the platform team to manage model selection, guardrails, and cost reporting centrally. The gateway also functions as an inference gateway when multiple inference accounts are used, routing requests to the appropriate model provider and applying per‑team rate limits.
Authentication for inbound calls is handled by AgentCore Identity, which can be federated with external providers such as Okta. Authorization is enforced by Policy in AgentCore, a Cedar‑based rule engine that evaluates each request before it reaches an MCP server. Observability hooks are built into the gateway, giving operators a single place to collect logs, metrics, and traces for all cross‑account interactions.
LOB Account Integration
Each LOB account packages its data and operational tools behind an MCP server. Rather than exposing raw S3 buckets, databases, or Bedrock knowledge bases, the LOB team implements a thin service that speaks the Model Context Protocol. The platform’s gateway registers this service as a target, which means the agent never contacts the LOB account directly; all traffic flows through the gateway.
Because data never leaves the LOB account except at query time, the ownership boundary remains intact. The gateway forwards only the specific request payload and returns the response, preserving the original data residency. Fine‑grained policy rules can restrict which agents or users may invoke particular MCP methods, and the gateway enforces those rules consistently across accounts.
Operational and Security Implications
Centralizing the entry point simplifies governance: a single set of policies, audit logs, and cost metrics covers all cross‑account activity. Teams can add or remove LOB MCP servers without redeploying agents, as the gateway dynamically updates its target registry. However, the gateway becomes a critical trust anchor; any misconfiguration in AgentCore Identity or Policy could expose data across accounts.
From an operations perspective, the platform team must monitor gateway health, latency, and error rates, as these affect every downstream LOB integration. The use of microVM isolation in AgentCore Runtime reduces blast radius for compromised sessions, but operators should still enforce least‑privilege IAM roles for the gateway’s cross‑account role assumptions.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Practitioners can now build a single Bedrock agent that reaches into multiple accounts without replicating data, but they must treat the AgentCore Gateway as a hardened integration layer. Implement robust AgentCore Identity federation, define precise Cedar policies for each MCP target, and instrument gateway observability to detect cross‑account anomalies early. When adding new LOB services, register the MCP server with the gateway and verify that policy rules limit access to only the required data. This approach consolidates cost, security, and operational visibility while preserving each team’s data ownership.
