Agent sandboxes your whole team can use
Describe the agent you need to the AI tool you already use. Runwork hosts it, and every big task it takes on runs in its own isolated sandbox, with your team's skills, connected tools and a budget you set. There are no servers, containers or API keys to manage.
Generated weekly executive summary from data-analyzer outputs. 3 files written to outputs/.
Reviewing auth middleware changes across 14 files. Reading previous session history for context.
Powered by Runwork AI What an agent sandbox is
An agent sandbox is a computer an AI agent gets to itself: its own filesystem, its own runtime, its own network access, walled off from everything else. The agent can install things, write files, run code and read the results, the way a person would at a terminal, and nothing it does reaches anything outside that boundary.
The isolation is the point. An agent that can only call pre-approved tools is limited to what someone anticipated. An agent with its own machine can do work nobody wrote a tool for. The sandbox is what makes the second one safe enough to allow.
In practice that is the work that does not fit in a chat reply: analysing a spreadsheet properly, processing files in bulk, research that takes an hour, anything long enough that you would rather it ran somewhere else while you got on.
What Agent Sandbox gives you
Made by describing it
Tell your AI tool what the agent should do, and it builds the agent in a space. Runwork hosts it, so the person who needs the agent can make it, with no developer and no dev environment.
Its own computer for every task
Each task gets a real computer with a file system, web access, MCP tools and your integrations, so the agent can do what a developer does at a terminal, safely behind its own boundary.
Your team's skills and tools come along
The sandbox starts with the team's skills, MCP servers and connected tools already in place. Nobody copies credentials or instructions into it.
Budgets you set
Your credit balance is the ceiling, each agent can have its own budget, turn limit and timeout, and a single task can be held tighter still. At 90% the agent is told to wrap up, and at 100% it stops and hands back what it has.
Watch it work
The Agents dashboard shows every tool call, output and error as it happens, with the tokens and cost of each run. A failed run can be retried with one click.
Pick up where it stopped
Pass a previous session and the agent continues with the full context of the work so far, for long analysis, rounds of revision or projects that run over several days.
Agents that hand work to each other
Agents read each other's outputs and continue previous sessions by sharing files, so one agent can pick up where another stopped.
For developers too
Every agent gets the run_agent_task tool automatically. Apps can call runAgentTask() in code for full control over inputs, outputs and limits.
Access from anywhere
Desktop & Web
Watch execution streams in real time from the Agents Dashboard. See tool calls, costs, token usage, and output files. Retry failed runs with one click.
CLI
Why Agent Sandbox matters
- Made for business teams: describe the agent, and Runwork hosts it
- Sandboxes are provisioned automatically. No servers or containers to manage.
- Workspace credentials flow to the sandbox, so nobody handles API keys.
- Agents, apps and automations run on one managed platform, with sign-in, data and integrations ready
- It runs a real coding agent at a real terminal, not a cut-down version built for a product demo.
How Agent Sandbox works
Most agent sandboxes are built for developers: you get an SDK, a container image and an API key, and connecting it to your business is your job. Runwork starts from the other end. Your team already has its skills, files and connected tools in Runwork, and the Agent Sandbox gives your AI agents a computer that already has all of it.
You make the agent the same way you make an app or an automation: describe it to the AI tool you already use, and it builds it in a space. Runwork hosts it. When the agent takes on something large, such as a folder of files to process or a report that needs code, it hands the task to a coding agent running in an isolated sandbox, and the results come back as files.
The sandbox runs with your team's context: your skills, MCP servers, integrations and data. Agents share work through files. Every agent session lives in /workspace/agents/, where other agents can read previous outputs and continue where someone left off.
Costs are held in three layers. Your platform credit balance sets the ceiling. Agent definitions set per-task budgets, turn limits and timeouts. A single task can tighten these further. At 90% of budget, the agent gets a warning to wrap up. At 100%, it stops and returns whatever results it has.
The Execution Stream in the Agents dashboard shows what your sandbox agents are doing: every tool call with its inputs, text responses, errors and status changes, all with timestamps, updating while the agent runs. Each run also shows its input and output tokens and its cost in USD. For developers, the agent's run_agent_task tool and runAgentTask() in app code give full control, and runwork agents execution <sessionId> shows the same stream in the terminal.
Frequently Asked Questions
What is an agent sandbox?
Do I need to be a developer to run agents in a sandbox?
Why do AI agents need a sandbox?
What is agentic AI sandboxing used for?
How is that different from giving an agent tools?
What can agents do in the sandbox?
How do agents share data with each other?
Do I need to create an app to use agent sandboxes?
How are costs controlled?
Which AI actually runs in the sandbox?
Can I run coding agents in isolation from each other?
How do I sandbox agents running inside my own team's tools?
Use Cases
Related Features
See How Teams Use Agent Sandbox
Ready to try Agent Sandbox?
One shared cloud under the AI tools your team already uses.