A shared agent endpoint does not imply shared user state. In a production Microsoft Foundry deployment, session isolation is the boundary that keeps one caller\u2019s conversations, files, runtime state, and stored data from appearing in another caller\u2019s workspace. This matters most in enterprise and multi-tenant systems, where the agent may look like one service from the outside while serving thousands of private interactions inside.<\/p>\n
Foundry hosted agents provide per-user isolation by default when callers are identified through Microsoft Entra. Each user\u2019s conversations and sessions are scoped to that identity, and hosted sessions run in isolated sandboxes with their own persistent filesystem state. That gives teams a strong platform primitive, but the application can still break isolation if it maps identities incorrectly or deliberately multiplexes users into a shared session.<\/p>\n
Within Microsoft AI agents<\/a>, isolation should be treated as a design decision that spans identity, session mapping, storage, tools, and telemetry. It is not a property the prompt can enforce.<\/p>\n Foundry can derive caller identity from Microsoft Entra tokens and use that identity to separate user data. This makes the authentication path part of the state architecture. If an application terminates user authentication upstream and then calls Foundry using one shared backend identity without a correct user-isolation mechanism, the platform cannot infer the original user by magic.<\/p>\n Designers should document which identity reaches the agent endpoint, whether user identity is passed through, and how the application maps an external user or tenant to Foundry\u2019s isolation keys. The trust boundary is similar to any other multi-tenant API: the service must not accept an arbitrary client-supplied user key without validating that the caller is entitled to use it.<\/p>\n Microsoft Entra identity architecture<\/a> provides the broader principle. A session boundary is only as reliable as the identity used to establish it.<\/p>\n Foundry\u2019s isolation guidance distinguishes conversations, sessions, and stored data. A conversation is the interaction history used by the Responses protocol. A hosted session is also an execution boundary with lifecycle and compute state. Stored files and other state can be associated with that user or session. These scopes often align, but they should not be assumed to be interchangeable.<\/p>\n An application may legitimately create multiple conversations for the same user. It may also resume a hosted session after the compute has gone idle. The platform can restore session filesystem state while the conversation model continues to track the interaction history. That is useful, but it means operators need to know which identifier they are looking at during debugging.<\/p>\n The companion Agent Conversation State<\/a> article focuses on continuity. Session isolation focuses on preventing that continuity from crossing the wrong security boundary.<\/p>\n Hosted agents run sessions in isolated sandboxes, which helps prevent one session\u2019s files and process state from leaking into another. That is a strong compute boundary for workloads that write temporary files, execute code, or maintain session-local artifacts. It also supports scale-to-zero behavior because state can be restored when the session resumes.<\/p>\n Sandbox isolation does not decide what the agent is allowed to access outside the sandbox. If every session uses an agent identity that can read an entire data lake or call a highly privileged internal API, the sessions are isolated from each other but still over-privileged relative to the downstream systems.<\/p>\n This is where zero-trust identity architecture<\/a> remains relevant. The agent runtime, its managed identity, delegated user identity, and downstream authorization all need the least privilege appropriate to the workload.<\/p>\n There are legitimate cases where an application may want to multiplex multiple users through one hosted session, for example a collaborative room or a shared operational workspace. That design intentionally weakens the default per-user separation because the sandbox and session state become shared. It should be treated as an explicit collaboration model, not as a performance optimization that happens accidentally.<\/p>\n Once users share a session, the application has to enforce its own internal authorization around messages, files, and actions. A user joining late may gain access to artifacts created earlier unless the application deliberately separates them. Tool calls also need attribution so operators can tell which participant initiated an action.<\/p>\n Shared sessions should therefore have an explicit business reason and a documented data model. If the requirement is merely to reduce cold starts or save compute, weakening isolation is usually the wrong optimization.<\/p>\n Agent data can live in Microsoft-managed resources or in customer-owned Azure Storage, Cosmos DB, and Azure AI Search. Bring-your-own resources improve ownership, but they do not automatically create tenant-specific indexes, partitions, or authorization rules in the business data sources an agent queries.<\/p>\n Retrieval systems need the same boundary as sessions. A vector search query that forgets the tenant filter can return evidence from the wrong customer even though the conversation itself is isolated correctly. Semantic caches need partitioning as well; a cached answer for one tenant should not be reused for another tenant simply because the prompts are similar.<\/p>\n This is why the planned Azure AI Search filtered vector search<\/a> and AI gateway semantic caching<\/a> topics belong in the same architecture. Isolation has to survive every stateful layer, not only the chat history.<\/p>\n Operations teams need to know which user or tenant experienced a failure, but logging full prompts and files can create a second data-exposure problem. Good telemetry uses stable, access-controlled identifiers to correlate sessions, conversations, model calls, and tools while minimizing sensitive payload capture.<\/p>\n Access to traces should be narrower than access to aggregate metrics. An engineer may need latency and error rates for all sessions without needing to read every user conversation. When deeper incident analysis is necessary, access can be elevated under the organization\u2019s normal audit process.<\/p>\nIsolation begins with trustworthy caller identity<\/h3>\n
Conversations, sessions, and stored data have separate scopes<\/h3>\n
Per-session sandboxes reduce blast radius but do not replace authorization<\/h3>\n
Multiplexing users into one session changes the threat model<\/h3>\n
Tenant isolation should extend into storage and retrieval<\/h3>\n
Telemetry should preserve attribution without exposing private content<\/h3>\n