Tip

Agents Off the Leash is a series about AI agents, from the incidents to the controls that keep them in check.

In October 2025 I handed a feature to GitHub Copilot’s cloud agent, running Claude Sonnet (I think v4.5), and went back to what I was doing: looking after my toddler. The feature was to create a dashboard that would allow the out-of-hours on-call admin to explore analytics from the on-call data on PagerDuty for the schedule selected. What surprised me was how quickly the agent finished its job and got back to me, notifying me that the job was done and awaiting review. Later when I ran it locally, it had done a fantastic job by giving me a great starting point. I was genuinely surprised at how well it worked. I hadn’t monitored or responded to any clarifications - all I gave was a pretty detailed specification in markdown.

Note

A cloud agent is a coding agent whose loop and tools run on a vendor’s machine instead of yours: you give it a task, move on with your life, and review the output when it gets back to you.

In Your Laptop Is the Blast Radius: Running an AI Agent Locally the agent ran as me, on my laptop, with me usually at the keyboard. When delegating a task or objective to a cloud agent, the vendor runs it and nobody, as in No Human, is watching it. My earlier post on CalOohPay - a hackathon project that I later gave a web front-end using AI shared that I got notified in under 20 minutes that a feature was implemented, and also that the code sometimes “looked like it worked, but didn’t”. Both are true, and the second is why this post exists.

If you are an engineer or lead weighing a hosted agent against running one locally, by the end of this article, you’ll know:

The same four questions with new answers

The loop is the same everywhere. What changes is the environment box, the place where the tools act. In Your Laptop Is the Blast Radius: Running an AI Agent Locally I asked four questions of each box. Here are the answers for two cloud agents I can point to, based on the vendors’ own documentation: Claude Code’s cloud sessions and GitHub Copilot’s cloud agent.

#QuestionYour laptopClaude Code cloud sessionCopilot cloud agent (Actions-based) (read more)
1Who runs the loop?YouAnthropic, on its infrastructureGitHub (its docs describe the environment, not where the loop runs)
2Where do the tools run?Your machineAn isolated VM that Anthropic managesAn ephemeral environment powered by GitHub Actions
3Whose identity does it hold?YoursA short-lived credential scoped to the sessionRestricted credentials that can only push to one branch*
4What limits its network?Whatever your network allowsA network level you choose (default: Trusted)A firewall (by default, each repository decides its settings)

*GitHub documents the one-branch limit for the Copilot cloud agent. It does not say whether the limit holds in a cloud sandbox session that spans repositories.

The cells above come from each vendor’s documentation: Claude Code on the web, Claude Code: Configure cloud environments, Claude Code: Security, GitHub: Configure the development environment, GitHub: risks and mitigations and GitHub: the Copilot firewall.

Note

A VM (virtual machine) is a virtual computer simulated inside another one. Each task gets its own, so a mistake stays inside it. I wrote about how virtual machines differ from containers in an earlier post, many moons ago.

Both vendors also let an organisation run the environment on its own infrastructure: Claude Code’s self-hosted environments and Copilot’s self-hosted GitHub Actions runners.

When the agents run on your own infrastructure, isolation and the network boundary become your job, which the next post in this series picks up.

Hand-drawn diagram of the four environment questions answered for a laptop. You run the agent loop. The tools run on your machine with your files. The agent holds your identity: SSH keys, cloud credentials, .env files and environment variables, shaded red. Three red arrows run from the machine to the internet because nothing limits the network except what your own network allows. The blast radius is everything you can do.

On your laptop the agent is you. Nothing sits between it and the internet unless you add it.

Hand-drawn diagram of the four environment questions answered for a Claude Code cloud session. Anthropic runs the agent loop. The tools run in an isolated VM that Anthropic manages, holding the cloned repository and the environment you set up. The agent holds a borrowed identity: a short-lived credential scoped to the session, while your real GitHub key stays out of the VM. Four pills show the network levels None, Trusted (the default), Full and Custom. Even at None the Anthropic API stays reachable. The blast radius is what you grant it.

A Claude Code cloud session: a sealed VM, a borrowed key and a network level you choose.

Hand-drawn diagram of the four environment questions answered for GitHub's Copilot cloud agent in its GitHub Actions-based environment, one of three environments. GitHub runs the agent loop in an ephemeral environment powered by GitHub Actions. The agent holds a restricted identity: it can push to one branch only and cannot run Git itself. A brick-wall firewall, on by default, sits between the environment and the internet, with two gaps where red arrows pass straight through: MCP servers, the plug-ins that connect an agent to other tools, and setup steps. The blast radius is what you grant it.

The Copilot cloud agent, Actions-based: a restricted key and a firewall with two known gaps, MCP servers (plug-ins that connect an agent to other tools) and setup steps.

