AWS Publishes Two AgentCore Paths to Query Cross-Account Knowledge Bases

AWS has published two generally available AgentCore patterns for agents that need answers from a Bedrock Knowledge Base held in a separate AWS account. Both are designed to query a Redshift Serverless-backed knowledge base without copying its governed source data into the account running the agent.

The missing permission is generated answers

The design addresses a specific gap in Bedrock Knowledge Bases’ cross-account controls. Resource policies support the Retrieve and GetDocumentContent operations, but not RetrieveAndGenerate, which returns a model-generated answer. AWS’s pattern therefore has the querying tool assume a dedicated, narrowly scoped IAM role in the Knowledge Base account through AWS Security Token Service before it calls RetrieveAndGenerate.

In AWS’s example flow, a user submits a natural-language question through an API or Streamlit interface. Amazon Nova Pro chooses whether to invoke the knowledge-base tool; the tool assumes the role and calls RetrieveAndGenerate using Claude Haiku 4.5. The knowledge base turns the question into a structured query against Redshift Serverless, then sends the generated answer and citations back through the selected orchestration path.

The choice is custom control or a managed loop

The first option is a code-based Strands agent on AgentCore runtime. The team’s Python code owns the agent loop, and its knowledge-base tool runs in a local Model Context Protocol subprocess packaged with that runtime. AWS positions it for teams that need custom orchestration, middleware, retry behavior, instrumentation, direct tool control, or streaming control.

The second is a declarative AgentCore harness, where AgentCore runs the loop from a harness definition. Its path sends calls through AgentCore Gateway to an AWS Lambda tool, whose execution role becomes the cross-account principal. AWS frames this as the configuration-first choice when the workload fits the managed loop.

First decide whether an agent belongs in the path

AWS’s most consequential recommendation is to avoid agent orchestration when the task does not need it. Applications that only need retrieved content can use native cross-account Retrieve. If every request needs one deterministic generated answer, AWS recommends assuming the data-account role and calling RetrieveAndGenerate directly from the application or a Lambda function, after confirming the work does not require tool selection, multi-step reasoning, or conversational state.

An agent is the fit when a model must decide when or how to query the knowledge base as part of a broader tool-using conversation. The cross-account requirement itself does not favor either AgentCore implementation; the operating decision is whether a team wants to maintain the loop and tool logic or accept the managed harness model.

Generated SQL still needs boundaries and review

The pattern does not make structured-data answers deterministic. AWS notes that RetrieveAndGenerate remains generative even when both variants receive the same question, Knowledge Base ID, model, retrieval count, and fresh session. It advises validating business facts against the direct tool response and underlying data, while specifying a row count, date range, and sort order for row-level questions because unbounded generated SQL can exceed result-handling limits.

AWS also recommends limiting the assumed role to the necessary Knowledge Base and model resources, using refreshable STS credentials for long-lived runtimes and warm Lambda environments, and applying Bedrock Guardrails. The company says guardrails complement rather than replace least-privilege access, source-data governance, citation-based checks, and human review for consequential decisions. A public GitHub sample contains deployment procedures for both variants.