# What Makes a Cloud Dev Workspace Secure for Coding Agents?

> What makes a cloud dev workspace secure for coding agents: isolation, credential custody, network egress, and an audit trail, with a dated vendor checklist.

Published October 17, 2026 · by the AQ team · Canonical: https://aq.dev/guides/secure-cloud-dev-workspace-for-coding-agents/

A secure cloud dev workspace for a coding agent is one where four boundaries hold at once: isolation (the agent's blast radius is one disposable machine, not your laptop or your network), credential custody (secrets the task does not need never reach the machine the agent works on), network egress (the workspace can only talk to destinations someone chose on purpose), and an audit trail (you can reconstruct afterwards what the agent read, ran, and sent). As of October 2026, the major hosted options (Claude Code cloud sessions, OpenAI's Codex cloud, GitHub Copilot's coding agent, Cursor's cloud agents) all implement some version of all four; they differ in the defaults, in what each boundary covers, and in who holds the keys, and those differences are what to evaluate.

## Why coding agents need their own security model

A coding agent is a program that runs shell commands chosen by a language model, and the model chooses based on text it reads: your code, your issue tracker, a README in a dependency, a web page. Prompt injection is when some of that text was written by an attacker to steer the model. The failure chain is read hostile instructions, run a command, send something valuable out. Approval prompts guard the middle step; the workspace guards the rest: isolation decides what a bad command can destroy, custody decides what it can steal, and egress decides where it can send anything.

The vendors treat this as a live threat. GitHub ships Copilot's coding agent behind a default-on firewall and still warns, as of October 2026, that sophisticated attacks may bypass it; Anthropic's cloud session docs note that even with network access disabled, Claude Code still talks to the Anthropic API, which may allow data to exit the VM. Caveats like these are a good sign: the dishonest version is a security page with no stated limits.

## Isolation: one disposable machine per task

Isolation means the agent executes inside a boundary the operating system or hypervisor enforces, so the worst a bad command can do is wreck an environment you can throw away. The unit matters. As of October 2026: each Claude Code cloud session runs in an isolated, Anthropic-managed VM; each Codex cloud task runs in an isolated, OpenAI-managed container; each Cursor cloud agent runs in its own VM boundary on Firecracker-based microVM infrastructure; and Copilot's coding agent runs inside an ephemeral GitHub Actions environment. A VM boundary is stronger than a shared-kernel container, and both are stronger than an agent loose on your laptop; [coding agent sandboxes explained](https://aq.dev/guides/coding-agent-sandboxes-explained/) walks the full spectrum.

Ask what happens to the environment afterwards, because "disposable" is a retention policy, not a feeling. Cursor, for example, documents that workspace snapshots are deleted after 30 days of inactivity. If a vendor cannot tell you when the machine and its disk cease to exist, that is your answer.

## Credential custody: what never reaches the workspace

Credential custody means secrets live outside the environment the agent can read, and reach a task only in the narrowest form the task needs. Assume anything on the machine can end up in a prompt or an outbound request, because reading files and running commands is the agent's whole job. The strong patterns, all shipping as of October 2026: Claude Code's Anthropic-hosted cloud sessions keep GitHub credentials encrypted on Anthropic's servers, where they never enter the session's VM; git operations go through a proxy that attaches scoped credentials server side. Codex cloud exposes secrets only to setup scripts and removes them before the agent phase starts, so the model never runs alongside them. Cursor injects secrets as environment variables and can mark a value as a runtime secret kept out of the transcript, tool output, and commits.

