What Makes a Sandbox Implementation Hard to Migrate Away From

Every team that deploys an AI agent into a code execution sandbox makes an architectural commitment the day they ship. What looks like a reversible infrastructure choice compounds into something close to permanent coupling, layer by layer, as session semantics, state formats, and security postures accumulate on top of the initial isolation primitive. The migration cost is technical, not contractual, and it accrues invisibly.

The mechanism is accumulation, not a single decision. Each technical layer a team adopts, whether it is the isolation model, session semantics, snapshot format, or SDK language, adds switching cost that is imperceptible at adoption time but dominates any later attempt to move. The two canonical cases show why they should.

OpenAI planned to formally deprecate the Assistants API, with a target sunset date of August 26, 2026, and provided a migration guide to help developers move to the Responses API. Thousands of teams had built session semantics around a runtime primitive that was unilaterally retired. The migration cost was technical, not contractual, and it landed on teams who had done nothing wrong except build against an abstraction that was not guaranteed to survive.

The pattern repeated within the same vendor. In October 2025, OpenAI launched AgentKit, a toolkit for building, deploying, and optimizing agent workflows, including Agent Builder, a visual canvas for creating and versioning multi-agent workflows. Teams that had integrated the canvas into their agent build process faced a forced rewrite on a fixed timeline.

The lesson is structural rather than vendor-specific. When AI models increasingly generate and execute code autonomously, the sandbox becomes the most load-bearing architectural decision in the agent stack, yet teams rarely evaluate it on migration cost at procurement time. The sections that follow identify precisely where that cost accrues.

How isolation technology choice determines your security posture permanently

The isolation primitive is the most foundational choice a team makes, and the hardest to reverse. Once your security posture and compliance certifications are built around a specific isolation mechanism, switching that mechanism is not a configuration change. It invalidates the threat model and restarts the compliance audit record from zero.

The isolation spectrum matters because the levels are not interchangeable. This provides stronger isolation than containers with less overhead than a full VM, though some syscall compatibility gaps can affect certain Linux software. MicroVMs like Firecracker give each workload its own kernel on hardware virtualization through KVM. A kernel exploit inside one VM cannot reach the host or other VMs, which is why major cloud providers have moved toward this level for untrusted code execution.

The structural distinction between these levels is the point. A microVM's isolation is enforced by hardware, below the layer the agent can reach. This is why isolation level is not just a performance tradeoff. It defines whether the security boundary can be reasoned around by the thing it is trying to contain.

The security consequence of getting this wrong is documented. In March 2026, a Falco core maintainer demonstrated that an LLM agent will bypass its own sandbox if the sandbox stands between the agent and completing its task. No jailbreak was required.

The lock-in mechanism follows directly. If SOC 2 Type II, HIPAA, or an EU AI Act conformity assessment is tied to a specific isolation primitive, switching that primitive means re-auditing from scratch. The audit record does not transfer.

The strongest objection deserves acknowledgment. What actually creates lock-in is not the VMM itself but the session semantics, snapshot portability, SDK bindings, and compliance certifications built on top of it. The stack above it is not.

Why stateful execution creates the deepest and least visible coupling

Stateful sandbox environments create deeper and less reversible coupling than any other architectural choice. The value teams accumulate over months of production use, snapshot chains, warm pools, preconfigured volume structures, exists entirely inside the vendor's format and cannot be extracted. Statefulness is a functional requirement for agent workloads, not a preference. On an ephemeral runtime it would re-clone and reinstall on every action. Long-horizon agents depend on persistent state to make progress.

The two stateful patterns produce different lock-in profiles. Persistent paused sandboxes stay alive between runs in a paused state, with filesystem and memory snapshots persisting so the next resume is sub-second. Teams accumulate months of preconfigured snapshot chains that are essentially non-portable.

The compounding mechanism is straightforward but rarely noticed in advance. The richer the state model, the more migration cost a team carries. A team that has built a library of parent snapshots with pre-installed dependencies, branch histories, and warm-pool configurations has created infrastructure that cannot be lifted and shifted to a new provider. It must be reconstructed from scratch.

