AWS pitches a governed way to let AI agents query data across company accounts

AWS has published a reference architecture for AI agents that query data held across separate company accounts without copying the underlying datasets into one central store. The design uses Amazon Bedrock AgentCore Gateway and the Model Context Protocol to give an agent one governed endpoint for discovering and invoking tools across business units.

AWS AI Watch analysis

What happened

In AWS’s architecture guide, a central platform account runs the agent and model inference, while line-of-business accounts keep ownership of their own data and tools. Each business unit exposes selected capabilities through an MCP server, rather than opening raw S3 buckets, databases or knowledge bases to the agent.

AgentCore Gateway acts as the hub. It provides tool discovery, routes calls to the relevant account and can apply authentication, fine-grained Cedar policy, guardrails and observability. The example includes banking-style tools such as retrieving a balance, checking a credit score and searching lending policies.

The accompanying walkthrough uses Okta for identity, OAuth 2.0 machine-to-machine credentials for service calls and a user token carried through the chain. AWS says the MCP server returns only the result needed for the request, so the source data remains in the account that owns it.

Why it matters

This is a practical answer to one of the less glamorous problems in enterprise AI: how to make an agent useful across fragmented systems without turning every business database into a shared buffet. The proposed arrangement keeps data ownership and local business logic with each team, while giving the platform group a single place to govern access and track activity.

That centralisation is useful, but it is not magic. A single gateway can simplify policy and oversight while also becoming a tempting concentration point for mistakes. The architecture depends on correctly scoped tools, identity claims and authorisation rules. A model that can discover a tool is not automatically entitled to use it, a distinction worth putting in large type before somebody gives an agent the keys to the lending department.

Our read

AWS is selling architecture rather than reporting a production result, but this is a meaningful piece of enterprise plumbing. The strongest idea is not the agent itself. It is the separation between where data lives, what a business unit chooses to expose and what the central platform is allowed to invoke.

For teams building cross-department agents, the useful takeaway is to expose narrow, typed tools and enforce policy outside the model wherever possible. The guide is a credible starting pattern, not evidence that the arrangement will be simple, cheap or secure in every organisation.

What to watch

• Whether AWS publishes production measurements for latency, cost and failed or denied tool calls.
• How organisations handle tool ownership when a central agent depends on several business units.
• Whether gateway policies prevent direct access paths that bypass the intended controls.
• How well the pattern works beyond the banking-style examples in the walkthrough.

Discussion spark: Should enterprise AI agents be given one central gateway to many departments, or is keeping each business unit’s systems more independent the safer long-term design?

not affiliated with or endorsed by Amazon Web Services (AWS)