By Suresh Mathew, Sedai CEO
When a tenant-isolation check failed in Asana's MCP server, roughly 1,000 companies using Asana's AI integration could access each other's project data for five weeks straight.
Failures like that are why AWS, Microsoft, Google, and Anthropic recently rebuilt their agent runtimes the same way: every session gets its own isolated environment, and the session, not the request, is what the platform schedules, secures, and bills for.
But none of them agree on how strong that isolation should be, because stronger isolation costs speed and money.
So I asked our engineering leaders: how much isolation do AI agents actually need to keep data safe?
Picking One Isolation Level Is the Wrong Question
Benjamin Thomas (Co-Founder & CTO)
I don't think you can pick one isolation level globally. Isolation strength should follow the trust level of what's running in the session. If an agent is executing arbitrary model-generated code with network access and credentials in scope, I want VM-level isolation, Firecracker-style, and I'll take the cold start.
That cost is also more manageable than the framing suggests, since you can start with the lighter VM at session initiation and escalate to heavier isolation only when the workload calls for it. Which really means the problem isn't the sandbox but the routing layer.
"Isolation strength should follow the trust level of what's running in the session."
— Benjamin Thomas, Co-Founder & CTO
Something has to look at each incoming session and decide its trust tier, placement, and lifecycle continuously rather than as a one-time config. That kind of workload-aware decisioning is where I'd expect the real gains to show up, both on cost and on blast radius.
The other wrinkle is that not all sessions are individual. Once you have shared sessions within a team, or long-running ones that outlive a single user's involvement, the question shifts from “What can escape the sandbox?” to “Who owns the session right now?”
The Asana case is exactly that: isolation held but the identity binding didn't. For shared and long-lived sessions, the session must be a security principal in its own right, not just a compute unit with a timeout. And the routing layer needs to carry that identity context along with everything else.
Your Sandbox Wont Save Your Work
Aby Jacob (VP of Engineering)
The sandbox is a security boundary, not a durability boundary, and many agentic workloads will fail if/when developers conflate the two.
While the session is increasingly becoming the preferred unit of compute, it seems durability and recovery are intentionally outside of its scope. A sandbox was never meant to remember, just execute.
For example, when a microVM crashes halfway through an agent task, everything inside it disappears including working files, runtime environment, partially completed routines and cached data. The session ID may still exist, but it now points to an empty container.
"The sandbox is a security boundary, not a durability boundary."
— Aby Jacob, VP of Engineering
The platform won't recover any of this, so we should design as if a crash is guaranteed: persist state outside the sandbox after every turn, make the environment reproducible from code or scripts, and make every tool call idempotent so a retry doesn't cause unintended side effects.
Resilient agents should externalise their state, treat the sandbox as ephemeral, and design every transaction to tolerate retries and partial failures.
An additional benefit of this architecture is portability. Once state lives outside the sandbox, the execution environment becomes a replaceable commodity that can be rented from any compatible provider, significantly reducing vendor lock-in.
Session Isolation Costs Less Than You Think
Shankar Jothi (VP of Engineering, ML)
The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one (at least for compute-bound serving paths). You pay it when a session is first provisioned, and it fades once the environment is warm and requests route back to it.
So the real variable isn't isolation itself, but how often you're establishing sessions — something lifecycle settings like idle timeouts directly influence.
"The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one."
— Shankar Jothi, VP of Engineering, ML
It's also worth being honest that this isn't measured as cleanly as it could be. Startup latency often gets folded into a single end-to-end number alongside inference time. The more useful practice is to decompose the path into the platform-managed portion and the application-defined portion, tracking those separately. That lets you reason about regressions instead of guessing at them.
More broadly, this still feels like an early and evolving space. The primitives are converging, but the operational maturity around cost, portability, and observability is still being worked out. That's where I expect most of the interesting engineering to happen over the next year.
Top comments (1)
The Asana example is a good reminder that “sandboxed” and “safe” are not the same thing. I like the distinction between isolation strength, identity binding, and durability, because teams often collapse those into one architecture decision and then wonder why retries or shared sessions get weird. The point that a session may need to be treated as a security principal in its own right feels especially important once agents become long-lived or team-shared. I’d be interested in how you decide when to pay the microVM tax up front versus escalating isolation only after a workflow crosses a trust threshold.