The research frontier suggests this coupling may not be permanent. The DeltaBox paper, arXiv:2605.22781, published in 2026, demonstrates millisecond-level sandbox checkpoint and rollback for stateful AI agents, designed specifically for high-frequency state exploration in LLM-powered workloads like test-time tree search and reinforcement learning. This is a direct technical challenge to the assumption that stateful execution necessarily requires a single persistent vendor environment.

What DeltaBox changes about the lock-in argument is the trajectory, not the present reality. If checkpoint and restore becomes commoditized infrastructure with open formats, the stickiness of any one provider's snapshot format is reduced. The coupling is real today, even if it may weaken over time.

How the orchestration and harness layer absorbs your agent's reasoning structure

The most dangerous lock-in is not at the sandbox level. It sits above it, in the orchestration harness layer, because the harness shapes prompts, tool definitions, permission models, and session continuity. These structures do not translate between platforms. The harness layer contains the agent loop itself: planning, context management, tool approval, subagent coordination, session state, tracing, handoffs, and resume bookkeeping. If you switch the runtime layer, you rebuild the harness assumptions, not just re-point an endpoint.

OpenAI's Agents SDK update in April 2026 made this explicit. The SDK provides the model with a harness that includes instructions, tools, approvals, tracing, handoffs, and resume bookkeeping. But the harness semantics themselves are SDK-defined, and teams building against them accumulate coupling to OpenAI's abstractions for planning, approval flows, and resumability.

The provider-agnostic design of that SDK is instructive. It supports the OpenAI Responses and Chat Completions APIs, as well as more than 100 other LLMs. A team can be model-agnostic but still deeply coupled to a specific harness abstraction.

Managed runtimes consolidate the risk further. A managed agent runtime that handles memory, session management, tool access, identity, and observability for agentic workloads bundles the harness and the execution environment together. The practical implication is that teams who treat the orchestration harness as interchangeable with the sandbox discover during migration that they are rebuilding both simultaneously, because the two were designed as a unit.

How provisioning APIs and SDK language bindings accumulate switching cost gradually

Provisioning APIs and SDK language bindings create switching cost that is proportional to integration depth, not to contract terms. Every tool, workflow, and internal library written against a vendor's surface area is a unit of migration work that teams rarely account for in advance. The mechanism operates through a team's internal platform engineering layer. The scripts, internal SDKs, CI/CD integrations, and monitoring hooks that wrap the sandbox API are written against a specific provider's API semantics. The deeper the integration, the higher the cost.

SDK language constraints compound this in a predictable way. A sandbox SDK that ships Python first, as the OpenAI Agents SDK harness did at launch, with TypeScript planned later, means teams building in other languages either wait or build their own bindings. The teams who build their own have the deepest integration and therefore the highest switching cost. They have invested engineering time in an abstraction layer that exists only for that vendor.

Billing architecture is a hidden API coupling that few teams examine at procurement time. The way a provider meters wall-clock CPU and memory versus task completion shapes how teams write agents. Agents optimized for one billing model perform or cost differently on another. That means the agent code itself may need revision on migration, not just the infrastructure configuration.

The Zendesk case illustrates what API migration looks like in practice even within a single vendor. Zendesk's mid-2026 infrastructure migration for AI agents required existing customers to accept URL filter format changes, knowledge source consolidation, search rule rewrites, and a mandatory service window with up to two minutes of downtime. Switching vendors entirely multiplies that surface across every integration written against the original provider.

What compliance and data residency requirements add to the migration surface

Compliance certifications and regulatory obligations are often tied to a specific vendor's managed deployment model in ways that are not portable. If you switch providers, you re-certify the new environment, and the audit record and the certification timeline restart from zero. The structural problem starts with certification scope. SOC 2 Type II is the baseline enterprise customers expect. Teams that verify only a vendor's headline certification without checking whether it covers their specific deployment model discover the gap at audit time, not procurement time.

