MCP session isolation for AI agents: keep tool connections separate
MCP session isolation means an AI agent should use a tool connection only within the session that requested it. A second chat, user, or background run should establish its own connection and authorization context instead of inheriting the first session’s state. That boundary matters whenever an MCP server can access files, tickets, databases, or a third-party OAuth account.
This is not a claim that MCP sessions replace authorization. They do not. It is a way to prevent an agent runtime from turning one valid connection into ambient authority for unrelated work. OpenClaw’s v2026.7.2-beta.3 prerelease notes describe scoping MCP server connections to the requesting session, which makes the boundary concrete for teams running several agent conversations at once. That change is still in prerelease at the time of writing, so verify the behavior on your own version before relying on it.
Table of contents
- Why MCP session isolation matters
- What should belong to one session
- A practical design for MCP session isolation
- How OpenClaw fits the boundary
- MCP session isolation checklist
Why MCP session isolation matters
An MCP connection is more than a list of tools. Depending on the server and transport, it may carry an authenticated browser flow, an access token, a server-side handle, cached discovery data, or state that affects later tool calls. If a runtime pools that connection too broadly, the next request may arrive with more context and authority than its user intended.
Consider two simultaneous conversations:
| Session | User’s task | MCP server | Risk if the connection is shared |
|---|---|---|---|
| Support triage | Read one customer’s ticket | Helpdesk MCP server | A later conversation can see or act on the same customer’s data |
| Engineering task | Inspect a repository issue | GitHub MCP server | A different agent session can inherit the authenticated repository context |
| Personal automation | Check a calendar | Calendar MCP server | A background run can reuse a consented connection without a new decision |
The failure is often subtle. The model may receive the right tool name and the server may accept the request. The problem is that the runtime no longer has a clean answer to a basic audit question: which session established this connection, and why is this turn allowed to use it?
The Model Context Protocol security guidance makes the wider principle clear: authorization must be deliberate, scopes should start small, and servers need their own authorization logic rather than trusting a claimed scope by itself. Session isolation reduces the blast radius when one of those surrounding controls fails or is misconfigured.
For a broader view of where a self-hosted runtime sits between conversations, tools, and channels, see how OpenClaw works. The useful unit of ownership is usually the active session, not the whole Gateway process.
What should belong to one session
A session boundary is useful only when the runtime applies it consistently. The following items should normally be owned by the requesting session or explicitly derived from it:
- the MCP client connection and its transport lifecycle
- server-issued session identifiers and resumable streams
- OAuth state, consent result, and access-token reference
- selected account, workspace, repository, or tenant context
- tool discovery cache when its contents vary by identity or scope
- approval record for a privileged tool call
- audit events that associate a tool invocation with the agent turn
Some data can be shared safely. A public tool schema, a server’s static capability description, or a read-only health result may be process-wide cache material. The test is simple: if reuse could change who can access data or what the agent can do, keep it session-scoped.
That distinction also avoids a common shortcut: treating one long-lived MCP process as equivalent to one long-lived authorization grant. The MCP transport specification permits independent server processes and multiple client connections. It does not give a runtime permission to merge identities just because the server is reachable over the same endpoint.
A practical design for MCP session isolation
Start with a stable session key before creating an MCP client. The key should identify the conversation and account context, not merely the model name or a browser tab. Then bind each connection, credential reference, and approval decision to that key.
A minimal policy can look like this:
- A user starts or resumes an agent session.
- The runtime resolves the session’s allowed MCP servers and requested tool scopes.
- The runtime opens or resumes a connection owned by that session.
- The server authenticates and authorizes the request using its own controls.
- The runtime records the tool call, result, and any approval against the same session.
- On session reset, logout, revocation, or expiry, the runtime closes or invalidates the connection and drops session-bound secrets.
Do not use a global map keyed only by server URL. That pattern is tempting because it reduces connection setup, but https://tools.example.com/mcp says nothing about which user authorized it. If connection reuse is necessary for performance, put a strict identity and scope tuple in the cache key and reject reuse when any part differs.
The same care applies to retries. A retry should continue the original session’s connection only when it is retrying the same authorized operation. A background job that starts later needs an explicit ownership and credential decision. Otherwise a transient failure path becomes an accidental privilege-escalation path.
This design complements the approval and provenance boundaries described in OpenClaw’s self-hosted agent security guide. An approval is more meaningful when it names the session, tool, target, and operation that will consume it.
How OpenClaw fits the boundary
The v2026.7.2-beta.3 prerelease lists two changes that belong together: MCP server connections scoped to the requesting session, and a Control UI that can create and place eligible coding-agent sessions on their owning hosts. Together they make session identity operational rather than cosmetic: a session has a place, a transcript, a model route, and an MCP connection boundary. Both land in a prerelease line, so operators on the current stable release should treat them as the direction of travel rather than as behavior they already have.
For an operator, the important point is not that every tool must run in a separate process. It is that a tool connection should not float freely between unrelated sessions. This makes incident review less ambiguous and prevents a convenient connection pool from becoming a shared privilege pool.
OpenClaw already treats tool-result handling as a separate security concern. Its MCP tool-results materialization boundary explains why tool output needs careful handling before it becomes agent context. Session isolation addresses the other side of the exchange: which conversation got to call the tool in the first place.
If you run multiple agents with different owners, channels, or tasks, review these boundaries together:
- session-to-server connection ownership
- server-side authentication and least-privilege authorization
- explicit approval before privileged actions
- tool output handling before it enters model context
- revocation and cleanup when a session ends or a pairing changes
MCP session isolation checklist
Use this checklist before treating an MCP integration as multi-user or multi-agent ready:
- Does every MCP connection have a requesting session and account owner?
- Can a reset, logout, or credential revocation invalidate the connection?
- Does the reuse key include identity and granted scope, not only the server URL?
- Do retries preserve the original session boundary instead of borrowing a global connection?
- Does the MCP server enforce authorization independently of client-side session state?
- Can an operator trace a tool call back to the session, approval, and credential context that allowed it?
A clean answer to those questions will not solve every MCP security problem. It does remove one dangerous assumption: that a connection created for one agent conversation is automatically safe for another.
FAQ
Does MCP session isolation replace OAuth scopes?
No. Session isolation limits which agent conversation can use a connection. OAuth scopes and server-side authorization still determine what that connection can do. You need both controls.
Should every MCP tool call open a new connection?
Usually no. A session can reuse its own connection when that reuse preserves identity, authorization, and audit context. The goal is not maximum connection churn; it is preventing cross-session reuse.
What happens when an agent session is resumed?
A resumed session may reconnect if the runtime can verify the same session ownership and credential state. If an account changed, access was revoked, or the session was reset, the runtime should require a new connection and authorization path.
Is session isolation useful for local stdio MCP servers?
Yes. A local server can still expose sensitive files, tokens, or actions. The transport changes how the connection is created, not the need to associate it with the session that requested it.