GitHub’s side is less simple than the table suggests. Copilot’s cloud agent can run in three environments, and you choose one when the session starts. You can’t change it afterwards.

  • GitHub Actions-based: an ephemeral environment powered by GitHub Actions. This is the one in the table above. It works in a single repository and supports setup steps, larger runners and self-hosted runners.
  • Cloud sandbox: an isolated Linux environment that GitHub creates for the session, which you don’t create or manage. Where you can choose between this and Actions, GitHub makes the cloud sandbox the default. Sessions can span repositories in one organisation. It follows the same firewall allowlists, but has no custom compute, Actions setup steps or self-hosted runners.
  • Remote: a connection to a custom environment.

The many flavours of GitHub’s agent environments

GitHub doesn’t say whether a cloud sandbox is a VM or a container. For the Actions-based environment, its docs describe each GitHub-hosted runner as a new VM, apart from single-CPU runners.

GitHub: Copilot on GitHub.com, GitHub: About cloud sandboxes and GitHub: GitHub-hosted runners.
Hand-drawn diagram of the three environments GitHub offers for a Copilot cloud agent session, stacked top to bottom. GitHub Actions-based, shaded blue and marked as the one in the table above: an ephemeral environment powered by GitHub Actions, for a single repository, with setup steps, larger runners and self-hosted runners. Cloud sandbox, shaded green: an isolated Linux environment that GitHub creates for the session, where sessions can span repositories in one organisation but there is no custom compute, setup steps or self-hosted runners. Remote, shaded yellow: a connection to a custom environment. A note says you choose the environment when the session starts and can't change it afterwards.

Copilot’s cloud agent can run in three environments. You pick one when the session starts.

The answer to the third question - Whose Identity? - is the big difference.

On your laptop the agent holds your identity. In the cloud it holds a smaller, borrowed one. So the blast radius, how much damage a mistake can do, stops being everything you can do. It becomes the repository, the secrets, and the network you grant that environment.

The keys that the agent holds

Agents may need several different keys to do their task.

Homer Simpson backing in the bushes

Here are the keys the two vendors document, and how each treats them:

KeyClaude Code cloud sessionCopilot cloud agent
GitHub accessStays on Anthropic’s servers; the VM holds only a short-lived credential scoped to the session, and a proxy adds the real oneRestricted credentials: the agent can only perform simple push operations
Environment variablesValues you save on the environment; any command Claude runs can read themAgents secrets and variables, set by a repository administrator and passed to the agent as environment variables, so it can read them
API keys for other servicesNetwork secrets: stored on the environment and added to requests for the hosts you list, so Claude can call the API without seeing the keyAgents secrets, passed as environment variables, so the agent can read them
MCP server credentialsNot covered in the pages I checkedSecrets whose names start with COPILOT_MCP_ are available only to MCP servers, the plug-ins that connect an agent to other tools
Setup stepsNetwork secrets are never attached to setup-script requestsAgents secrets are available to the copilot-setup-steps.yml workflow that prepares the environment
Claude Code: Configure cloud environments, Claude Code: Security, GitHub: Configure secrets and variables for Copilot cloud agent and GitHub: risks and mitigations.

The difference that matters is between using a key and holding it. Claude Code’s network secrets are the only mechanism I found for API keys to other services where the agent can use the key without ever seeing it. Environment variables, on both vendors, are readable by anything the agent runs. Copilot’s cloud agent does not get your GitHub Actions, Codespaces or Dependabot secrets, only the Agents ones.

Hand-drawn diagram of two columns split by whether the agent can read the key. On the left, in red, keys it can read, so they are part of the blast radius: environment variables on both Claude Code and Copilot, and Copilot's Agents secrets, which are passed to the agent as environment variables. On the right, in green, keys Claude Code lets the agent use but not read: the GitHub credential, which never enters the VM, and network secrets, which are added to matching requests after they leave the VM. A note says Copilot's GitHub credential is restricted to simple push operations. Anything the agent can read is inside the blast radius.

Using a key is not the same as holding it.

For the sake of exploring further, let’s take GitHub access/permissions as an example and compare how two different vendors restrict what the agent’s GitHub access can do.

Claude Code cloud sessionCopilot cloud agent
Your GitHub credentials“Never enter a session’s VM”; a proxy makes the GitHub calls insteadRestricted so the agent “can only perform simple push operations”
Where it can pushBranches only, but not limited to one; the proxy rejects branch deletions and tag pushesOne branch
Who can start itAnyone on a plan or role that allows cloud sessionsOnly users with write access to the repository
After it pushesBranch protection rules still decide what it can updateBranch protections and required checks apply; workflows it triggers wait, by default, for a write-access user to approve them
Pull requestsWith Auto-fix on, it keeps working on an open pull request and replies under your GitHub account (more on that below)Draft pull requests only: it cannot mark them ready for review, approve them or merge them

