What the platform gives you — and what stays your design

Lesson 3 of 5 in Multi-Tenant Isolation: One Platform, Many Customers, Zero Bleed.

Managed agent platforms genuinely do sell isolation, and some of what they sell is real and documented. The discipline is separating three things: what the vendor guarantees, what the vendor offers if you configure it, and what the vendor never claimed and you therefore still owe. This academy is not vendor documentation — the summaries below reflect the AWS and Microsoft docs as checked in September 2026, and you should re-read the current pages before designing against them.

The pattern repeats across clouds: you get strong per-session compute isolation for free, namespacing and per-tenant resources as configuration, and tenant-aware credentials, egress, telemetry, quotas, and deletion as your job.

AWS Bedrock AgentCore

Provided. Each AgentCore Runtime session is identified by a runtimeSessionId and runs in a dedicated microVM with isolated CPU, memory, and filesystem; on termination the microVM is destroyed and its memory sanitised, which the developer guide describes as preventing cross-session data contamination. AWS also lists namespace-based memory isolation, encrypted credential storage, and audit logging among AgentCore’s security capabilities.

Configurable. AgentCore Memory scopes events by actorId plus sessionId, and long-term retrieval addresses records through namespace paths built from template variables such as /summary/{actorId}/{sessionId}/ — so the isolation you get depends on the namespace scheme you define. AgentCore Identity’s token vault stores OAuth tokens, API keys, and client secrets encrypted with AWS KMS keys (customer-managed keys supported), and AWS states that user-specific credentials are accessible only by the individual agent acting for that user. AgentCore Policy evaluates Cedar permit/forbid rules — which can condition on tool-call input attributes — on actions passing through Gateway.

Still yours. Deciding that a tenant maps to an actor, a namespace prefix, or an entire separate Memory resource. Per-tenant credential providers rather than one. Per-tenant network policy. Tenant tags on spans, and who may query across log groups. Note the durability twist with Runtime Instances (EC2-backed sessions up to 14 days): persistent volumes survive stops and re-attach on resume with the same session id, so a “session” is now durable state you must scope and delete.

Microsoft Foundry Agent Service

Provided. Hosted agents run in per-session VM-isolated sandboxes; each session gets a dedicated sandbox with a persistent filesystem ($HOME and /files), enabling scale-to-zero with stateful resume. Each hosted agent automatically receives a dedicated Microsoft Entra identity, and with a user token present it can call downstream services through OAuth 2.0 on-behalf-of.

Configurable. Standard setup requires bring-your-own Azure Storage, Azure AI Search, and Azure Cosmos DB, so conversation history, files, and vector stores live in your tenant, with customer-managed keys supported. Private networking (BYO VNet) is available with Standard setup only, and network injection must be set at Foundry account creation — it cannot be added or changed afterwards. The hosted-agent state store holds keyed JSON independently of compute and, per Microsoft Learn, can partition items per end user for multitenant agents. Network egress controls for hosted agents are documented as preview as of September 2026 and are configured inside the guardrail policy, so treat them as a moving target and verify behaviour yourself.

Still yours. Mapping tenants onto projects, accounts, sessions, and state-store partitions. Deciding whether a regulated tenant needs its own account (remember the create-time VNet decision). Per-tenant tool credentials in Toolbox rather than one shared connection. Microsoft also notes that not all agent tools support network isolation, and that trace content recording is opt-in because it may contain personal data — both are your calls.

Your own stack

On Kubernetes, serverless functions, or plain VMs, nothing is provided: every layer is a component you choose and wire.

Session: one pod, task, or microVM per run, with no warm-worker reuse across tenants — and real sandboxing for code execution and browsing, not just a fresh directory.
Memory and retrieval: a namespace convention enforced in a single data-access layer that physically cannot be bypassed, plus per-tenant collections wherever the store supports them.
Credentials: a broker that takes the pinned tenant id and mints or fetches a per-tenant, downscoped credential. This is the layer teams skip, and the reason a “shared service account” shows up in so many post-incident write-ups.
Egress: an outbound proxy or network policy per tenant, enforced outside the agent process — an allowlist the agent cannot edit.
Observability and quotas: tenant tag required at span ingest, per-tenant dashboards, per-tenant token and spend counters.

