Where your agent runs decides what can contain it
Two real incidents this year show why the 'is it sandboxed' question misses the point, and why authority, not isolation, is where agents actually get burned.
A researcher opened a pull request. In the title, where you would normally write a description, they typed an instruction instead. Then they watched an AI code-review bot read that title, do what it said, and post its own API key into the thread as a comment.
The same class of trick worked on three different tools: Claude Code’s review action, Google’s Gemini CLI action, and GitHub’s Copilot agent, each hijacked through its own variant, a PR title, an issue comment, a hidden HTML comment. Three agents. Three leaked keys, walked out through nothing fancier than a comment box. The researchers, working with Johns Hopkins, called it Comment and Control (disclosure).
The detail that should keep you up: Anthropic’s own system card had already said that review tool was “not hardened against prompt injection.” The weakness was written down before the tool shipped. Nobody was surprised when it broke. It broke anyway.
TL;DR
We keep asking the wrong question about agent security. The popular question is “is it sandboxed?” The question that actually predicts whether you get burned is “what is this thing allowed to do?” Those are two separate axes, and where you run your agent sets where both of them start. This post is about telling them apart: the easy axis is worth pushing, but it’s the dangerous one that decides how bad a bad day gets.
Two axes, not one
Every running agent sits on two independent axes.
The first is isolation: if the agent runs malicious code, can that code escape and touch the rest of your machine? This is the sandbox question. Containers, microVMs, a locked-down user account. It governs the blast radius of execution.
The second is authority: what is the agent legitimately allowed to reach? Which credentials it can read, which files it can open, which network endpoints it can call, which tools it can invoke. It governs the blast radius of permitted action.
Almost the entire market conversation is about the first axis. It is the one with products attached. You can buy isolation, demo it, put it on a slide. AWS’s Bedrock AgentCore, for one, gives each agent session its own microVM and sanitizes the memory when the session ends (per AWS’s own docs). That is real, and it is good, and you should use it.
Now look back at the pull request. No code escaped any box. The agent did not break out of a sandbox. It used its own legitimate credential, over its own legitimate network connection, to do a thing it was fully permitted to do. The sandbox had nothing to grab onto, because nothing escaped. The key left through the front door, holding a visitor’s badge the agent had handed it.
That was not an isolation failure. It was an authority failure. And isolation, no matter how good, does not move the second axis even one notch.
The easy axis and the hard one
Isolation is the easy axis because it has a shape. There is a box. You make the walls thicker: container, then user-space kernel, then hardware-virtualized microVM, then a managed runtime that throws the whole thing away after every session. You can measure it. You can sell it. You can finish it.
Authority is the hard axis because there is no box to build. The danger is not code breaking out. The danger is the agent staying perfectly inside its permissions and using them against you. A credential the agent can read is a credential an attacker can exfiltrate the moment an injection lands. And injections land. We are not going to prompt-engineer our way out of that. The models get better and the attacks get better with them, direct, indirect, through a web page, through a repo, through a PR title.
Here is the same failure in a quieter form. Earlier this year Check Point showed that a malicious repository could ship a config file pointing Claude Code’s API base URL at an attacker’s server. Open the folder, and Claude Code fired off a request carrying the full authorization header before the trust prompt ever appeared (CVE-2026-21852, since patched). Your key was gone before you clicked anything. No sandbox stops that, because making an API call is the one thing the tool exists to do. The credential simply went somewhere new.
Isolation would not have saved you in either story. The authority axis was the whole game, and nobody was holding it.
Where you run it sets your starting point
This is why deployment topology matters, and why it is not just an infrastructure decision. Where you run an agent fixes where both axes start before you have configured anything.
Local CLI on your machine — you get about no isolation, your host, your shell. Authority you still owe: everything you can touch, your keys, your files, your cloud. Most exposed, most common.
Ephemeral sandbox / managed runtime — isolation you get for free: strong, own kernel, wiped after use. Authority you still owe: still whatever credentials and network egress you handed the session.
Agent in CI/CD — isolation you get for free: weak-to-medium runner isolation. Authority you still owe: the pipeline’s cloud credentials, usually the crown jewels.
Multi-agent setup — isolation you get for free: varies per agent. Authority you still owe: multiplied, plus new trust between agents that nobody is checking.
Read those the same way each time and the point falls out. The isolation half is what the topology gives you on day one. The authority half is what you have to build yourself, every single time, no matter how good the box is.
And notice the most common case. The local agent on your own laptop, the one most of us run every day, starts with almost zero isolation and total authority. It has your shell, your keys, your everything. To anyone watching from the credential’s point of view, that agent is an insider with full access and an attacker whispering in its ear. We have been pointing all our sandbox energy at the cloud while the riskiest deployment is the terminal already open in front of us.
The question to actually ask
So replace the question. Not “is it sandboxed.” Ask instead: if this agent does exactly what it is allowed to do, while someone else is feeding it instructions, how bad is that?
That breaks into four plain checks:
Access. What can it read, and can the secret it holds reach a place it should never reach?
Egress. Which network destinations can it talk to? An agent that can only reach two allowlisted hosts cannot mail your secrets to a third.
Tools. What can it call, and is the default “no”? Permission should be granted per action, not assumed.
Approval. Who signs off on the high-impact step, and is that gate enforced in code? If the model can talk itself out of asking for review, it will.
None of those is a sandbox setting. All of them are authority settings. That is the gap.
Close
Isolation keeps the code inside the box. Authority decides how much the box is worth robbing. We have spent years thickening the walls and almost no time asking what we left sitting on the table inside.
The agent is going to get tricked. Call it the design assumption, not pessimism. The work is not making it un-trickable. The work is making sure that when it gets tricked, and it will, there is very little it is actually allowed to do about it. Stop measuring the thickness of the walls. Start measuring the blast radius of the badge.