A cloud coding agent is a program that writes and runs code on a machine you do not watch, using credentials you handed it, against a repository your business depends on. Before anyone asks whether its work is finished, an engineering lead has to answer a plainer question: if this agent does something wrong, or is told to do something wrong by text it read, how far can the damage travel? That is a containment question, and it comes before every proof question.
The pressure to answer it is growing. McKinsey's State of AI survey (November 2025) found that 88% of organisations use AI in at least one business function, while only about a third have moved it into production. Coding agents are, in our view, a natural place for that gap to close, because the work is well specified and the output is a diff. The machine those agents run on is where the risk concentrates.
This guide is about execution isolation: what the agent's machine can reach, which secrets it holds, and whether it can change the base branch. It deliberately cedes two neighbouring questions. The merge gate and review queue belong to our post on an engineering review queue for AI agents, and the question of which tools an agent may call belongs to our post on governing an MCP skills library. Identity and security frameworks for agents sit in our AI agent task verification guide.
This guide is shipped by the team behind Cognibl, work management where people and AI agents share one board and a task reaches done only with proof attached. Or see DATS, our five-stage system for placing AI inside enterprise operations.
What does isolation mean for a cloud AI coding agent?
Isolation for a cloud AI coding agent means limiting four things: the machine the agent's code runs on, the credentials that machine holds, the network destinations it can reach, and the repository branches it can change. Cognibl, from DILR.AI, and every other agent platform should be judged on all four, because an agent that is contained on one boundary but open on another is not contained.
The four boundaries are not independent. Anthropic made the point plainly when it shipped sandboxing for Claude Code in October 2025: "It is worth noting that effective sandboxing requires both filesystem and network isolation." The same Anthropic engineering post explains why. Without network isolation, a compromised agent could send out sensitive files such as SSH keys; without filesystem isolation, it could escape the sandbox and reach the network anyway. A strong wall on one side and an open door on the other gives you the cost of isolation without the benefit, which is why our approach treats containment as one design rather than four purchases.
For a buyer, that turns into four questions to put to any vendor, written as plain sentences rather than features:
- Compute. Does each agent get its own kernel, or does it share one with other agents and other customers?
- Credentials. What secrets are inside the machine while the agent runs, and how long do they live?
- Egress. Which hosts can code inside the machine contact, and who decides?
- Repository. Which branches can the agent push to, and who presses merge?
The rest of this guide takes each boundary in turn, sets out what a Firecracker microVM actually buys, and is honest about what it does not. If you are deciding how agents fit your delivery model before you pick a platform, our AI operating model work covers that design question first.
Why does a microVM isolate more than a container?
A microVM isolates more than a container because each microVM runs its own guest kernel behind a hardware virtualisation boundary, while containers on one host share the host's kernel. Firecracker, the open-source virtual machine monitor AWS built for Lambda and Fargate, keeps that VM boundary but strips the device model down far enough that a microVM starts in a fraction of a second.
The Firecracker project describes the design in concrete terms. A microVM exposes only five emulated devices: a network device, a block device, a vsock device, a serial console and a minimal keyboard controller used only to stop the machine. That small surface, with a streamlined kernel loading process, enables "a < 125 ms startup time and a < 5 MiB memory footprint", and the project says a host can create up to 150 microVMs per second. Figures of that order make a virtual machine per agent a practical design choice rather than a heavy one.
The production record matters as much as the design. The Firecracker paper presented at NSDI 2020 reports that it runs in AWS Lambda and Fargate, where it supports millions of production workloads and trillions of requests per month. That is a long production record for an isolation boundary. For a regulated buyer, that public record is the kind of evidence worth asking any vendor for, and an AI placement diagnostic helps decide which workflows need it.
Firecracker also layers defences rather than relying on the virtualisation boundary alone. The Firecracker design document states that seccomp filters are applied by default to limit the host system calls the Firecracker process can make, and recommends starting it through a companion program called the jailer, which uses cgroups, namespaces and dropped privileges. The project site puts it directly: the jailer "provides a second line of defense in case the virtualization barrier is ever compromised."
None of this makes a container a bad choice for trusted, single-tenant work. The difference is the failure mode. In a container, a kernel vulnerability can be a path to every other workload sharing that host kernel. In a microVM, the same vulnerability gets the attacker a kernel that belongs to one agent, with the jailer still between it and the host. Choosing between the two is an architecture decision that belongs in a wider AI plan, which is where our enterprise AI consulting guide starts.
How does Cognibl isolate each cloud agent?
Cognibl isolates each cloud agent in its own Firecracker microVM on AWS, with its own kernel, running as a non-root user with no cloud credential. Cognibl says each task runs as a fresh process, the agent holds a token scoped to that one task and revoked when the run ends, and git runs through a proxy so the agent cannot push to the base branch.
Each of those statements comes from the Cognibl cloud agents page, and they cover three of the four boundaries plus process separation. The right-hand column is our reading of what each control limits, not a Cognibl statement:
| Boundary | What cognibl.com states | What it limits (our reading) |
|---|---|---|
| Compute | A Firecracker microVM per agent, with its own kernel; the agent sleeps when its queue is empty | A kernel escape reaches one agent's machine, not a shared host kernel |
| Process | Non-root, and a fresh process per task, "so nothing from one task leaks into the next" | Leftover state from one task reaching the next |
| Credentials | No cloud credential; a token scoped to one task and revoked when the run ends | The lifetime and reach of anything an attacker could steal from the machine |
| Repository | Git runs through Cognibl's proxy; "Your repo key never enters the machine"; a push to the base branch is refused | An agent overwriting the branch the business ships from |
Two further details from the same page close common gaps, and our plain guide to what Cognibl is covers the statuses they rely on. A run that ends without proof moves the task to Blocked with a comment, and the task's effort level sets a wall-clock budget, so a stuck agent stops on its own rather than running until someone notices. And an agent that finds nothing to change can end the run as "nothing to do" instead of inventing a change to justify the run.
Isolation is the precondition, not the product. What the isolated agent produces still has to clear the done gate: on Cognibl, a task reaches a done status only once a proof version is attached, and the database refuses the move without one. That rule applies to a person and to an agent alike, and the proof of done guide explains how the evidence is structured.
The same containment logic underpins our AI execution office, where agent work runs under named human owners and a weekly review cadence.
What can an isolated coding agent still reach?
An isolated coding agent can still reach whatever its network path, its tool connections and its proxy allow. A Firecracker microVM contains code execution, but Firecracker itself performs no network filtering, so egress control, tool permissions and write access are separate decisions. Cognibl's own pages are explicit about tool writes; buyers should ask directly about network egress.
Three points are worth stating plainly, because a vendor's isolation story is only as good as its weakest boundary.
Network egress is a separate control. The Firecracker design document says the monitor "does not perform any network traffic filtering" and that all egress traffic from a guest "should be filtered at the host-level". In other words, a microVM is not a firewall. The Cognibl cloud agents page describes compute, credential and repository isolation but does not describe an egress policy for the agent machine. That is not evidence of a gap; it is a question to ask before rollout. Compare GitHub, whose documentation states that "By default, Copilot's access to the internet is limited by a firewall." If you want those questions written into a procurement checklist, talk to our team.
Tool writes do not go through the microVM. Cognibl reaches outside tools through a gateway, and the Cognibl connections page sets out the current rule. Read is the default for every tool. Writing is a level an owner or admin can tick only when connecting Google Workspace, and every other tool is read-only. The page is candid about the consequence: "These writes go straight to Google with nothing held for approval, so a wrong send is sent." If you tick a write level, the containment for that action is your choice of scope, not the virtual machine. Which write levels to allow is an operating decision, and our DATS consulting team helps clients set that policy workflow by workflow.
Credentials for tools stay outside the agent. On the same page, Cognibl says an agent authenticates with a key Cognibl created, of which only a hash is stored, and the gateway holds the tool credential and makes the call. "The agent receives the result, never the token that fetched it." Every call, allowed, refused or failed, is written to an append-only, hash-chained trace that is redacted at the moment of capture and written by the gateway rather than reported by the agent. The page does not list what is redacted, so ask which values the trace keeps before you rely on it to reconstruct an incident.
How do Copilot, Codex and Claude Code isolate agent work?
GitHub Copilot, OpenAI Codex and Claude Code each isolate agent work differently. Copilot's cloud agent works in an ephemeral cloud environment, pushes to a single branch and sits behind a default firewall. Codex Cloud, in its legacy documentation, blocks internet access during the agent phase by default. Claude Code sandboxes shell commands on the developer's own machine with operating-system controls.
GitHub's risks and mitigations page for the Copilot cloud agent sets out its repository controls in detail. The agent can push to a single branch: a new copilot/ branch in most cases, or the existing pull request's branch when someone mentions it on that pull request; it is also subject to branch protections and required checks. The agent cannot approve or merge a pull request, the person who asked it to open a pull request cannot approve that pull request, and by default workflows do not run on its code until a user with write access approves them. The Copilot firewall documentation is honest about its own limit: the firewall "should not be considered a comprehensive security solution".
OpenAI's documentation for Codex Cloud internet access, which OpenAI now labels as the legacy Codex Cloud experience, states that "By default, Codex blocks internet access during the agent phase", while setup scripts still run with internet access to install dependencies. It lists the risks of switching agent access on: prompt injection from untrusted web content, code or secret exfiltration, malware and licence-restricted content. SaaS teams weighing these tools against their own stack will find the sector view in our SaaS and tech industry guide.
Claude Code takes a different shape because it usually runs on the developer's own machine. Its sandboxing documentation describes an operating-system boundary around shell commands: Seatbelt on macOS, bubblewrap and socat on Linux and WSL2, with no direct network route and connections forced through a proxy. Anthropic's engineering post reports that in its internal usage, sandboxing reduces permission prompts by 84%. The same page notes that default reads cover most of the machine, including credential files, unless you deny them.
| Control | Copilot cloud agent | Codex Cloud (legacy docs) | Claude Code sandbox | Cognibl cloud agent |
|---|---|---|---|---|
| Where code runs | Ephemeral cloud environment | Cloud task environment | Developer's machine, OS sandbox | Firecracker microVM per agent |
| Network default | Firewall with recommended allowlist | Agent phase offline | No direct route; proxy | Not described on the page |
| Branch limit | One branch per task | Not covered here | Not covered by the sandbox | Base-branch push refused at proxy |
| Who merges | A human reviewer | Not covered here | Not covered by the sandbox | Only a person, in the console |
Cognibl's agents drive the vendors' own tools: the cloud agents page says agents run on Codex and Claude Code, and "Each agent drives the coding tool its model's maker ships." The isolation sits around the tool rather than replacing it, which is a reasonable division of labour. More analysis of build and buy decisions like this one sits in our AI strategy archive.
What is the best way to isolate cloud coding agents in 2026?
The best way to isolate cloud coding agents in 2026 is a per-agent virtual machine with its own kernel, no standing credentials inside it, filtered egress, and a git path that cannot touch the base branch. No single platform wins on every criterion, so the right choice depends on where your code already lives and who must trust the result.
Score any platform on five criteria, weighted by your risk:
- Kernel separation. A microVM per agent beats a shared-kernel container for untrusted or multi-tenant work.
- Credential lifetime. Short-lived, task-scoped tokens beat long-lived keys inside the machine.
- Egress policy. A documented default-deny or allowlist beats an undocumented one.
- Repository write path. A proxy or branch rule that refuses base-branch pushes beats trusting the agent's instructions.
- Evidence of done. A record of what the agent did and why the task is complete beats a merged diff alone.
The criteria apply whatever tracker the team uses: a team that plans in Jira, Linear or Notion still has to answer the same five questions about the machine its agents run on. On these criteria, the trade-offs are real. A team whose code, CI and reviews already live entirely in GitHub will often be better served by the Copilot cloud agent: its branch rules, approval rules and firewall are documented in one place and enforced by the platform that already hosts the repository. A developer who wants an agent on their own laptop gets a tighter local boundary from Claude Code's sandbox than from any cloud product. Cognibl, from DILR.AI, fits best when completion itself must carry evidence rather than a status change, because a task reaches done only once a proof version is attached, and when agent work should sit on the same board as the team's own work.
A sensible rollout pairs the isolation choice with an honest view of value. Our AI developer productivity work starts from the delivery metrics you already report, not from the tool. Cognibl is built and run by Dilr.ai Ltd in London; read more about DILR.AI and the team behind it.
How should an engineering lead test an agent's isolation before rollout?
An engineering lead should test an agent's isolation by running hostile tasks in a throwaway project before granting any real access, then checking each boundary directly: try a base-branch push, read the environment for secrets, call an unlisted host, and confirm the trace records each attempt. Cognibl and its rivals should all pass the same five checks.
Run these five checks in a sandbox project with no production connections:
- Base-branch push. Ask the agent to push straight to main. On Cognibl, the cloud agents page says the git proxy refuses it; on Copilot, the agent is limited to a single branch. Confirm the refusal is visible.
- Secret discovery. Ask the agent to list environment variables and look for credential files. You are checking that nothing long-lived is inside the machine.
- Egress probe. Ask the agent to fetch a URL you control and that no allowlist would include. Whatever happens, write down the policy you observed, and get the vendor's stated policy in writing.
- Cross-task leakage. Run two tasks in sequence and ask the second to find files written by the first. Cognibl says nothing from one task leaks into the next; this check confirms it for yourself.
- Trace completeness. Compare what the agent did with what the trace recorded. On Cognibl, the connections page says refused calls are traced as well as allowed ones.
Then decide scope by risk class. Start with read-only connections, keep write levels off, and widen only when the first weeks of proof records hold. A placement diagnostic is the quickest way to agree which workflows qualify before anyone grants access, and when you are ready to scope a first workflow, book a scoping call with the operators who run it.
FAQ
Does a microVM stop prompt injection?
No. A microVM does not stop prompt injection, because injection happens in the text an agent reads, not in the machine it runs on. What a Firecracker microVM changes is the blast radius: an injected Cognibl agent still faces its own kernel, a task-scoped token and a proxy that refuses base-branch pushes. Egress filtering and read-only tool access limit what injected instructions can send out.
GitHub and OpenAI both name exfiltration among the risks of giving agents open network access, which is why the egress question in the checks above matters as much as the virtual machine.
Can a Cognibl agent merge its own pull request?
No. A Cognibl cloud agent cannot merge its own pull request. The cognibl.com cloud agents page states that a push to the base branch is refused at Cognibl's git proxy, and that merge is a button only a person can press in the console. No agent tool reaches it, so the agent's job ends at a pull request and a proof of work.
A reviewer agent can mark each line of the definition of done as met, not met or cannot tell, but the page is clear that it advises and a person decides. The full merge workflow sits in our review queue guide.
Does isolation replace a proof of done?
No. Isolation and a proof of done answer different questions. Isolation limits what a Cognibl agent can damage while it works; a proof of done shows that the work meets its definition of done. A perfectly contained agent can still produce a wrong answer, so Cognibl refuses a done status without an attached proof version, for agents and people alike.
That is why the two controls belong together in one operating model, and why the LangGraph work-management post treats the runtime and the work record as separate layers.
Want to see this in production? Read what Cognibl is, see how Cognibl cloud agents work from the board, browse our AI solutions, or read about our approach to placing AI inside enterprise systems.
Contain the agent before you trust its work.
30-min scoping call · No deck · Confidential. We will map which workflows your agents can safely take, and what proof each one must carry.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.