Your Coding Agent Has More Access Than You Think. Here's the Audit.

#ai #agents #security #programming

DEV.to has a trend right now called "sandboxing your AI coding agent." Nineteen posts in a week. New accounts, template titles, and one of them openly admits it's vendor outreach. It's noise — but the signal under it is real: developers are realizing their coding agent has actual power over their machine, and they don't know where it ends.

I can tell you where it ends, because the answer is public. And it's not where most people think.

Do you know what your agent can actually touch — read, write, run, and phone home?

That's the question this post answers. Not with vibes, not with a sales pitch, and not with "just trust it." With the real permission defaults, the real failure receipts, and a five-check audit you can run in an afternoon.

Your agent is more powerful than you think

Coding agents ship with the same three powers that make security people nervous: a shell, file write access, and network access. The difference between tools isn't whether they have those powers — it's what they do before using them.

Take the two agents most people are actually using right now.

OpenCode defaults to allow. From their own docs: "If you don't specify anything, OpenCode starts from permissive defaults — most permissions default to allow." The only two things that prompt you by default are accesses outside your working directory and repeated tool calls. .env files are denied — the one hard rule baked in. Everything else, including a full bash shell, runs without asking.

And here's the part almost nobody knows: OpenCode has no sandbox. It's their own words.

"OpenCode does not sandbox the agent. The permission system exists as a UX feature… it is not designed to provide security isolation. If you need true isolation, run OpenCode inside a Docker container or VM."

That's from their SECURITY.md. The permission prompt is a convenience, not a cage.

Claude Code is the cautious one — relatively. Bash commands ask before running, except a fixed read-only subset (cat, grep, pwd, diff, read-only git…). Permission rules are evaluated deny → ask → allow. It has a real sandboxed Bash tool (bubblewrap on Linux, Seatbelt on macOS) that isolates filesystem and network. Anthropic claims it cuts permission prompts by 84% internally.

But even "cautious" means: shell access, write access, network access — all present, all gated by prompts you habitually click through.

This gap between "the tool asks me sometimes" and "the tool is actually contained" is exactly what OWASP calls excessive agency — the #1 blind spot in agent security.

Developers already sense it. In the 2025 Stack Overflow survey, 81% of developers said they're concerned about AI security — yet 52% either don't use agents or stick to simple ones, and 38% have no adoption plan. Concern is high, verification is rare. That gap is this post.

Where it breaks: the receipts

This isn't hypothetical. Every major agent has a patched CVE or a user-reported incident on the same handful of failure modes.

Prompt injection turns approved commands into remote code execution. Trail of Bits showed argument injection against pre-approved commands achieving one-shot RCE on popular agents. Academic research measured up to 84% command-execution success against Cursor and Copilot with prompt injection.

Repo files execute code before you approve anything. This is the scariest cluster, because it happens before the trust dialog:

CVE-2025-65099 — a malicious Yarn config in a project ran code before Claude Code's trust prompt.
CVE-2026-21852 — a repo's ANTHROPIC_BASE_URL redirected API traffic and siphoned the API key before the trust prompt. CVSS 7.5.
CVE-2026-33068 — a repo silently set permissions.defaultMode: bypassPermissions and skipped the trust dialog entirely. CVSS 8.8.
CVE-2025-54795 — command injection via echo parsing let a prompt-injected agent run arbitrary commands. CVSS 9.8.

"Secure" modes leak. A bypassPermissions rule, a misread glob, a model-generated path, and the boundary is gone: Cursor's allowlist bypass, and Codex's sandbox bypass where the model-controlled working directory became the writable root.

And the user-reported incidents read like a horror list:

An agent deleted a user's main GitHub repository after misreading a rename command. Restored via GitHub's 90-day window.
rm -rf src wiped a Vue project in standard, non-auto mode.
An agent launched in an empty directory wrote 40+ files into a sibling repo without saying anything.
Cursor read and echoed .env credentials despite a .cursorignore file.

The pattern across all of them: the boundary held until it didn't, and nothing noticed until after the damage. That's why the audit below exists.

