Laptop or cloud: where should your coding agents run?
Run each coding agent where the work needs to happen, and put the same policy, secrets and audit in front of it either way. What a laptop gives you, what a governed cloud runtime gives you, and the questions that decide which run goes where.
Run the agent where the work needs to happen, and put the same policy, secrets and audit trail in front of it on both sides. A laptop is the right home for work that depends on a developer's uncommitted context and their live services. A governed cloud runtime is the right home for unattended work that would otherwise sit on a personal machine holding broad credentials. Moving an agent to the cloud changes where the blast radius sits, not whether there is one.
The question is really three questions
"Laptop or cloud" collapses three separate decisions, and separating them is most of the work:
- Where does the code live? The clone the developer is editing, or a fresh checkout nobody has touched.
- Where does the credential live? A key on the machine, or a lease the runtime issues for one run.
- Who watches the run? A person at the keyboard, or a pipeline with logs.
A run with a fresh checkout, a lease and a pipeline is a cloud run whatever hardware it lands on. A run against the developer's clone with their personal token is a laptop run even if it executes in a container on that laptop.
What each option changes
| Property | Laptop | Governed cloud runtime |
|---|---|---|
| Host isolation | Shared with the developer's other work | Ephemeral node per run |
| Credential scope | Whatever is on the machine, often standing | Issued for the run and expiring |
| Egress control | Per-machine, if anything enforces it | Per-environment by construction |
| Audit completeness | Depends on what the endpoint records | Every call inside the box is mediated |
| Feedback loop | Seconds, in the editor | A push, a run, and a wait |
| Access to uncommitted state | Full | None, and that is the point |
| Source custody | Stays on the machine | Leaves the machine for the runtime |
| Offline use | Works | Does not apply |
Two rows decide most cases: access to uncommitted state, and credential scope.
Where the laptop still wins
The developer loop is the reason laptops exist. An agent beside an editor can read the file that is not committed yet, run the test that depends on a local service, and act on the error the developer just saw. That loop is measured in seconds, and a cloud run is measured in a push and a wait.
There are also things a laptop has that a remote runtime does not: the VPN, the licensed simulator, and the local database with production-shaped data. Some code does not leave the machine, which a laptop satisfies by default and a cloud runtime has to satisfy deliberately. None of that makes the laptop safe: it is still the machine with the standing token in a shell profile and the browser session to the production console, which is why the controls belong there.
Where the cloud wins
Unattended work is the strongest case. An agent that takes a ticket at 02:00, opens a pull request and runs the test suite has no developer watching it, so "person at the keyboard" is not a control that exists. On a laptop that run waits for someone to start it, or runs with whatever their session can reach.
The second case is credential scope. An agent doing CI-adjacent work needs to read repositories, package registries and cloud APIs. On a laptop that means a standing key that outlives the run. In a runtime, the credential is issued per run, scoped to the run, and expires. The difference is not the sandbox, it is the secret.
The third is reproducibility: a fresh checkout and a known image produce the same result on Tuesday and on Friday, with no drift from whatever the developer installed. The fourth is audit completeness, which cloud vendors undersell. A runtime that mediates every model and tool call gives you a complete record; a sandbox that only isolates the host does not.
Sandbox is not governance
The common rollout buys a sandbox, points an agent at it, and assumes the security question is answered. A sandbox answers one question: what happens to the host if the agent misbehaves.
Inside a typical sandbox the agent still has the repository, a token with push rights, package registry access and model provider APIs. It can exfiltrate through a package install, a webhook or the model prompt itself, and its own logs are process logs rather than tool calls. Ephemeral isolation limits persistence and lateral movement, not what one run can send out while it is alive.
Dev containers and hosted sandboxes sell isolation and compute (Codespaces overview, E2B docs, Modal guide), and GitHub's Copilot coding agent runs in an Actions environment (about the coding agent). Isolation is a real control, and a different one from "this agent may not read the secrets file and post it anywhere".
A concrete setup, both sides
On the laptop, the test container an agent drives does not need the network, and saying so explicitly costs one line:
services:
tests:
image: node:22
working_dir: /work
network_mode: none
volumes:
- .:/work
command: npm test
The agent itself still needs the model provider, so the container the agent lives in needs a proxy with an allowlist rather than a blanket egress rule. The test container it shells out to does not, and that is where most accidental exfiltration happens.
In the cloud, the credential should never be a stored key. GitHub Actions can mint a short-lived token for the run and exchange it for a cloud role, so nothing standing exists to steal:
permissions:
contents: read
id-token: write
jobs:
agent:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/agent-run
aws-region: us-east-1
That is the mechanism behind the credential row above, worth adopting before any agent runtime lands because it removes a standing key from the pipeline today. GitHub documents it in hardening with OpenID Connect.
Three questions that decide the placement
- Does the task need state nobody has committed? If yes, it belongs beside the developer. If it can start from a clean checkout, it can run anywhere.
- Does it need a credential the developer holds personally? If yes, that is a finding, not a placement decision. Replace the standing credential with a lease and the run becomes movable.
- Will anyone watch it run? Unattended work needs the runtime to be the control, because a person is not there to be the control. Human approvals for AI agents covers the rest.
A fleet usually lands on a split: interactive work on laptops under endpoint policy, bulk or credential-heavy work in the runtime, one policy language over both.
How Alyria covers both sides
On the laptop, Alyria Beacon is a signed, user-space daemon with no kernel driver. It inventories the AI tooling and MCP configuration on each machine, evaluates Lyra policy locally on every MCP and model call, and enforces egress at the endpoint, all with no cloud round trip, so it keeps working offline. Enforcement is opt-in and starts in monitor mode, which lets you see what a rule would have done before it stops anyone's work.
In the cloud, Statio is the governed runtime. It hosts the agent on a node governed by Alyria Beacon in your cloud, raised per GitHub or Jira event, where the agent receives its skills, flow and Lyra policy. Every model and tool call is mediated by Alyria Beacon by construction rather than by a proxy beside the agent, the difference between a control the agent can bypass and one it runs inside. It is engine-agnostic across Claude, Codex and framework agents.
Both are one system from above. One Lyra policy applies on the laptop and in the runtime, Umbra issues the short-lived leases in both places, Spectra emits the same OpenTelemetry from both, and Observatory reports one fleet with one signed record. Moving a run from a laptop to the runtime changes where it executes, not which control applies.
For which layer sees which surface, the comparison guide puts endpoint governance, gateways and cloud runtimes side by side. For what a coding agent's call looks like to each of them, start with what EDR cannot see and what agent detection and response covers.
Try it with Alyria
Move one background job into a governed runtime and leave the interactive work where it is. The policy you wrote applies to the run unchanged, and the record comes back with the tool calls. Start free and read the Statio page.
Frequently asked questions
Is a cloud runtime more secure than a laptop? It is more controlled, which is not the same thing. Isolation and per-run credentials remove whole classes of problem, but source code moves somewhere new to govern, so the outcome depends on what you enforce inside it.
Can we keep everything on laptops and still pass an audit? You can, if the endpoint has real policy enforcement and a record the auditor can verify. The failure mode is per-client, per-developer controls, where coverage depends on which editor someone installed.
What about agents that vendors run in their own cloud? A vendor-hosted agent sits outside your endpoint and your runtime, so your controls are the repository permissions and the scopes you grant. Treat it as a third placement with its own review, and read the gateway comparison before assuming a proxy covers it.