Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Session Isolation?

AI agent session isolation gives each run its own environment, browser state, files and memory, enforced by a virtual machine or container rather than by the model. The boundary it draws runs between sessions rather than within one, so content inside a run can still attempt to manipulate the agent.

Three browser sessions occupy separate transparent enclosures with independent data stores.

AI agent session isolation gives each run its own environment, browser state, files and memory, enforced by a virtual machine or container rather than by the model. The boundary it draws runs between sessions rather than within one, so content inside a run can still attempt to manipulate the agent. In practice, isolation means that cookies, files, and context from one run cannot be read by another run, by a different user, or by software on the host outside the session. It is enforced by the environment around the agent, typically a dedicated virtual machine or container per session, rather than by asking the model to forget. Isolation governs what crosses between sessions, not what the agent reads inside its own session; that second question belongs to render-layer tokenization and to the approval of consequential actions by a named person. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Process isolation standards require a separate execution domain for each process, outside controlled channels (NIST, 2020).
  • Container guidance describes namespace isolation as limiting a workload to the file systems, networks, and processes allocated to it (NIST, 2017).
  • Session controls include termination after defined conditions, giving an isolated session a planned end (NIST, 2020).
  • Hosted agent documentation describes each session running in an isolated virtual machine (Anthropic, 2025).
  • Browser isolation documentation includes clearing cache and cookies when an isolated session ends, an example of clean teardown (Palo Alto Networks, 2025).
  • Isolation does not sanitize content inside a session, where a page can still attempt prompt injection (OWASP, 2025).

What is a session for a browser using AI agent?

A session is the bounded period of work that begins when an environment is created for a task and ends when that environment is closed or destroyed. Inside the boundary the agent holds state that helps it work: an authenticated browser, open pages, downloaded files, notes on steps taken, and model context for the task. The session is the unit isolation protects. If two tasks share a session, they share that state by definition, whether sharing was intended or not.

The word is broader than a website login session, although it includes several of those. A workflow may sign in to three applications, each setting its own cookies. The agent session is the container around all of them, plus the local files and memory connecting the steps. The levels must stay distinct in review. A claim about isolated website sessions does not prove run environments are isolated, and a claim about isolated machines does not by itself describe cookie handling at teardown.

Persistence is a policy decision. Some tasks need a fresh environment destroyed at the end. Others need continuity later in the day. Saved state preserves cookies, cached files, and downloads a later run inherits. A sound design states whether each kind of state is created fresh, restored from a named saved state, or carried forward, and who approved that choice.

Which parts of a session must be kept apart?

The browser profile comes first. Cookies, local storage, cached pages, saved form data, and history determine which sites the browser appears to have visited and which accounts it may already be signed in to. A new run that inherits a profile from an earlier task may inherit an authenticated state never intended for it. Per session profiles, or a profile restored only from an approved saved state for the same purpose, prevent that quiet inheritance.

Files and memory come next. Downloads, attachments, and temporary exports often hold the most sensitive material in a workflow. A separate execution domain for each process, with its own address space, is the classic statement of this requirement (NIST, 2020). For agent sessions, one run should not be able to list, open, or alter another run's files or memory through ordinary tools.

Network, identity, and task context also need separation. A session carries allowed destinations and the identity it acts under. Mixing that context can let a public research session reuse a route meant for a restricted application. CISA treats segmentation and per request authorization as maturity steps, supporting separation by purpose (CISA, 2023). Likewise, one run's transcript, tool results, and notes should not become background for another customer or matter. That may be enforced by account and project scoping as well as by the machine, so a complete review checks both layers.

Session element Examples What isolation should prevent
Browser state Cookies, local storage, cache, history A later run inheriting a signed in state
Files and downloads Exports, attachments, temporary files One run reading another run's working files
Memory and processes Address space, clipboard, temporary data One process inspecting another outside controlled channels
Network context Allowed destinations, routes, addresses Reaching systems approved only for a different task
Task context Transcript, tool results, working notes Context from one matter appearing in another
Credentials in use Website sessions created during the run A session token surviving teardown without approval

How do virtual machines and containers create that separation?

A virtual machine gives a session its own guest operating system under a hypervisor, which allocates processor, memory, and devices and mediates access between guests and the host. The guest has its own kernel, which is why the boundary is comparatively strong. If an application inside the guest fails or is compromised, other guests and the host are intended to remain outside its reach, subject to the correctness of the hypervisor and its configuration.

