Per-Session Sandbox Isolation — Hosted Agents: Operations

The most important architectural choice in a hosted agent is not the model, the prompt, or the tool list. It is the boundary around each unit of work. Per-session sandbox isolation means every conversation, task, or job gets its own private compute environment and its own filesystem. When the work is active, the sandbox runs. When it goes quiet, the compute disappears while the files remain. That single pattern gives you three things agents badly need: strong separation, low idle cost, and a practical way to resume long-running work.

Scale by session, not by shared instance

Traditional web services often scale by running several replicas, which are identical copies of the same service. A load balancer spreads many users across those replicas. That model works well when the service is mostly stateless and users do not write private working files into the same runtime.

Agents are different. They may create files, execute code, cache intermediate results, call tools, and handle secrets. If several users share one long-lived instance, a mistake in cleanup, permissions, or tool behavior can turn into cross-user exposure.

Per-session isolation changes the unit of scale. A session is one logical unit of work, such as a user conversation, an analysis job, or a task run. Each session gets a new sandbox of its own. Concurrency is handled by creating more sandboxes, not by packing more users into one shared process.

This also changes how you think about resource settings. If you configure central processing unit and memory limits, those limits describe one session sandbox, not the entire agent fleet. Ten active sessions mean ten separate sandboxes, each with its own boundary.

📌

The unit matters. If agents can write files or run tools, the safe scaling unit is usually the session, not the replica.

What the sandbox boundary must do

Isolation is a spectrum. The weakest form is social isolation: two programs run near each other and are expected not to interfere. A stronger form uses operating system boundaries, such as process or container controls. A stronger common cloud boundary is hardware-level isolation enforced by a hypervisor, the layer that separates virtual machines from one another.

For hosted agents, that distinction is not academic. Agents can be asked to process untrusted inputs, run generated code, inspect uploaded files, or call tools with side effects. You should assume that some session will eventually behave badly, whether because of a bug, a prompt injection, or a malicious file.

A hardware-isolated sandbox gives each session a wall that does not depend on the agent being polite. The code inside one session should not be able to read another session's memory, browse another user's files, or tamper with a shared machine. The goal is not to make bad behavior impossible. The goal is to make its reach small.

The boundary should remain meaningful even when code inside the session is hostile.
The session should not share a writable working directory with other sessions.
Secrets made available to one session should not become reachable from another.
Failure or compromise in one session should not require trusting cleanup on a shared instance.

Isolation ranges from social separation to hardware-enforced walls between sessions.

State survives, compute does not

The useful trick in this design is separating compute from state. Compute is the running machine: processor, memory, and active processes. State is the filesystem the agent uses to store files, intermediate results, downloaded data, generated reports, and other working artifacts.

In a per-session sandbox, the compute can be temporary while the filesystem is persistent. When the session is active, the sandbox runs with its files mounted and available. When the session goes idle, the platform tears down the compute but keeps the session's filesystem. When the same session is resumed, fresh compute is created and the saved files are restored into the expected places.

That is what makes long-running agent work practical without keeping machines alive all week. An agent can prepare data on Monday, sit unused for days, and continue on Friday with its working directory intact. The machine is disposable; the session's state is the durable part.

✅

The design pattern. Treat compute as replaceable and the session filesystem as the continuity layer.

Per-session sandboxes keep the filesystem while the compute behind it can be torn down.

The session lifecycle

A hosted session usually moves through three practical states: active, idle, and resumed. Active means compute is currently provisioned and can handle requests. The filesystem is present, tools can run, and the agent can read and write its working files.

Idle begins after a period with no requests, commonly on the order of fifteen minutes. At that point the platform deprovisions the running compute and preserves the session's state. Because there is no machine running, there is no compute charge during the idle period.

Resumed means the same session is referenced again. The platform provisions fresh compute, attaches or restores the saved filesystem, and the agent continues with the files it had before. Sessions are commonly created on first use and cleaned up automatically. If a session remains untouched for a long period, on the order of a month, its persisted state may be deleted permanently.

You should design with that lifecycle in mind. Store durable work in the session filesystem, not only in memory. Assume memory is lost across idle. Also assume that very old abandoned sessions are not archives; if a result must be kept indefinitely, copy it to a system of record.

A session moves through active, idle, and resumed states while its files persist.

Scale to zero and cold starts

Scale to zero means no compute remains allocated when there is no active work. For agents with bursty usage, this is a major economic difference from an always-on service. You are not paying for idle sessions just because a user might return later.