The advantage of building it yourself is that the boundary is exactly where you drew it. The cost is that all five layers are now your on-call rotation’s problem.

Amazon Bedrock AgentCore Developer Guide — How AgentCore Runtime works (checked September 2026)

Each session runs in a dedicated microVM with isolated CPU, memory, and filesystem; when the session terminates, the entire microVM is destroyed and its memory sanitised, preventing cross-session data contamination. Sessions are Active, Idle, or Terminated, and the guide documents termination after 15 minutes of inactivity or at an 8-hour maximum lifetime, with session state treated as ephemeral — durable context belongs in AgentCore Memory.

Read that boundary precisely: it is per session, not per customer. Two sessions for two tenants are isolated from each other; a session and the Memory namespace it reads are not, unless your namespace scheme says so. Timeout values are defaults documented at the time of writing — check the current AgentCore Runtime service quotas before you design a session-lifetime assumption into your product.

Microsoft Learn — Networking options for Foundry Agent Service (checked September 2026)

BYO virtual network for Foundry agents requires a dedicated subnet delegated to Microsoft.App/environments (per account, /27 or larger) in RFC 1918/6598 space, with private endpoints and Private DNS zones. Network injection must be set at Foundry account creation and cannot be added or changed afterwards. Standard setup — the only one that supports private networking — also requires bring-your-own Storage, AI Search, and Cosmos DB, keeping agent data in your tenant.

The consequence for tenancy design is unusual and worth internalising: on this platform, one of your isolation choices is irreversible at create time. If a future enterprise tenant will demand network isolation, the cheap moment to decide is before the first account exists, not after you have a thousand agents in it.

Provided, configurable, or yours — as documented in September 2026
Concern	AgentCore (AWS docs)	Foundry Agent Service (Microsoft Learn)	What remains your design
Per-run compute isolation	Provided: dedicated microVM per session; destroyed and memory sanitised at termination.	Provided: per-session VM-isolated sandbox with persistent `$HOME` and `/files`, resumed on demand.	Never multiplex two tenants in one run, and treat resumable session filesystems as durable tenant data.
Memory / conversation storage	Configurable: events scoped by `actorId` + `sessionId`; long-term records addressed by namespace paths from strategy templates.	Configurable: Standard setup stores conversations, files, and vector data in your own Cosmos DB, Storage, and AI Search, with CMK support; state-store items can be partitioned per end user.	The namespace scheme itself: does a tenant map to an actor, a prefix, a store, or a whole account? Plus provenance tags and the deletion path.
Tool credentials	Configurable: Identity token vault (KMS/CMK-encrypted) with per-user credential access; Cedar policies enforced at Gateway.	Configurable: per-agent Entra identity, on-behalf-of user tokens, and centralised credential injection through Toolbox.	Creating one credential provider per tenant instead of one per vendor, and proving no single secret can reach two tenants.
Egress	Partially: VPC and PrivateLink support, plus network modes on sandboxed tools; per-tenant destination policy is not a documented AgentCore feature.	Partially: BYO VNet with private endpoints (create-time only); hosted-agent network egress controls documented as preview.	A per-tenant allowlist enforced outside the agent process, and a decision for every tool that does not support network isolation.
Observability	Provided: OTel telemetry to CloudWatch with a session/trace/span hierarchy (one-time Transaction Search enablement per account).	Provided: OpenTelemetry traces in Application Insights; message-content capture is opt-in because it may contain personal data.	Requiring a tenant attribute at ingest, scoping who can query what, and keeping cross-tenant queries privileged and audited.
Quotas and fairness	Account- and service-level quotas exist; per-tenant budgets are not a documented feature. Consumption pricing means one tenant’s runaway loop is your bill.	Both agent types autoscale under platform management; per-tenant fairness is not a documented feature.	Per-tenant token, tool-call, concurrency, and spend budgets with enforcement — the subject of the next lesson.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.