Local vs cloud AI agents: where should the work run?
Choose where the agent works by the accounts it uses, the files it needs and the rules that apply when it acts.
You give an agent a task so you can leave the work to it. Then it asks where to run: on your computer or in the cloud. Choose the wrong environment and you can spend the afternoon transferring files, signing in again or discovering that the rules you set don't cover the route it took. The local vs cloud AI agent decision starts with the task and the access it needs.
- A cloud sandbox separates the agent from your machine, but files and account access need explicit setup.
- A local agent can inherit your account's reach unless its tools run under enforced limits.
- Local execution can still depend on a cloud model and cloud coordination.
- A hybrid setup can change which permissions apply when work moves between environments.
- Choose an environment by the task's required access, continuity and evidence.
The short answer
Run an agent in a cloud sandbox when the work is self-contained, lengthy or needs to continue after you close the laptop. Run it on your machine when it needs local files, apps or signed-in accounts, with enforced limits. In either case, check whose identity it acts with and what survives the session.
A sandbox is a restricted place for software to work. Its location alone tells you little about the permissions inside it. Start with a task you can inspect, and check the product's actual settings before granting access to the working account you use every day.
What "local" and "cloud" actually mean in agent products
Separate where the model processes information, where the tools act, and where the product stores state and logins. These are distinct parts of a task, and a product can put them in different places.
In Anthropic's self-hosted sandbox, files and processes stay on your worker, while conversation history and tool results reach its service. OpenAI's local security documentation likewise distinguishes local actions from model processing: "Local execution does not mean offline or device-only model inference."
Our desktop AI agent guide covers what stays local. Here, the decision is which working environment gives the task the access it needs without lending it the rest of your life.
What a cloud sandbox gets right
A separate environment lets you give the agent a working copy without opening your everyday desktop. That suits a contained task, such as comparing a supplied set of documents and returning a draft. Several independent tasks can use separate environments, where the product supports that arrangement.
OpenAI's cloud browser works after you close your computer, pausing for input, sign-in or confirmation. It is one form of computer use agent: it acts through a browser on a remote computer.
GitHub describes its cloud sandboxes as isolated, temporary environments whose sessions you can continue across devices. Anthropic's default Managed Agents environment provides a fresh container per session without requiring you to operate it. These are product-specific arrangements; check the lifetime and interruption rules before leaving a long task running.
What a cloud sandbox cannot reach
OpenAI's cloud browser has separate sessions. It does not inherit your browser's tabs, history, saved passwords, cookies, extensions or sign-ins. Some websites block it even when they work in your browser. Sign-in availability also depends on your workspace.
Docker's comparison makes the file boundary explicit: its cloud sandbox has no access to host paths. Needed files require transfer, and the sandbox expires under its configured lifetime rules.
For a one-off document review, supplying copies can be a sensible boundary. For work that depends on a changing local folder, that transfer becomes part of the job. Decide how the agent will receive updates and how you will bring the result back before it starts editing an obsolete copy.
A separate environment also needs an account with suitable access. Signing into the same powerful account somewhere else still lends that account's authority. Separation from your desktop does not reduce what that account can do on the destination website.
What running on your machine actually hands over
Local access saves handoffs because the work is already there. It can also give an agent far more authority than the task requires.
GitHub says local sandboxing is off by default. Until enabled, Copilot's shell commands can read, change and delete wherever your account can, reach its networks and use its credentials. Enabling the sandbox constrains that reach; it does not create a separate virtual machine.
OpenAI warns that a signed-in app can expose the account's permissions. Computer Use driving a browser does not use Browser Use's site policies; native-app controls and account permissions still apply. Check each available route.
Consider a task that only needs to read a folder and prepare a draft. An account that can also submit the result has more authority than this task needs. A local sandbox, a separate account or an app-level restriction can help, depending on what the product actually enforces. Confirm which actions are possible before relying on an instruction to stop at the draft.
Hybrid setups move the boundary, they do not remove it
Hybrid means the task crosses environments. Anthropic's self-hosted option puts tool execution on your worker while its service receives the conversation and results. You operate the worker's security and lifecycle; web search and fetch still run on Anthropic's side.
OpenAI's local computer access with Work Cloud uses cloud coordination and local execution. If the computer is unavailable at a new turn, an eligible task can continue in a cloud container without local files or local enterprise requirements. It cannot make that switch during a turn.
Docker's move operation copies a filesystem snapshot, not running processes. Managed secrets and network policy do not move with it, although credentials written into copied files can travel. Configure and verify the destination separately.
Before switching, stop at a point where you can identify the current files and unfinished actions. Check the destination account and restrictions, then resume. A successful transfer proves that something arrived. It does not prove that the receiving environment has the rules you expected.
Five questions to choose for a real task
- Does the task need my files, apps or signed-in accounts? A supplied document set is easier to separate than work inside an app on your computer. Prefer the environment that reaches the necessary material with the smallest grant of access.
- Whose identity will the actions use? Identify whether the destination sees your account, a shared account or an account reserved for the agent. The account's authority should match the work you are delegating.
- Where is the policy enforced, and does it survive a switch? Check the actual tool path, including browser control and commands. If you move the task, test an allowed action and a harmless blocked action in the destination before continuing.
- What happens if I close the laptop or the session expires? Local steps require the local computer to remain available; remote work depends on the service's lifetime and pause rules. Save the output somewhere you can recover it before the working environment disappears.
- What record will exist of what it did? Require enough detail to connect the instruction to the files changed and the destination result. A completion message alone gives you little to inspect when the result is wrong.
For example, comparing supplied documents and returning a draft is a reasonable cloud candidate. Updating a document through an app available only on your computer may require local access. A workflow using both needs an explicit handoff that identifies the current version and who is allowed to change it. These are decision examples, not measured product tests.
The question underneath: whose computer is it?
In the familiar local and cloud arrangements, the agent borrows either your working account or an environment the provider operates. Both can be useful. Both leave you checking how the task's identity, restrictions and saved work fit together.
Our analysis of bolted-on agents examines that dependence on a human computing environment. The ownership argument asks who controls the continuing capability when a service changes.
Permissions need enforcement below the agent so a different route cannot silently widen its authority. An evidence trail should preserve what it actually did. Persistent memory should keep the current task available after the session ends.
Where ERIKA fits
eFreedom's one product, ERIKA, is an operating system where the user is purely AI. Its architecture puts the agent's own identity and persistent state, system-enforced permissions and work records together in the OS. Those responsibilities belong to the agent's environment instead of depending on a person to rebuild them for each task.
The AI operating system explainer covers that system layer. ERIKA is in development; this is the architecture being built, rather than a claim of tested guarantees. The ERIKA page explains how its accounts, memory and work fit together.
Frequently asked questions
Is a local AI agent more private than a cloud agent?
Local execution alone does not establish privacy. OpenAI and Anthropic both document modes where tools act on your infrastructure while task information reaches their services. Check the full data path and retention rules before treating a local setting as a privacy guarantee.
Will a cloud agent use the accounts I am already signed in to?
OpenAI's cloud browser does not inherit your device's sign-ins. You sign in separately where supported. Its own sessions can remain active until they expire or you clear the browser data. Other products need their own session checks.
Can a cloud agent keep working after I close my laptop?
OpenAI's cloud browser can, though it pauses for input, sign-in or confirmation. A step that needs your local computer requires that computer to be available. Check the service's pause and expiration rules before leaving work unattended.
What is a self-hosted agent sandbox?
In Anthropic's Managed Agents terminology, you operate the worker that executes tool calls. The model service still receives conversation history and tool results, and Anthropic runs web search and fetch. Self-hosting the worker gives you responsibility for its security and lifecycle.
Is it safe to let an AI agent run on my own computer?
Safety depends on enforced access limits and the task. GitHub documents local sandboxing as off by default, so check that setting rather than assuming containment. Restrict the working files and accounts, keep consequential actions subject to approval, and inspect the result before expanding access.
Sources
Product documentation checked October 20, 2026. Availability and controls vary by product, plan and configuration.