AI-native
Should an AI agent run on a server or in a sandbox?
Usually both. The part of an agent that has to be awake all the time, listening for messages, remembering context and holding keys, belongs on a server you control. The risky work it does, such as running code a user or a model wrote, belongs in a fresh sandbox that holds none of your secrets and is thrown away when the task ends.
Updated November 6, 2026
Why split an agent in two?
The two halves have opposite needs. The always-on half must be reachable, keep state for weeks and hold credentials. The task half runs code nobody has reviewed, which might be buggy, slow or hostile. Putting them together means untrusted code runs next to your keys and your memory store. Splitting them means the worst a bad task can do is wreck a machine you were going to delete anyway.
What goes where?
Sandboxer's guide on whether an AI agent should live on a server or in a sandbox sorts the jobs like this:
| The agent needs to | Put it on |
|---|---|
| Receive webhooks, chat messages or email | The always-on side |
| Keep long state, such as history or a task queue | The always-on side |
| Run on a schedule | The always-on side |
| Hold credentials: model keys, chat tokens, its Sandboxer key | The always-on side |
| Reach your own network or a GPU you own | Your own machine |
| Run code a user or a model wrote | A fresh sandbox per task |
| Run heavy builds or tests | A sandbox |
| Do several things at once | One sandbox each |
Isn't a fresh sandbox per task slow?
Not any more. In the guide's test on October 31, 2026, creating a sandbox took 156 to 256 milliseconds, and a small task ran end to end in about half a second. The task sandboxes were created with no account secrets in them and a 10-minute deadline as a backstop, then deleted.
What key should the always-on side hold?
A narrow one, never the account key. The guide picks actions by hand: create sandboxes, read and update them, run commands, write files and delete only the sandboxes the key created, with a short expiry. With that key, trying to mint an admin key was refused. The guide also notes a subtlety: a key allowed on all sandboxes can run commands in any sandbox in the account, not only its own, so fence it further where you can. See how long an AI agent's API keys should last.
Can the always-on side itself be a sandbox?
Yes. It can be a server you run, or a long-lived Sandboxer sandbox. Stopping a sandbox saves its memory as well as its disk, so a long-lived agent picks up where it was after a resume. What matters is the separation: the long-lived machine holds the keys, and the throwaway ones don't. For the coding-agent version of this question, see coding agents in the cloud.
How does this fit with the rest of an agent's safety?
The split limits what a bad task can reach. Pair it with an approval step for the actions that matter, described in how to add human approval to an AI agent's actions, and with limits on spending, in how to stop an AI agent from overspending.
Frequently asked questions
Can untrusted code in a sandbox read my agent's API keys?
Not if the keys stay on the always-on side and the task sandbox is created without your account's secrets, as the split recommends.
Should I reuse one sandbox for many tasks?
For code you don't trust, use a fresh sandbox per task and delete it afterwards, so nothing one task leaves behind affects the next.
Can an agent running in a sandbox reach my home network?
No. Sandboxes can't reach your network, which is why work that needs your LAN or your own GPU stays on your machine.
Does Sandboxer have GPUs for the task side?
No. Sandboxer sandboxes are CPU only.