The tradeoff is the cold start. A cold start is the first request after a session has gone idle, when the platform must provision compute and restore the filesystem before work can continue. In a well-engineered hosted agent environment, cold starts are designed to be predictable and short enough for interactive use, but they still exist as a real part of the user experience.

The right question is not whether cold starts can be wished away. The right question is whether their latency is acceptable for the task. A background research job can tolerate more startup delay than a chat interface waiting for a user-visible response. Measure the path that matters, including filesystem restoration and tool initialization.

Use scale to zero for workloads with meaningful idle periods.
Measure cold start time after the session has been idle long enough for compute to be removed.
Keep startup work lean; do not rebuild large indexes or redownload large dependencies on every resume if the filesystem can preserve them.
Set user expectations differently for interactive chats, batch jobs, and scheduled tasks.

Keeping users and tenants apart

One deployed agent often serves many end users. Per-session isolation only works operationally if the application maps each user's work to the correct session every time. That usually requires a session namespace or isolation key, which is a stable identifier used to separate one user's or tenant's sessions from another's.

The namespace decision is simple in concept and important in practice. User A's conversation must resume into user A's saved filesystem, not user B's. A tenant administrator viewing a company workflow must not accidentally attach to a different tenant's sandbox. The platform can provide the isolation primitive, but the application still has to choose and pass the right session identity.

For privacy-sensitive systems, consider the session key part of the security design. It should be derived from authenticated identity and authorization decisions, not from a user-editable field. If users can influence the session identifier directly, they may be able to guess or collide with another session.

⚠️

Identity is part of isolation. A strong sandbox does not help if the application resumes the wrong user's session.

A session namespace derived from authenticated identity keeps each user and tenant apart.

Decisions for leaders and practitioners

Per-session sandboxing is not only an implementation detail. It affects cost models, risk reviews, product behavior, and operational runbooks. Leaders should ask whether the agent platform charges for active compute only, what happens to state during idle, and how abandoned sessions are retained or deleted.

Practitioners should ask sharper engineering questions. What exactly is persisted? Are uploaded files and generated files in the same session filesystem? Are secrets injected per session or shared across an instance? What resource limits apply to one sandbox? How is a session namespace constructed? What is the measured cold start after fifteen minutes of idle time?

Security reviewers should focus on blast radius. If one session is compromised, the expected answer should be narrow: it can affect its own files, its own running processes, and the tools and permissions granted to that session. It should not reach another user's state, another tenant's data, or a shared host process.

A simple test for your agent

You can evaluate an agent's isolation model without a long audit. Pick two test users, give each a separate conversation, and have each session write a distinctive file. Let both sessions sit idle long enough for compute to be torn down. Then resume each session and verify that the correct files return in the correct place.

Next, test the failure case. Try to make one session discover the other session's files, environment, or identifiers. It should fail by construction, not merely because a prompt says not to look. Finally, check billing or telemetry to confirm that idle sessions are not consuming compute.

The ideal result is straightforward: each user gets a separate sandbox, idle compute falls to zero, the filesystem returns on resume, and the largest plausible failure is limited to one session.

Create two users or tenants with separate authenticated identities.
Start one session for each and write a unique file in each filesystem.
Wait past the idle teardown window, then resume both sessions.
Confirm each session sees only its own files.
Review telemetry for cold start time and zero compute during idle.
Document the maximum blast radius if one session is hijacked.

Key takeaways

Hosted agents are safest when they scale by session rather than by shared service replica.
Hardware-level sandboxing gives each session a boundary intended to contain hostile or mistaken code.
A persistent session filesystem lets long tasks resume even after compute has been torn down.
Scale to zero reduces idle cost, while cold starts must be measured for the user experience that matters.
Session namespaces connect the isolation model to real user and tenant separation.
The practical security goal is a blast radius of one disposable session.

Glossary

Session: A logical unit of work, such as a conversation, task, or job, that receives its own isolated sandbox and saved state.
Sandbox: A restricted execution environment that limits what code inside it can reach or affect.
Replica: An identical running copy of a service that may serve many users at the same time.
Hardware-level isolation: Separation enforced below the operating system, commonly by a hypervisor, so one virtual machine cannot directly access another.
Persistent filesystem: A session's saved file storage that survives compute teardown and is restored when the session resumes.
Scale to zero: The practice of removing all running compute when there is no active work, so idle time does not consume compute resources.
Cold start: The startup delay on the first request after idle, when compute must be provisioned and session state restored.
Session namespace: A way to map users, tenants, or tasks to distinct sessions so their persisted state does not collide.
Blast radius: The maximum amount of damage or exposure caused by a single failure, compromise, or misbehavior.