Use case · coding agents

Your coding agent has commit access to your whole life.

Claude Code, Cursor, Codex, Copilot's agent mode, Gemini CLI, Aider, Cline, Continue — they differ in interface and model, and not at all in exposure. Each one reads files, runs commands, installs packages and makes network calls with your account behind it. That is the job. The question is what else comes with it.

Get BitShout See Guard Mode

The actual blast radius

What a coding agent can reach on a normal developer Mac.

Nothing here requires a bug, a jailbreak or a hostile vendor. This is the default state of a process you started, described accurately.

Your whole home directory

Agents are usually launched from a project folder, but nothing confines them to it. `cat ~/.ssh/id_ed25519` is a normal command run by a normal process you started.

Every repository on the machine

Not just the one you are working in. Including the client work, the private fork, and the repo with the credentials someone committed in 2021.

Your git and registry credentials

A credential helper, a `.npmrc` token, a `~/.docker/config.json`. Anything the agent can shell out to, it can read the credentials of.

Arbitrary execution

Shells, interpreters, package managers, build scripts. A `postinstall` hook runs with exactly the authority the agent had.

Your network position

Corporate VPN, internal DNS, a reachable staging database, the printer. Being on your machine means being on your network.

Browser profile data

Session cookies and saved logins live in files. They are files an agent can read.

Why the usual answers do not hold

Four things people say their agent already does.

“It only edits files in the project”: A convention inside the agent, enforced by the agent. One convincing instruction in a dependency README and the convention is a suggestion.
“It asks before running commands”: Until you enable auto-approve, which everyone does by hour three, because approving 200 `ls` calls trains you to click yes.
“It runs in a container”: Often only the editor integration does. The shell tool frequently does not, and the container usually mounts your credentials in anyway.
“I only give it a scoped token”: Better than most. But scope is coarse, tokens are long-lived, and the moment it is read you cannot take it back.

The common thread: every one of them is enforced by the thing being restricted. That is the definition of not being a boundary — see what AI containment actually requires.

The escape everyone forgets

Restrictions that stop at the first process stop at nothing.

This is the specific test to run against whatever you use today: restrict the agent, then ask it to accomplish the same thing via a shell. Containment has to follow the process tree or it is theatre.

One workspace, resolved properly

The project folder, and genuinely nothing else.

~/Projects/appgranted workspace · read + write

src/

node_modules/

keys → ~/.sshsymlink

~/Documentsnot granted

~/.sshcredential store

~/.awscredential store

~/Library/Application Support/…browser profiles

/Volumes/NASnetwork mount

Resolution, not comparison

requested~/Projects/app/keys/id_ed25519
expanded/Users/you/Projects/app/keys/id_ed25519
symlinks resolved/Users/you/.ssh/id_ed25519
device / inodedev(1,17) : 8814402
verdictoutside grant → deny

Prefix matching on the requested string would have allowed this. BitShout matches on the resolved object, so the link leads nowhere.

What it recognises

By signature, not by name.

BitShout has no list of supported agents. A protected subject is a fingerprint over code-signing identity, Team ID, bundle identifier and executable identity, so an agent released next month is governed by the same rule as one released last year — and renaming a binary changes nothing.

One distinction is worth stating plainly, because it changes what containment means in practice:

Standalone processes: Claude Code, Codex CLI, Gemini CLI, Aider and similar tools run as their own signed processes. Each is contained as its own subject, with its own workspace, network rules and capabilities.
In-editor extensions: Copilot inside VS Code, and extensions like it, run inside the editor's own process tree rather than as separately signed programs. Containing them means containing the editor — which is real containment and often the more useful boundary, but it is the editor's authority you are scoping, not the extension's. We would rather say that than imply a precision we do not have.

FAQ

Coding agent security, answered

Is Claude Code, Cursor or Codex safe to run on my main machine?

They are legitimate, well-built tools, and none of them is malicious. The risk is not the vendor — it is that any coding agent necessarily has broad capability (read files, run commands, reach the network) and inherits your full account authority to exercise it. The exposure is the same whichever agent you choose, because it comes from the operating system’s permission model rather than from the agent.

Do coding agents run in a sandbox already?

Partially and inconsistently. Some agents sandbox their editor integration but not their shell tool. Some offer a container mode that then mounts your SSH keys and git credentials into the container, which returns most of the exposure. And almost none of them scope descendants, so a spawned shell escapes whatever the parent had. Check what happens on your setup when the agent runs `bash -c` — the answer is often "everything".

What is the single highest-risk thing a coding agent can do?

Read a long-lived credential and put it somewhere it persists — a log, a commit, a request body, a context window. Everything else is recoverable: a deleted file comes back from backup, a bad commit gets reverted. A leaked key keeps working until someone notices and rotates it, and nothing in the normal workflow makes anyone notice.

How do I stop an agent from reading ~/.ssh or ~/.aws?

Not with file permissions — the agent runs as you, so it has exactly the same rights to those files as you do. You need an authority boundary outside the process. BitShout denies those paths by default for contained subjects, resolves the real object rather than comparing path strings (so a symlink placed inside the granted workspace does not work either), and applies the same policy to every descendant process.

Will containment break my agent workflow?

It changes it in one way: the first time the agent reaches for something outside its workspace, you get asked instead of it silently succeeding. In Guard Mode the agent runs natively at full speed with no VM, and grants can be scoped to a session or a duration so you are not answering the same question repeatedly. The friction is concentrated at setup, which is where you want it.

Does this work with agents that use MCP servers?

Yes, and that is where a lot of the real authority lives. MCP servers are registered by exact identity and their tools are individually approved; a tool the server advertises is not a tool the agent may call. Credential-backed operations are brokered so the agent receives a result rather than the token. See MCP security for the detail.