# Why coding agents belong in remote sandboxes > Source: > Published: 2026-08-04 18:12:30+00:00 Today's coding agents don't just write code; they operate software environments. Agents inspect repositories, run shell commands, install dependencies, start services, open browsers, call CLIs, read test output, and keep working for long stretches while a developer is away. That power is useful, but it changes the security model. When a company runs agents on developer laptops, the agents often get the same access as the developers. This can include SSH keys, cloud credentials, package tokens, browser sessions, local files, VPN routes, and internal systems. Much of this access can remain on a laptop for years. Enterprise concern about this is rising quickly. [Salt Security research](https://www.prnewswire.com/news-releases/new-research-reveals-9-in-10-security-leaders-concerned-about-ai-generated-code-risks-302788323.html) found that 90% of security leaders are concerned about risks from AI-generated code, while [Red Hat](https://www.redhat.com/en/blog/ai-code-paradox-moving-fast-without-breaking-security) has warned that unrestricted AI-assisted development creates security and compliance gaps. The concern is not just bad code. It is what happens when increasingly capable coding tools run unchecked on individual employee laptops. ## Local agents inherit laptop access Most local coding-agent setups begin with a reasonable assumption: the agent should have access to the same tools as the developer. In practice, though, a developer laptop usually contains more access than one task needs. The most obvious risk is credential exposure. A laptop may have deploy keys, GitHub tokens, cloud profiles, database URLs, package manager tokens, SSH agent access, and one-off secrets that were never meant to be part of an agent task. An agent does not need malicious intent to expose a secret. It can print an environment variable in a log or add a credential to generated code. It can also run a diagnostic command that shows sensitive data. The next risk is network access. A laptop can usually reach internal tools, staging systems, admin panels, and private package registries. An agent troubleshooting a failing test may make HTTP requests, run a CLI, fetch a dependency, or follow a link without understanding which systems are sensitive. If agents can reach all the same places as the developer, "just let agents investigate" becomes a security concern. Finally, local agents are hard to audit consistently. A terminal transcript may show some commands, but it usually does not capture the full environment boundary: which secrets existed, which network paths were reachable, which long-running services were present, or which files outside the repository were available. ## Remote sandboxes let teams control access Remote sandboxes move the agent's working environment into company-controlled infrastructure. Instead of giving an agent a long-lived personal workstation, each implementation runs in a dedicated environment with the repository, tools, and project configuration that the task needs. This matters because teams can decide what the agent gets access to, instead of inheriting whatever happens to be on one person's laptop. **Repository isolation:** Each implementation can work in its own lane, so parallel agents do not trample one another's files or depend on a developer's dirty working tree.**Scoped secrets:** The sandbox only gets the secrets the project needs, not every credential present on a laptop.**Network controls:** The environment can restrict outbound access to approved domains and package registries instead of inheriting broad VPN or workstation access.**Temporary state:** The team can discard the sandbox after the task. This removes temporary files, caches, background processes, and accidental changes.**Central audit records:** The team can review agent commands, logs, diffs, and decisions in one place. These records stay with the ticket rather than being scattered across personal machines. Remote sandboxes also reduce engineering risk. Local agent work is siloed on one machine: teammates cannot easily jump in, reproduce the environment, or identify the local settings that changed the result. In a remote sandbox, the team shares the project setup, services, startup commands, test commands, and secrets. Plus, each parallel implementation runs in its own isolated sandbox, so agents can work at the same time without stepping on one another's files, processes, or databases. Switching to a remote sandbox doesn't mean every agent is trusted unconditionally. It means every agent is useful inside a tighter, controlled environment. ## What about local sandboxes? Of course, coding agents don't completely roam free on laptops. Codex, Claude Code, and other agents all include multiple degrees of local sandboxing, permission prompts, command approval, filesystem restrictions, and network controls. Local sandboxing has gotten much better, and teams should use it. However, local and remote sandboxes solve different problems. Local sandboxing adds a protection layer inside a developer-controlled workstation. The exact protection depends on the tool, operating system, shell configuration, project setup, and the permissions an individual developer grants in the moment. It may reduce accidental file access or require approval before risky commands, but it still lives near that one developer's credentials, browser sessions, VPN routes, package caches, local databases, and personal configuration. Stricter permissions in local sandboxes can also lead to developers gravitating towards YOLO mode. In [a post about local coding-agent safety](https://noriagentic.com/newsletter/2026-06-06-local-coding-agents-unsafe.html), Amol Kapoor from Nori describes the tension between autonomy, convenience, and local controls. Stronger local permissions help, but they also create approval fatigue. This leads developers to drift towards more permissive modes, and permissive modes bring the agent closer to everything on the developer's machine. For an individual developer, local sandboxes can be a good default for lightweight tasks. For a company standardizing agent usage across a team, the harder questions apply to the whole organization: - Can we define a default org-wide or project-wide network policy once, instead of relying on each laptop's settings? - Can we share secrets only when a project needs them, instead of giving agents default access just because a developer has them? - Can every implementation start from a clean environment, regardless of who launches it? - Can the team review work logs, blocked network requests, diffs, and environment setup in one place? - Can we monitor agent use and token costs across the org? Remote sandboxes do not replace tool-level sandboxing. They add a team-controlled boundary around it. A coding agent can still have command approvals and filesystem controls inside the sandbox, but the sandbox itself is no longer the developer's laptop. ## What remote sandboxes should include A sandbox is only useful if it is actually constrained. At a minimum, companies should expect: - A fresh, isolated workspace for each agent attempt. - Project-level setup for runtimes, services, startup commands, and test commands. - Secret injection that is explicit, scoped, and revocable. - Network sandboxing with a restricted default and an approval path for new domains. - Logs that show command execution, blocked access, environment setup, and agent reasoning. - A review workflow that keeps humans in control before changes are merged or deployed. - A usage dashboard for monitoring token spend, agent usage, and workspace activity across the company. This is the model Superconductor is built around. Each agent gets a remote cloud environment with the project setup it needs, scoped credentials, network policy, work logs, live previews, and review context. Teams can also use [network sandboxing](https://www.superconductor.com/blog/network-sandboxing) and [workspace usage visibility](https://www.superconductor.com/docs/workspace/usage) to control and review agent activity across the company. As coding agents become a normal part of software teams, "where does the agent run?" becomes a security architecture question. For most companies, the answer should not be "wherever a developer happens to have a terminal open."