Building multi-tenant agents with Amazon Bedrock AgentCore

Artificial Intelligence Building multi-tenant agents with Amazon Bedrock AgentCore Software as a service (SaaS) providers building multi-tenant agentic applications must address architectural challenges beyond the typical concerns of security, governance, and response accuracy. These include tenant isolation, tenant identity, tenant observability, data isolation, cost attribution, and noisy neighbor mitigation. Closing the gap between a working demo and a production deployment requires infrastructure built for multi-tenant environments.Amazon Bedrock AgentCore is a managed, serverless service for building, deploying and securely operating agentic applications on AWS. It provides constructs for deploying agents and hosting MCP servers, with built-in support for identity management, memory, observability, and evaluations, all designed to make multi-tenant agent architectures straightforward to build. This post, part 1 of the blog series, explores design considerations for architecting multi-tenant agentic applications and the framework needed to address SaaS architecture challenges with Amazon Bedrock AgentCore. Design considerations for building a multi-tenant agent Building secure multi-tenant agentic applications with strong isolation requires careful architectural decisions across certain key components, as shown in Figure 1. Each component must balance tenant isolation, operational efficiency, and cost optimization while maintaining security and compliance standards. These design considerations revolve around three tenant isolation patterns: Silo, Pool, and Bridge, with tiering strategy as a key consideration when choosing among them. Figure 1: Design considerations for a multi-tenant agent In the following section, we elaborate how multi-tenancy impacts each of these components. 1. Agent Runtime Deployment: Dedicated compared to Shared A key decision in a multi-tenant agentic architecture is how the agent runtime is provisioned relative to tenants. A dedicated runtime per tenant instantiates a separate execution environment for each tenant, with its own container image, process space, and lifecycle. This silo approach offers the strongest noisy-neighbor protection and streamlines compliance audits. A shared runtime hosts agents for all tenants within the same container image and process pool, lowering infrastructure costs and operational overhead but requiring strict in-process tenant context propagation. Amazon Bedrock AgentCore Runtime resolves this tension through session-isolated microVM-based compute. AgentCore Runtime launches lightweight microVMs on a per-session basis, without the cost or latency of spinning up a full virtual machine for every tenant. Each session carries its own persistent file system, so agents can read and write session-scoped files, maintain intermediate computation artifacts, and preserve state across multi-step interactions, reducing the risk of cross-session data leakage. The architecture is a good fit for hosting multi-tenant MCP servers, agents, and AG-UI servers.Tenant context flows into the isolated execution environment through custom HTTP headers. When the SaaS platform forwards a request to an AgentCore Runtime session, it attaches headers carrying tenant-specific metadata such as tenant identifier, tier, regional preferences, feature flags, or entitlements, alongside standard authorization tokens. The agent reads these headers at invocation time to establish full tenant awareness, so it can run workflows tuned to that tenant’s business logic, invoke only licensed tools, and call tenant-specific API endpoints without hardcoded routing logic. 2. Shared compared to Tier-Specific compared to. Fine-Tuned Models Shared foundation models (FMs) serve as…