Model provider lock-in compounds compliance lock-in. Locking to one model provider locks teams to whatever that provider later decides about retention, training, and data residency. Compliance obligations travel with data handling decisions, not just infrastructure decisions. A team cannot separate its compliance posture from the chain of vendors that process its data.

The EU AI Act adds a new compliance surface for sandboxes. Agents deployed in the EU or affecting EU users that operate in high-risk categories, including HR and recruitment, credit scoring, critical infrastructure, education, law enforcement, and healthcare AI regulated as medical devices, trigger conformity assessment, post-market monitoring, fundamental rights impact assessments, and human oversight requirements. A sandbox vendor that cannot provide per-tenant audit logs, data residency controls, and documented human-oversight hooks is now a regulatory disqualifier for these deployments, not merely a preference.

The portability consequence follows. If your compliance posture is built around one vendor's data residency controls, audit log format, and BAA, you cannot assume those controls exist or are structured the same way on a new platform. If you migrate, you re-establish the compliance evidence base, and the timeline is measured in months for SOC 2 and longer for HIPAA-covered environments.

Managed platforms versus bring-your-own-compute, and what each choice locks in

The managed-versus-BYOC decision is not primarily about operational burden. It determines which combination of lock-in vectors a team accumulates, and teams that treat it as a convenience trade-off rather than an architectural commitment discover the constraint when a migration becomes necessary. Managed platforms lock in a bundle. Zero-ops scaling comes at the cost of coupling to the vendor's session semantics, snapshot format, egress policy, billing model, and compliance posture simultaneously. If a managed abstraction hides operational complexity, it also hides a migration dependency. The abstraction is the coupling.

Building directly on open primitives such as Firecracker or gVisor preserves maximum control and offers the lowest per-run cost at scale. The isolation primitive itself is not a lock-in because it is open-source. The burden shifts from migration risk to operational load.

The BYOC middle path is customer-managed compute in a team's own cloud, running a sandbox platform's software stack. The platform's API surface remains a coupling point even when the compute is owned. Owning the hardware does not free a team from the software contract.

The computer-use agent gap deserves specific attention. For agents that interact with a desktop environment rather than a code execution environment, no standardized portable sandbox primitive currently exists. Teams building in this space have no established portability baseline to plan against. Their lock-in risk is structural rather than vendor-specific, because the underlying primitive has not been standardized yet.

Which architectural choices genuinely create lock-in and which ones do not

Not all architectural coupling is lock-in. The meaningful distinction lies between choices that are reversible with engineering effort and choices that invalidate the entire surrounding system when changed. Teams that understand this distinction can make sandbox decisions they will not regret.

Genuine lock-in consists of decisions that invalidate the surrounding system when changed. Orchestration harness semantics baked into agent prompts and tool definitions couple the reasoning structure of the agent to the harness's abstraction model. Data residency and BAA coverage tied to a specific vendor's managed deployment carry a compliance timeline, not just an engineering timeline.

Reversible coupling takes a different form. Isolation primitive selection when the primitive is open-source, such as Firecracker or gVisor, is portable even if the stack above it is not. SDK language bindings written against a standards-based API are rewritable with effort proportional to integration depth, not to architectural reconfiguration. Billing model optimization in agent code is adjustable as a performance tuning exercise, not a system redesign.

The evaluation questions teams should apply at adoption time follow from this distinction. Does the compliance certification survive a change of this component, or does it require re-certification? If this vendor deprecates this primitive, as has happened with the Assistants API and AgentKit, what is the blast radius and the migration timeline?

The DeltaBox research direction is worth watching as a signal. If millisecond-level checkpoint and rollback with portable state formats becomes standard infrastructure, the stickiness of proprietary snapshot formats diminishes. The choices that create genuine lock-in are the ones that embed team-specific value, compliance evidence, and reasoning structure into a vendor's format. Those are the decisions that survive any improvement in the underlying primitives.