Amazon Bedrock AgentCore now includes a documented pattern that lets an agent running in one AWS account invoke the RetrieveAndGenerate operation on a Bedrock Knowledge Base that resides in a different account, using an assumed IAM role. This enables teams to keep AI workloads and governed data stores separate while still delivering RAG‑style answers without copying data.
Cross‑Account Knowledge Base Architecture
The flow begins with a user query submitted through a Streamlit UI or the AgentCore API. The model (for example, Amazon Nova Pro) decides to call a query_knowledge_base tool. The tool assumes a dedicated role – named bedrock_kb_access_role – in the account that owns the Knowledge Base, using AWS STS. Once the role is assumed, the tool calls RetrieveAndGenerate on the Knowledge Base, which is backed by Amazon Redshift Serverless. The Knowledge Base translates the natural‑language request into a structured query, runs it against Redshift, and returns a generated answer with citations to the originating orchestration path.
Two Implementation Paths
Both paths share the same cross‑account role and resource‑policy boundary, but they differ in where the tool executes. Variant 1 deploys a Strands agent on the AgentCore runtime. The tool runs in a local Model Context Protocol (MCP) subprocess packaged with the runtime, assumes the role, and performs the retrieval‑and‑generation call. Variant 2 uses a declarative AgentCore harness. Here the harness invokes an AWS Lambda function through the AgentCore Gateway. The Lambda assumes the same cross‑account role and issues the RetrieveAndGenerate request. The choice between a code‑based agent and a managed harness determines who owns the orchestration loop and where the execution environment lives.
Security and Operational Implications
Bedrock Knowledge Base resource policies natively allow Retrieve and GetDocumentContent for cross‑account access, but they do not list RetrieveAndGenerate. Consequently, the solution must rely on an explicit IAM role in the Knowledge Base account. Practitioners should define a narrowly scoped policy for bedrock_kb_access_role, granting only the actions required for the RAG workflow. The trust policy must allow assumption from the agent account’s principal. Because no data is copied, the primary data‑governance boundary remains in the source account, but monitoring of STS token usage and Knowledge Base API calls becomes essential for auditability. Deploying the role and policy is a one‑time cross‑account configuration; after that, agents can query the KB without additional data movement.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
To adopt the pattern, create a bedrock_kb_access_role in the Knowledge Base account, attach a policy that permits RetrieveAndGenerate on the target KB, and configure a trust relationship for the agent account. Choose Variant 1 if you need full control over the agent loop and prefer a code‑centric deployment; select Variant 2 for a fully managed harness that offloads execution to Lambda. Verify that the role’s permissions are minimal, instrument STS and KB API logs, and test end‑to‑end query flow before scaling. This approach preserves account isolation while delivering RAG capabilities across accounts.