Whatever the platform, scope the tokens themselves: a fine-grained GitHub token limited to one repository beats an account-wide classic token, and per-person credentials beat a shared bot account because revocation and blame stay individual. [Safe AI coding agents on your own repos](https://aq.dev/guides/safe-ai-coding-agents-on-your-own-repos/) covers least-privilege setup; [keeping secrets out of coding agent prompts](https://aq.dev/guides/keep-secrets-out-of-coding-agent-prompts/) covers the half custody cannot fix.

## Network egress: default-deny, or at least a chosen allowlist

Egress control means the workspace can only open connections to destinations on a list someone chose, so stolen data has nowhere to go and injected instructions cannot phone home. This is where the shipped defaults differ most, as of October 2026. Codex cloud is the strictest: setup scripts run with internet access to install dependencies, then agent internet access is off by default, with wider access an explicit opt-in. Copilot's coding agent is firewalled by default with a recommended allowlist for dependency downloads plus custom allowlists; a blocked request adds a warning to the pull request showing the blocked address and the command that made it. Claude Code cloud sessions limit network access by default, and an environment can turn it off or restrict it to chosen domains. Cursor cloud agents start with internet access on, restrictable to allowlisted domains, and admins can lock that policy org-wide.

Read the scope line as carefully as the default: GitHub documents that Copilot's firewall applies to processes the agent starts through its Bash tool, not to MCP server processes, and Claude Code's local sandbox similarly proxies shell commands while other tools run outside it. A boundary that covers one tool is still useful, but only if you know which tool it covers.

## Audit trail: can you reconstruct what the agent did?

An audit trail means that after the session you can answer, from records rather than memory, what the agent read, ran, changed, and sent. The hosted products keep the transcript and the diff as a matter of course, and the better ones surface security events in the flow of work: Copilot's blocked-request warnings land on the pull request itself, turning the firewall into a visible log, and Claude Code can export usage and tool-activity events to a customer-run OpenTelemetry collector. The trail is what makes the other boundaries checkable: an egress allowlist you cannot see violations of is a policy, not a control. A trail does not undo anything; [limiting what a coding agent can destroy](https://aq.dev/guides/limit-what-a-coding-agent-can-destroy/) covers containment and recovery.

## The shipped defaults at a glance (October 2026)

| Product | Isolation unit | Agent-phase network default | Credential handling |
| --- | --- | --- | --- |
| Claude Code cloud sessions | Isolated Anthropic-managed VM per session | Limited by default; can be disabled or set to chosen domains | Git credentials stay on Anthropic's servers; a proxy attaches scoped credentials outside the VM |
| Codex cloud | Isolated OpenAI-managed container per task | Off by default; limited or full access is opt-in | Secrets available to setup scripts only, removed before the agent phase |
| GitHub Copilot coding agent | Ephemeral GitHub Actions environment | Firewall on by default with a recommended allowlist | Repository secrets via Actions; firewall covers Bash-started processes only |
| Cursor cloud agents | Own VM boundary on Firecracker microVMs | On by default; restrictable to allowlisted domains, lockable org-wide | Encrypted secrets; runtime secrets hidden from transcript and commits |

Every row was verified on the vendor's own documentation in October 2026; defaults move, so re-check before relying on them.

## The questions to ask any vendor (October 2026)

1. **Isolation:** What is the unit, a VM or a container, and is anything shared between customers or tasks?
2. **Isolation:** When does the environment and its disk get destroyed, and is that documented with a number?
3. **Custody:** Which credentials ever exist inside the workspace, and which are attached outside it (proxy-side git auth, setup-only secrets)?
4. **Custody:** Can I scope access per person and per repository, and revoke one person without rotating a shared key?
5. **Egress:** Is agent-phase network access off or allowlisted by default, and can an admin lock the policy?
6. **Egress:** Which processes does the network control cover, and which (MCP servers, setup scripts, the model API channel) bypass it?
7. **Audit:** Where do I see what the agent ran and what was blocked, and can I export that trail to my own systems?
8. **Audit:** Who on my team can see a session while it runs, and who decides that?
9. **Residency:** Whose cloud account does execution happen in, and can it be mine? (If that boundary is the requirement, [self-hosted AI coding agents](https://aq.dev/guides/self-hosted-ai-coding-agents/) compares the routes.)
10. **Honesty:** Does the security page state its own limits?

## Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Against the four properties, AQ's answers are structural. Isolation and residency: there is no shared multi-tenant execution tier; agents run on a VM that is yours, either machines you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, and every workspace gets its own isolated git worktree so parallel tasks cannot touch each other's checkouts. Custody: each engineer logs into the agent CLIs with their own Claude or OpenAI account, and commits and pull requests use per-user GitHub auth, so revoking one person means revoking one person's credentials. Audit: agents run as real CLIs in persistent tmux sessions streamed live to the browser, teammates can open the same workspace and watch the same live session, and workspace visibility is owner-managed, team-visible or private and shared with specific people. Runner health shows in the product, the installer runs preflight checks, and an aq-runner doctor command diagnoses a broken host.

Pricing is two plans. The Free plan is a personal sandbox for one person: AQ creates a private machine in an isolated network, with nothing to install and no time limit, which is also the evaluation path. The AQ Pro plan is $50 per user per month early access (standard $200, billed monthly), covers VMs you connect from your own cloud or a dedicated AQ-managed VM, and locks your rate for your first 12 months.

Plainly: if a hosted product's defaults in the table satisfy your policy, use it. AQ earns its place when the boundary you need is "execution in our own cloud, visible to the whole team," because that is the shape of the product rather than a tier.

## Frequently asked questions

### Is it safe to let a coding agent run autonomously in a cloud workspace?

Safer than on a laptop, if the four boundaries hold. An agent on your laptop runs next to your SSH keys, your browser sessions, and your whole home directory. A disposable cloud workspace limits the blast radius to one machine built for the task, holds only the credentials that task needs, and restricts where data can go. The honest caveat: autonomy plus network access is the risky combination, so the more autonomous the run, the tighter the egress policy should be.

### Do cloud coding agents send my code to the vendor?

For hosted products, execution happens on the vendor's infrastructure, so the repository clone is there while the task runs: as of October 2026 Codex cloud checks your repo out into an OpenAI-managed container, Claude Code cloud sessions clone it into an Anthropic-managed VM, and Cursor documents that workspace snapshots persist until deleted after 30 days of inactivity. Separately, prompts carrying code context go to the model provider under its data terms wherever the agent executes. If execution in your own account is the requirement, that is a different product shape: self-hosted or own-cloud harnesses.

### What network access should a coding agent have?

As little as the task needs, chosen on purpose. The pattern the strictest vendors ship as of October 2026: full access during environment setup (installing dependencies), then default-off or allowlist-only while the agent works. A practical allowlist is your package registries, your git host, and nothing else. And insist on visibility: GitHub's Copilot coding agent writes a warning on the pull request naming every blocked address and the command that tried it, which is the behavior you want from any egress control.

### How do I keep my GitHub token safe when an agent works in the cloud?

Prefer platforms where the token never enters the agent's environment at all: Anthropic-hosted Claude Code cloud sessions keep git credentials on Anthropic's servers and attach them through a proxy outside the VM, with scoped permissions per operation. Where the token must exist in the workspace, make it fine-grained (one repository, minimal permissions), per person rather than shared, and short-lived where the platform supports it, so a leaked token bounds the damage to one repo and one revocation.

### Can a prompt injection attack steal code from a cloud agent workspace?

It can try, and the workspace decides whether it succeeds. The attack needs the agent to read hostile instructions, act on them, and move data out. Isolation does not stop the reading, and approval prompts are imperfect against step two, which is why egress control matters: with the agent-phase network off or allowlisted, there is nowhere to send the data. Vendors are candid that this is not absolute: as of October 2026 GitHub warns sophisticated attacks may bypass Copilot's firewall, and Anthropic notes the model API channel remains open even with network access disabled. Layered boundaries plus an audit trail is the honest state of the art.

---

About AQ: AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Start at [aq.dev](https://aq.dev/).