Code sandboxes isolate what agents run. What isolates what they write?

Argon Labs published a comparison arguing that code sandboxes such as E2B, Modal and Daytona isolate only the code an AI agent executes, not the database writes it performs through a handed-over connection string, and that a separate "data sandbox" is needed to contain those writes. Argon Labs, which builds the open-source Argon data sandbox for MongoDB, lists five required properties for such a system — starting from real data, using a real database, expiring abandoned runs, recording what each run changed, and allowing a person to adopt or discard changes — and notes its own limits: checkout materializes a physical database, actor attribution is per branch/run, and undo requires complete images and retained history. Product descriptions were checked against vendor documentation on November 11, 2026.

Code Sandboxes Isolate What Agents Run. What Isolates What They Write? A code sandbox contains agent-written code, not its database writes. See what a MongoDB data sandbox adds, with a runnable example and its limits. Argon Labs https://argonlabs.tech/about 8 min read Current capability notes: checkout materializes a physical database; native actor attribution is per branch/run; undo needs complete images and retained history. CLI sandboxes require watch and scheduled sweep. Read the capability matrix https://argonlabs.tech/features capabilities . When an AI agent writes and runs its own code, the standard advice is to put that code in a sandbox. That advice is right, and it covers less than people assume. A code sandbox contains what the agent runs . It does not contain what the agent writes to your database . That takes a data sandbox , and the two solve different problems. This article explains the difference, shows the gap with a small MongoDB example you can run, and lists what a data sandbox does not do. We build Argon https://github.com/argon-lab/argon , an open-source data sandbox for MongoDB, so read the comparison with that in mind. Product descriptions below were checked against each vendor's documentation on November 11, 2026. What a code sandbox contains Code sandboxes give an agent a place to execute code that you did not write and have not read. The vendors describe them in similar terms: - E2B https://docs.e2b.dev/ describes its sandbox as a Linux VM created on demand for an agent. - Modal https://modal.com/docs/guide/sandboxes describes Sandboxes as secure containers for executing untrusted code, isolated with gVisor or a VM runtime. - Daytona https://www.daytona.io/docs/ describes its sandboxes as isolated machines with their own kernel, filesystem and network stack, built for running AI-generated code. The boundary in each case is the machine: the filesystem, the processes, the kernel, and whatever network rules you set. If the agent's code deletes every file it can reach, it deletes files inside the sandbox. That is the problem these products were built to solve, and they solve it. What gets through the wall Most useful agents do not only compute. They read and change state that lives somewhere else, and a database is the usual place. To let sandboxed code do that, you hand it a connection string. From that moment the sandbox wall is beside the point for that data: a write sent over the connection lands in the database it points at. So the question is which database the connection string points at. There are three common answers, and each has a cost: - The real database. The agent sees real data, and every mistake is a production incident. A wrong filter on an update is not contained by anything. - An empty throwaway database. Writes are contained, but the agent works on fixtures instead of your data, and nothing it produces can come back. - A copy you made by hand. A dump and restore gives the agent real data in isolation. You then own the copying, the cleanup, and the question of what changed, which a plain copy cannot answer. What a data sandbox has to do A data sandbox is the third answer made routine. To be worth using for agents it needs five properties: 1. It starts from your data. The agent works on a fork of a real state, or of a pinned dataset when runs must be comparable. 2. It is a real database. The agent's code uses the ordinary driver and query language, with nothing to learn. 3. It expires. A run that is abandoned should not leave a copy behind forever. 4. It records what the run changed. Without that, the only review is reading the agent's own summary. 5. It has a way back. A person can adopt the changes they want and throw the rest away. The last two are what separate a data sandbox from a scratch database. Isolation alone protects your data. Review and merge are what let the agent's work become useful. A worked example The run below uses the published Argon 2.2.0 CLI installed from npm and MongoDB 7.0.48 as a one-node replica set on a laptop, on November 11, 2026. The data is synthetic: three products in a shop database. A short script stands in for agent-written code. We did not run it inside a code sandbox, because where the script runs does not change where its writes go. Bring the existing database under Argon once, then create a sandbox with a one-hour TTL: python argon import database --uri "$MONGODB URI" --database shop --project shop --source-quiesced argon sandbox create -p shop --name agent-run-1 --ttl 1h Sandbox "agent-run-1" forked from main at LSN 5. Expires: 2026-11-11T22:43:06-05:00 Connection string: mongodb://localhost:27817/argon br 6af527ba1c8ca8fc9851a748?replicaSet=rs0 Capture its writes with: argon watch -p shop -b agent-run-1 Start capture under a label for this run, and leave it running in its own terminal: argon watch -p shop -b agent-run-1 --actor agent:run-1 Now the agent's code. It was asked to apply a 10% discount. It also decides, on its own, that the cheapest product is not worth keeping: // connected to the sandbox connection string db.products.updateMany {}, { $set: { price: { $round: { $multiply: "$price", 0.9 }, 0 } } }, ; db.products.deleteOne { id: "p3" } ; MongoDB reports three documents modified and one deleted. The source database has not changed: { id: 'p1', name: 'Desk lamp', price: 49 }, { id: 'p2', name: 'Monitor arm', price: 89 }, { id: 'p3', name: 'Cable tray', price: 19 } Ask what the run changed: argon diff -p shop -b agent-run-1 Merging agent-run-1 → main put products/p1 put products/p2 delete products/p3 3 change s , 0 conflict s The delete is on the list. With --output json each change carries the document before and after, so the reviewer sees price: 49 become price: 44 instead of trusting a summary. Here the reviewer does not want the delete, so the run is discarded: argon sandbox discard -p shop -b agent-run-1 Discarded; storage reclaimed. The source still holds three products at their original prices. Had the changes been acceptable, argon merge preview would save a plan and argon merge apply would apply exactly that plan. The quickstart https://argonlabs.tech/quickstart runs a full review with two competing agents, and the MCP tutorial https://argonlabs.tech/blog/mongodb-mcp-sandbox-reviewed-merge-tutorial does the same through an MCP client, where capture and expiry are managed for you. What a data sandbox does not do The same run also showed a limit worth knowing before you rely on this. In a second sandbox the script created a new collection, inserted a document and updated it straight away. Review then failed: Error: exact post-image unavailable for update on audit log; history is incomplete; enable changeStreamPreAndPostImages before writing Collections that come from the parent are ready for exact capture. A collection the agent creates is not, until you run argon collections prepare for it or create it with pre- and post-images enabled. Agents create collections freely, so decide up front which ones a run may create and prepare them. Other limits: - It is not a security boundary. Experiments write to a separate branch database. Applying a reviewed merge explicitly changes the target branch; start the MCP server with --disable-tools argon merge apply to keep that step with a person. Use MongoDB credentials and network controls for access isolation. - It is a full copy. A sandbox materializes a physical MongoDB database, so its creation time and storage grow with the data. The open benchmark suite https://github.com/argon-lab/benchmarks measures readiness as sandbox capture ready ms . - History has edges. A healthy capture process records document changes. Undo requires complete images and retained history. Missing images or unsupported drop/rename operations mark history incomplete and prevent unsafe restoration. - It does not contain code. A data sandbox does nothing about the files, processes or network of the machine the agent's code runs on. That is the code sandbox's job. Using both together The two fit together without special integration. The host creates a data sandbox and gets a connection string, starts a code sandbox, and passes the connection string in. When the run ends, the host reviews the diff and merges or discards. Two practical points decide whether this works: - Network reach. A hosted code sandbox has to be able to reach your MongoDB deployment. A database on your laptop is not reachable from someone else's cloud without a tunnel or a deployment both sides can see. - Credentials. Give the code sandbox a MongoDB user that can reach only the sandbox database. The connection string selects a database; it does not stop a user with wider rights from naming another one. If your agent only calls a fixed set of tools and never runs code it wrote, you may not need a code sandbox at all. If it touches a database you care about, you need somewhere safe for those writes to land either way. Start with the local quickstart https://argonlabs.tech/quickstart , or read how one sandbox per agent https://argonlabs.tech/blog/disposable-mongodb-sandbox-for-ai-agents works in more detail. Frequently asked questions - Does a code sandbox protect my database from an AI agent? - It protects the machine the code runs on. If the code inside the sandbox is given a connection string to a real database, its writes go to that database. Containing those writes takes a separate, isolated copy of the data. - What is a data sandbox? - An isolated, disposable copy of a database for one agent run. A useful one starts from your real data, records what the run changed, and lets a person review the changes before merging or discarding them. - Is a Docker container with an empty MongoDB a data sandbox? - It isolates writes, but the agent starts from nothing and there is no way back: you cannot see the run as a diff against your data or merge the good parts. It works for tests that create their own fixtures. - Do I need both a code sandbox and a data sandbox? - If an agent runs code it wrote itself and that code touches a database, yes. They contain different things. An agent that only calls fixed tools against a database may need only the data sandbox. - Is an Argon sandbox a security boundary between agents? - No. A sandbox connection string is a MongoDB credential for a separate database, not an access-control system. Use restricted MongoDB users and network rules for agents that should not trust each other. - How long does an Argon sandbox take to create? - A sandbox is a full physical copy of the branch with capture ready, so the time grows with the data. The open benchmark suite measures it as sandbox capture ready ms; we do not quote a number here. Continue reading - Zero Conflicts, Wrong Price: Validate MongoDB Agent Catalog Changes https://argonlabs.tech/blog/validate-mongodb-agent-catalog-changes - A Reproducible MongoDB MCP Tutorial: From Sandbox to Reviewed Merge https://argonlabs.tech/blog/mongodb-mcp-sandbox-reviewed-merge-tutorial - What Happens When Two AI Agents Change the Same MongoDB Document? https://argonlabs.tech/blog/two-ai-agents-one-mongodb-document Argon is open source and MIT-licensed.