A container gives a session a separated user space on a shared host kernel. NIST container guidance explains that namespace isolation limits which resources a container may interact with, including file systems, network interfaces, interprocess communication, host names, user information, and processes, and that resource allocation limits how much of the host it can consume (NIST, 2017). Containers start quickly and use resources efficiently. The tradeoff is that the shared kernel is part of the trust boundary, so configuration errors, excessive privileges, or a kernel flaw can weaken separation a virtual machine would have provided.

Browsing separation can sit inside or alongside either choice. A browser can run each profile in its own directory and process set, and remote browser isolation moves browsing into a separate environment so page content does not execute on the user's device. Palo Alto Networks documents clearing cache and cookies when an isolated session ends (Palo Alto Networks, 2025). Anthropic documents the machine pattern for a hosted agent product, describing each session as running in an isolated virtual machine, with network access limited by default (Anthropic, 2025). A buyer can ask any platform for the same plain statement: one session, which mechanism, and what happens to the machine, disk, and profile at the end.

Why does a clean state at the start and end of a session matter?

Clean state at the start means the session begins from a known image and policy, not from whatever a previous run left behind. Leftovers create exposure, where data from an earlier matter appears in a later one, and integrity risk, where a changed setting or saved file alters how the later run behaves. A defined image makes runs reproducible and makes differences attributable to the task, not to drift.

Clean state at the end means teardown is a control, not housekeeping. NIST access control guidance includes terminating a session after defined conditions or trigger events (NIST, 2020). For an agent session, teardown should close website sessions where the destination supports it, delete or archive working files by policy, clear browser cache and cookies, and destroy temporary credentials issued for the run. Material that must be kept, such as a deliverable or audit record, should leave through a defined export, not by keeping the whole environment alive.

OWASP session guidance reinforces the same lifecycle discipline for web sessions, including invalidation on logout and timeout and fresh session identifiers after authentication changes (OWASP, 2024). Agent platforms hold many nested website sessions inside one run, so every layer needs a defined end. Fresh environments cost time and make resuming harder, and longer sessions may be chosen for practical reasons. Isolation does not forbid that. It requires the choice to be explicit, scoped, and visible in the record.

What can still go wrong inside a single isolated session?

Isolation separates sessions from each other. It does not edit what the agent reads inside its own session, and it does not decide whether an action inside that session should be allowed. A malicious page opened during a run is inside the boundary with the agent. OWASP identifies prompt injection as a leading risk for LLM applications, where content processed by the model attempts to redirect its behavior (OWASP, 2025). If that page instructs the agent to copy information visible in the same session to an outside destination, no session boundary was crossed, so isolation offers no answer.

The same limit applies to authorized but mistaken actions. An agent legitimately signed in to a finance application can prepare the wrong payment, change the wrong record, or download more than the task needs, all within one correctly isolated session. Controls for those risks sit elsewhere: limiting data shown, scoping permitted actions per screen, and requiring a named person to approve consequential actions as they run.

Isolation also depends on layers beneath it. A virtual machine assumes a patched, correctly configured hypervisor. A container assumes a maintained host kernel and runtime, without broad privileges granted for convenience. NIST discussion of process isolation notes hardware based separation can give greater assurance than software based separation alone (NIST, 2020). Governance should also state who at the provider can observe a live session or export its contents. Isolation from other customers is not the same claim as isolation from the provider.

How is isolation checked in practice?

Checking begins with the provider's statement of the unit of isolation. It should name the mechanism, such as a dedicated virtual machine, a container with defined namespaces, or a separate browser profile, and the scope, such as per run, per user, or per organization. Language that names no mechanism cannot be tested. NIST zero trust material supports this approach, because segmentation and access decisions are meant to be explicit and enforced before access (NIST, 2020).

Functional checks need no specialist tooling. Start two sessions for different tasks and confirm neither can see the other's history, cookies, downloads, or files. Sign in to an application in the first and confirm a fresh second session is not signed in. End a session, start a new one, and confirm earlier files and website state are absent unless a saved state was deliberately restored. Interrupt a session without a clean close and check what remains, because teardown that works only on a tidy exit will fail in real operations.

Record checks complete the review. The platform should show when an environment was created, which task and authorizer it belonged to, what was exported, and when it was destroyed. Where no destruction record exists, the organization is relying on an assertion, which should be a recorded decision.

Where does RedactSure sit?

RedactSure starts from that boundary and governs what happens inside it. Each piece of work runs in its own governed secure virtual machine, on hardware-encrypted enclaves, with keys the customer holds; RedactSure holds ciphertext it cannot decrypt. The agent is a tethered agent: it works only inside that environment, on the applications a named person chose, with no per-application integration and no change to user permissions.