So what we can see here is that the vendor protects the GitHub key by default. Other keys you add to the environment are yours to guard.

What it can reach

Keys are one half of the radius. The network is the other. In 1,200 Agents and a Package Cache: What the OpenAI–Hugging Face Incident Teaches Us the agents were in a sandbox with one filtered exit, and that exit was how they got out. A cloud agent has the same shape.

Jurassic Park - life finds a way

Claude Code lets you choose how open the exit is (Configure cloud environments):

Network levelWhat the VM can reach
NoneNo outbound access through the session’s network; the Anthropic API, the GitHub proxy and MCP connectors still work
Trusted (default)Package registries, GitHub and cloud SDKs
FullUnrestricted outbound access
CustomThe list of destinations you choose, optionally plus the defaults

However, even at None, the docs say that the Anthropic API stays reachable, “which may allow data to exit the VM”.

Copilot’s firewall limits what the agent can reach too, but GitHub is candid about its gaps (Copilot firewall). It only covers processes the agent starts through its Bash tool. It does not cover MCP servers, the plug-ins that connect an agent to other tools, or the setup steps that run before the agent starts.

Anything you save into the environment is part of the radius as well. Claude Code’s environments can hold network secrets that sessions use without seeing, so the agent never reads the key. But the hosts attached to a secret stay reachable whatever the network level, and the secret applies to every session in that environment, so each one you save enlarges the radius.

So I think it is clear from the pattern that a network setting is a starting position, not a guarantee. The wall - allow only the outbound network destinations the agent needs and keep everything else shut - as mentioned in Your Laptop Is the Blast Radius: Running an AI Agent Locally - has gaps, and the vendors’ own docs say so. So it is important to always consider what might still be reachable through the exit.

What it does while you’re away

The third change is absence: nobody is watching while the agent works.

Samuel L Jackson saying What? in Coming to America

A cloud session keeps running after you close your laptop, and you can start several in parallel. Nobody sees the middle. You often just see the result: a branch, a diff and a pull request.

Hand-drawn top-to-bottom flow of a cloud agent run. One: you hand over a task and close your laptop. Two: inside the vendor's cloud the agent works alone and nobody is watching. Three: it pushes a branch and opens a pull request, where branch protections and checks apply. Four, shaded green: you review the pull request, the one place a human looks. Five, shaded red: if Auto-fix is on, replies go out under your GitHub name and can trigger comment-driven automation such as Atlantis, Terraform Cloud or issue_comment workflows.

While you are away, the pull request is the only place a human looks.

Normally the agent stops once it opens a pull request, and nothing more happens until you review it. Claude Code’s Auto-fix removes that pause. With it on, the agent keeps working on the open pull request: it responds to CI failures and review comments, and posts its replies under your GitHub account, labelled as Claude Code.

If your repository runs automation from comments, for certain CI tools, those replies can trigger it before you have looked at anything. The docs warn about exactly that. Auto-fix needs the Claude GitHub App, and you turn it on for one pull request at a time. Replies from the agent can set off that automation, so review it before you turn Auto-fix on.

The quiet guardrails are limits. Cloud sessions stop after a period of inactivity and the VM is reclaimed, and they share rate limits with the rest of your Claude usage. In When an AI Agent Decides the Task Is Impossible I gave two levers for an agent that thinks it is stuck: ask a human, and set limits. With no human there to notice, “ask a human” has nobody to ask, so limits do the work.

So the pull request is your review gate. It’s where I’d catch code that looks like it works but doesn’t.

Before you hand over a repository

Monsters Inc. I'm watching you Wazowski.

In Your Laptop Is the Blast Radius: Running an AI Agent Locally I boiled the fences down to three words: role it (scope its access), time it (keep credentials short-lived) and wall it (limit its network). They apply in the cloud too, but you apply them to the environment rather than your laptop.

FenceAsk before you hand over a repository
Role itWhich repository and branch will it touch, and do branch protections and required checks stop a bad push? Which secrets have I saved in its environment?
Time itDoes its credential die with the session? (Claude Code documents this; I found nothing for Copilot.) How long can a session run, and what happens when it goes quiet?
Wall itWhich network level or allowlist is set? What does the firewall not cover, such as MCP servers and setup steps?

One more question sits outside the fences: how will I review the pull request? That is the one control that works whatever the vendor’s defaults are.

Next

Everything so far assumed a vendor runs the loop and the sandbox. Suppose you run them yourself, on your own Kubernetes cluster. That is the next post in this series.

Sources

Anthropic

GitHub