AI agents don’t just generate text anymore. They execute shell commands, modify files, query databases, call APIs, and push code. Every major coding agent (Claude Code, Codex, Cursor, …) now operates this way: the model reasons about what to do, and the harness executes real commands on a real system.
That’s what makes them useful. It’s also what makes them risky.
This article is part one of a two-part series on sandboxing AI agents on Upsun. This piece covers why sandboxing matters and why cloud environments are the right place for it. Part two, coming next week, will cover the step-by-step technical implementation: configuring Claude Code, Codex, and building your own sandbox from scratch with standard Linux tools.
Why agents are a security problem
An AI agent can read your environment variables and make outbound network calls. It processes content written by others: pull request descriptions, issue comments, dependency READMEs. That combination is what makes prompt injection dangerous. An attacker doesn’t need to compromise your infrastructure. They just need to put the right text in a place the agent will read.
This has already happened in production. Prompt injection attacks have been reported against Microsoft 365 Copilot, GitHub’s MCP server, and GitLab Duo Chat. The industry consensus now treats LLM-generated code as untrusted by default. Not because models are malicious, but because their output is shaped by input you don’t fully control.
The solution is sandboxing: restricting what the agent’s process can see, touch, and reach. But where you run that sandbox matters almost as much as how you configure it.
Local sandboxing: good for coding, bad for validation
Running agents on your laptop with tools like bubblewrap or Docker gives you basic isolation. The agent can’t easily read files outside its working directory, and network access can be restricted. For interactive coding sessions where you’re watching the output and approving each step, this works well enough.
But local sandboxing has hard limits that appear the moment you need agents to do more than edit files.
No realistic environment. A coding agent on your laptop can modify source code and run unit tests. It can’t validate a database migration against production-scale data. It can’t check how a caching change behaves with your actual service configuration. It can’t verify that a platform configuration update behaves correctly with the services your application depends on. Local sandboxing gives you code isolation, not environment isolation.
No reproducibility. Your laptop has its own OS version, package versions, and quirks. An agent that passes tests locally may still fail later because the environment is different. A sandbox is only as useful as the environment it mirrors, and a laptop doesn’t mirror much.
No collaboration. When an agent runs locally, the output stays on your machine. Your team can’t visit a preview URL to see the changes. Your CI pipeline can’t validate them against a real environment. The agent’s work is invisible until you manually push it somewhere.
No scalability. You can run one, maybe two agent sessions on a laptop before it crawls. Companies running agents across dozens of projects need hundreds of concurrent sessions. Local machines don’t scale.
Cloud sandboxing addresses all of these. But not all cloud sandboxes are equal.
Agents need infrastructure, not just containers
Most sandbox platforms provide isolated containers for running code. That’s a good start, but it misses something fundamental about what makes agents valuable.
An agent fixing a performance issue doesn’t just modify a source file. It needs to understand how the application behaves with realistic data, real queries, and actual services. An agent running a database migration needs a database that contains the kind of data it will encounter in production. An agent adjusting configuration needs access to real metrics and real service topology.
This is the difference between a code sandbox and an environment sandbox. Code sandboxes let agents modify files safely. Environment sandboxes let agents understand, test, and validate their changes against reality.
Early adopters are already proving this out. Engineering teams that give their agents access to real databases, testing frameworks, telemetry, and live previews report significantly higher trust and adoption. Some teams now attribute a substantial share of their merged pull requests to agents. That level of trust does not come from letting an agent run npm test in an empty container. It comes from letting it verify its work in a realistic environment.
The pattern is clear. Agents that can only modify code are useful. Agents that can validate their changes against real infrastructure are transformative. And validation requires a cloud environment that looks, behaves, and contains the same things as production.
Upsun already has the right building blocks
Upsun wasn’t designed specifically for AI agents. It was built for developers who need fast, isolated, production-like environments for every branch. It turns out agents need the same thing.
The platform provides two levels of protection that are relevant for agent sandboxing. The first is container-level security: every container runs rootless, with namespace isolation, syscall filtering, and a read-only application filesystem. These protections are always on, with zero configuration. Part two of this series will cover this layer in detail, including how to add in-container tools like bubblewrap for additional process-level isolation.
The second level is what makes Upsun genuinely different for agent workloads: environment-level isolation.
Preview environments: full-stack sandboxes with real data
When you create a Git branch on Upsun, the platform creates a complete, isolated deployment of your entire application. Not just the code, but the data, the services, the configuration, and the network topology. The entire stack, cloned in seconds thanks to copy-on-write storage. Every branch gets its own URL, its own database, its own services.
For human developers, this means safe experimentation. For AI agents, it means something more profound: a full-stack sandbox with production data that can be destroyed without consequence.
Database migrations against real data. The agent creates a branch, gets a clone of production data, writes a migration, runs it, and checks the results. If the migration fails or corrupts data, delete the branch. Production never noticed. Try doing that on your laptop with a 200 GB PostgreSQL database.
Performance validation with real service topology. The agent deploys a code change to a preview environment and profiles it. Same database version, same cache configuration, same message queue setup as production. The performance numbers are meaningful because the infrastructure is identical. Not a Docker Compose file with default settings, but the same managed services running the same versions with the same data.
Configuration changes you can actually trust. The agent modifies .upsun/config.yaml, pushes to the branch, and the platform redeploys the preview environment with the new configuration. If it breaks, the branch is self-contained. Production keeps running.
Most sandbox providers give you isolated containers. Upsun gives you isolated environments that are faithful copies of your entire production stack. The agent doesn’t test against a simplified mock. It tests against reality.
Preview environments are also ephemeral by design. You create a branch for the agent, let it work, review the result, and delete the branch when you’re done. Inactive environments can pause automatically, which keeps this model practical for experimentation.
For a deeper look at data cloning and why it matters for agents, see Instant data cloning was a bet. AI agents are the payoff..
The Git workflow as a safety net
Every Upsun environment is tied to a Git branch. This means agent execution fits naturally into the development workflow your team already uses:
- Agent creates a branch
- Upsun creates an isolated environment for that branch
- Agent makes changes, runs tests, and validates against the services in that environment
- Agent opens a pull request
- Human reviews and merges (or rejects)
- Branch is deleted, environment disappears
The agent’s work is visible, reviewable, and reversible. No hidden changes, no direct production access, no mystery state living on somebody’s laptop. The history lives in Git and in the platform activity log.
This is fundamentally different from agents that apply changes directly to a running system. With Upsun’s branch-based model, agents propose changes through the same workflow your team already uses. The sandbox isn’t just a security boundary. It’s a collaboration tool.
This also means you can run agents with different levels of autonomy. A fully autonomous agent creates branches, makes changes, and opens pull requests for human review. A human-in-the-loop agent pauses at key decision points and asks for approval before proceeding. Both models work naturally within the Git workflow, and both benefit from the same environment isolation.
An environment, not a product
One thing worth noting: sandboxing on Upsun isn’t a separate product you buy or a toggle you flip. It’s a configuration pattern built from existing platform capabilities. Container isolation is always on. Environment boundaries are always enforced. Data cloning works the same way for agents as it does for developers. In-container sandboxing tools like bubblewrap are standard Linux packages you install through composable images.
This matters because the AI agent landscape is moving fast. The tools, frameworks, and best practices are changing month to month. A sandboxing approach that depends on a specific vendor’s agent runtime or a proprietary isolation layer will break when the landscape shifts. Upsun’s approach gives you standard Linux tools on a platform that already handles the hard parts (isolation, data cloning, environment lifecycle), and you compose them however your workload requires.
Getting started
You don’t need to wait for a specialized agent platform to run agents safely in the cloud. If you’re on Upsun, you already have the building blocks:
- Environment isolation with complete separation between branches
- Preview environments for disposable, full-stack experimentation with real data
- Instant data cloning for production-like testing in seconds
- Git-based workflow for reviewable, reversible changes
- Container security with rootless execution, seccomp, and read-only filesystems
- Composable images for installing any sandboxing tools you need
Start with a branch. Push your agent’s code. Let it work against a real environment. Review the results. Delete the branch when you’re done.
For the full technical guide to configuring in-container sandboxing on Upsun (Claude Code, Codex, or from scratch), stay tuned for part two of this series, coming next week.
To get started with Upsun, create a free trial account. For more on running AI workloads on the platform, see the AI agent hosting documentation. Last modified on April 27, 2026