Inside the boundary, screen values chosen by policy are replaced by consistent tokens at the render layer before any model reads the screen; the model works with ACCT_001 and PATIENT_001. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy and approves every payment, submission and record change during the run, under Supervised Delegation. Real values resolve only at approved destinations at the moment of an approved action. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, the creation, export and destruction record a review asks for. The environment is model agnostic. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page draws on standards and official documentation only: NIST Special Publication 800-53 Revision 5 on security and privacy controls, including the AC-12 session termination and SC-39 process isolation controls (standard); NIST SP 800-190 on application container security (standard); NIST SP 800-207 on zero trust architecture (standard); the OWASP Top 10 for LLM Applications entry on prompt injection and the OWASP Session Management Cheat Sheet (industry guidance); the CISA Zero Trust Maturity Model, second edition (official guidance); and vendor documentation from Anthropic on Claude Code cloud sessions and from Palo Alto Networks on Remote Browser Isolation (vendor documentation). All sources were read as of October 13, 2026. Vendor statements are reported as the vendor's own description, with the date, and are not characterized.

No isolation claim was tested, no sessions were run, and no hypervisor or container configuration was inspected. No hands-on testing of Claude Code, Remote Browser Isolation, or any other named product was performed. Strength in a real deployment depends on details summaries do not reveal, including patching, privilege settings, and teardown after failure, so the checks described are tests for a buyer to apply, not results. Vendor features change; the page carries its date and is revised when the documentation changes. The finance application, research session and signed-in browser examples describe situations, not any organization; no customer or prospect is described.

Whether a given isolation mechanism, scope, or teardown practice meets an organization's requirements is a determination for its counsel, its assessor, and its security and compliance officers, not for the page.

What the record shows

Session isolation draws a boundary around a single run, giving it its own browser state, files, memory, network context, and task material, and ending that state deliberately when the run finishes. Enforced by a virtual machine or a container rather than by the model's memory, it prevents the quiet inheritance that makes shared environments dangerous, where a later task inherits an earlier task's sign in, downloads, or notes. Its limit is equally clear: isolation says nothing about what happens inside the boundary, where a malicious page, an over broad permission, or a mistaken action remains fully possible. It therefore belongs alongside controls over what the agent reads and what it may do, not in place of them. The test a buyer can apply is to start two sessions for different tasks, sign in to an application in one, and confirm the other is not signed in and cannot see the first session's files, then end a session and confirm nothing survives without a recorded decision. A clean boundary plus controlled reading and acting is the combination to choose, because isolation by itself leaves the inside of the session ungoverned.

Frequently asked questions

Is an isolated session the same as a private browser window?

No. A private window mainly separates browsing history and cookies on the same machine, under the same operating system and user account. The isolation described here separates the whole run environment: processes, files, memory, network routes, and task context, usually in a dedicated virtual machine or container. The claim to test is the mechanism and its scope, per run, per user, or per organization, not the label a product uses.

What should happen when an isolated session ends?

Teardown should be a control, not housekeeping. Website sessions are closed where the destination supports it, browser cache and cookies are cleared, temporary credentials issued for the run are destroyed, and working files are deleted or archived under policy. Anything that must be kept, such as a deliverable or the audit record, should leave through a defined export rather than by keeping the whole environment alive.

Does session isolation protect against prompt injection?

Not inside the session where the injection occurs. A malicious page opened during a run sits inside the boundary with the agent, and no session border is crossed if it persuades the agent to misuse information visible in that same run. Isolation does limit spread to other runs and other matters. The in-session risk needs different controls, such as limiting the data shown and approving consequential actions.

Is a container enough, or does an AI agent need its own virtual machine?

It depends on the trust boundary the organization accepts. A virtual machine gives each session its own kernel under a hypervisor, which is the stronger boundary. A container shares the host kernel, so configuration errors, excessive privileges, or a kernel flaw can weaken the separation. NIST notes that hardware based separation can give greater assurance than software based separation alone. Either choice should be named in the provider's statement of the unit of isolation and tested.

Does session isolation keep the provider from seeing what happens in a session?

Not by itself. Isolation between customers and between runs is a different claim from isolation from the provider. Governance should state who at the provider can observe a running session or export its contents, and under what approval. Customer-held keys and a record of every export are the controls that address that question; a virtual machine per session does not answer it on its own.

How can a buyer test whether an agent platform's sessions are really isolated?

Ask for the unit of isolation in plain terms: the mechanism, the scope, and what happens to the machine, disk, and profile at the end. Then run functional checks: start two sessions and confirm neither sees the other's cookies, downloads, or files; sign in to an application in one and confirm the other is not signed in; interrupt a session without a clean close and check what remains. Finish with record checks for creation, export, and destruction.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.