---
title: "A central agent does not need centralised data. Keep authority in the owning account."
description: "AWS shows a multi-account AgentCore pattern where each business account keeps its data and MCP server while a central agent gets temporary, scoped access. The security boundary should follow data ownership, not agent placement."
url: "https://devencelab.com/insights/2026/09/24/a-central-agent-does-not-need-centralised-data-keep"
date: "2026-09-24"
section: "Insights"
tag: "Agentic AI"
author: "Devence Lab"
reading_time: "2 min read"
site: "Devence Lab"
license: "Readable and quotable with attribution to the canonical URL."
---

# A central agent does not need centralised data. Keep authority in the owning account.

AWS shows a multi-account AgentCore pattern where each business account keeps its data and MCP server while a central agent gets temporary, scoped access. The security boundary should follow data ownership, not agent placement.

AWS published a multi-account agent pattern on 24 September that keeps each team's data and MCP server inside its own AWS account while a central platform account runs the agent. The agent can query across those accounts without copying their data into one shared store.

That changes the usual enterprise-agent trade-off. Centralising the agent does not require centralising either the data or the authority over it. The useful boundary is the account that owns the resource.

## Cross-account access should preserve ownership

In AWS's reference architecture, line-of-business accounts expose tools through MCP servers and retain their own data. The central platform provides the agent and AgentCore Gateway. Cross-account IAM then connects the two sides instead of moving datasets into the platform account.

The architectural consequence is important for regulated or independently operated teams. Data ownership, deployment lifecycle and access policy can remain local even when the user experience becomes global. A central agent becomes an orchestrator across trust boundaries rather than a new data lake with broad standing privileges.

> Centralise the agent experience, not the authority over every system it can reach.

## Temporary access beats a permanent agent identity everywhere

The pattern also gives security teams a cleaner place to reason about delegation. Each target account can define what the central agent is allowed to invoke and can change that policy without granting the platform ownership of the underlying data.

That matters as the number of tools grows. A single long-lived identity with direct permissions across dozens of accounts creates a blast radius that expands with every integration. Cross-account roles and fine-grained authorisation keep the permission decision close to the resource being protected.

## Make the account boundary part of the agent contract

Platform teams adopting this model should treat every remote MCP server as a separate trust domain. Derive the target account from an authorised tool mapping rather than arbitrary model output. Scope the assumed role to the exact resources and actions the tool requires. Record both the originating agent session and the target account in audit events.

Then test failure as deliberately as success. A finance tool should fail when the agent carries an engineering scope; a revoked target role should stop the call without breaking unrelated tools; and an MCP server should never infer tenant or account identity from user-controlled arguments.

The broader design rule survives outside AWS. Enterprise agents often need a unified interface across systems that deliberately have separate owners. Preserve those ownership boundaries. Give the orchestrator temporary, attributable authority to cross them, and make every crossing independently revocable.

## Sources

- [Build a multi-account AI agent with AgentCore Gateway and MCP](https://aws.amazon.com/blogs/machine-learning/build-a-multi-account-ai-agent-with-agentcore-gateway-and-mcp/) - AWS Machine Learning