The audit: five checks, one afternoon

No security degree required. Run these once now, and re-run after every agent or tool update — because each update can silently change the defaults.

Check 1 — Read your permission config

Find out exactly what runs without asking. In Claude Code, run /permissions and inspect settings.json — the deny → ask → allow order means a single ask rule can silently upgrade. In OpenCode, review the permission block in your config and your agent files. You're hunting for three things: blanket rules like Bash(*), any auto or bypass mode, and network tools (webfetch, websearch, curl). Ask yourself: is there a single command here I would never want auto-approved? If yes, that rule gets a deny.

Check 2 — Plant canaries

A canary is a decoy your agent has no legitimate reason to touch. Drop a fake credential into a file (sk-test-DONOTREAD-…), a bait .env, or a tripwire file outside the workspace. Check after your sessions: if the canary moved, got read, or shows up in agent logs — the boundary leaked. Canary tokens turn this into an alert. The read is invisible to you otherwise: file reads leave no trace, which is exactly why a canary is the right tool.

Check 3 — Test egress

Can the agent reach the network? Blocked HTTP with open DNS is still an exfiltration pipe. Two probes: request the cloud metadata endpoint 169.254.169.254 (it should fail), and check whether your DNS resolver logs hits on a hostname only the agent could have looked up. If you care about this, default-deny the network with a proxy or firewall rules — don't assume the agent's "network access" setting means anything on your machine.

Check 4 — Verify the sandbox is real

If you rely on a sandbox, confirm it's enforced, not just configured. A container with --privileged, --cap-add=SYS_ADMIN, seccomp=unconfined, or a mounted docker.sock is not a sandbox — it's a room with the door off. Check with docker inspect, look at /proc/self/attr/current for AppArmor, and probe a blocked syscall. Tools like cagecheck automate this. And remember the OpenCode case: if your tool has no sandbox, the only honest isolation is a container or VM.

Check 5 — Make read-only real

Plan mode and read-only agents are prompt-based, not enforced — a misbehaving model can still write. If you want a hard guarantee, enforce it structurally: a PreToolUse hook that returns deny for edit/write tools outside approved modes, or run exploration agents against a read-only mount. Enforce with a hook, don't hope with a prompt.

Where trust really breaks

The audit catches what's misconfigured. But there's a deeper failure that no checklist fixes — and it's the one the trend posts never mention:

Permission rules are enforced by the tool, not by the model.

An allow rule is a contract the tool will honor. The model, on the other hand, is a probabilistic text-completer that can be prompt-injected, can misread a path, or can interpret "clean up" as "delete everything in src." The load doesn't guarantee the obey. Every incident above is a loaded rule that wasn't obeyed — which is exactly why a session log matters (I wrote the system for that), and why I keep saying migration is a re-declaration, not a file copy (the diary version).

The practical consequence: boundaries are a systems-design problem, not a model-politeness problem. Your agent's cage is your config, your hooks, and your harness — not the model's mood. That's the framework behind the whole AGENTS.md approach I write about.

The verdict

You don't need to fear your coding agent. You do need to audit it — because the defaults are wider than you think, the failures are documented and recurring, and nobody else is going to check for you.

Five checks. One afternoon. Re-run on every tool update.

Read your permission config. Plant canaries. Test egress. Verify the sandbox. Enforce read-only.

Then ask yourself the question from the top of this post, and actually know the answer: what can my agent read, write, run, and phone home?

The "sandbox your agent" trend is full of posts from accounts that were created last week. The signal under the noise is real, and it's this: nobody's checking what their agent can touch. This is the check.

What's the one thing you'd never want your agent to touch — and have you tested whether it can?

The weird part of the boundary story is that your own rules file is the biggest boundary you already control. Start there: Why Your Coding Agent Keeps Making the Same Mistakes — AGENTS.md Fixes It.

I write about AI engineering stacks, autonomous developer tools, and structural agent design. If you're building in this space, follow @buildloops for weekly breakdowns!