How Much Isolation Do AI Agents Actually Need?
After Asana's MCP data leak, Sedai engineers debate how much session isolation AI agents truly need, weighing security against cost and speed.
When a tenant-isolation check failed in Asana's MCP server for five weeks, roughly a thousand companies could see each other's project data. That incident illustrates why AWS, Microsoft, Google, and Anthropic have rebuilt their agent runtimes around the session as the core unit that gets isolated, scheduled, secured, and billed — though none of them agree on how strong that isolation should be, since stronger isolation trades off against speed and cost.
Sedai's engineering leaders offer different angles on the tradeoff. Benjamin Thomas argues there's no single right isolation level: strength should scale with the trust level of what's running in a session, and the real engineering win comes from a routing layer that continuously assesses trust tier and identity rather than treating isolation as a one-time config. For shared or long-running sessions, he notes, the real risk isn't escaping the sandbox but losing track of who owns the session — exactly what broke in the Asana case.
Aby Jacob stresses that a sandbox is a security boundary, not a durability boundary: when a microVM crashes, everything inside vanishes, so state must be persisted externally, environments made reproducible, and tool calls designed to be idempotent. Shankar Jothi adds that isolation overhead is mostly a cold-start cost that fades once a session is warm, meaning the real lever is how often sessions get re-provisioned rather than isolation itself. All three agree the space is still maturing, with cost, portability, and observability practices still being worked out.