Coding Agent Sandboxes Don't Solve Credential Authorization

Sign in

Loading

Loading

Home/Blog/Coding Agent Sandboxes Don't Solve Credential Authorization

Loading

Get Started<br>Test in minutes,go to prod in days.<br>Get Started Now

Join our Community<br>2938 Members

Get support from our experts, Learn from fellow devs<br>Join Permit's Slack

Table of Contents<br>A lot of teams are having the same uncomfortable conversation right now: we moved our coding agent into a locked-down container, so why does security still feel fragile? The answer is that container hardening and VM isolation solve one class of problem—the host compromise problem—but not the authority problem. If your agent can still push to protected branches, publish packages, deploy infra, read inboxes, or call high-power MCP tools, the blast radius is defined by those privileges, not by namespace isolation.

That's the architectural tension behind secure coding agents today. We're very good at talking about runtime boundaries, but still too casual about coding-agent credentials. You can run Claude Code security controls perfectly at the OS layer and still hand the agent effective admin authority through GitHub tokens, cloud credentials, and browser-backed sessions. That gap is where most serious failures will happen.

Host isolation vs authority isolation

Host isolation and authority isolation are different security properties that happen to get discussed as if they were one. Host isolation is about containing code execution: containers, microVMs, seccomp profiles, egress controls, read-only mounts, and process-level guardrails. It answers, "if this process is malicious, how far can it move on this machine?"

Authority isolation answers a different question: "what can this process do through legitimate APIs and trusted control planes?" An agent doesn't need a kernel escape if it already has a token that can merge to main, trigger production deploy, or read secrets from a vault. In practice, most damaging incidents won't look like classic host compromise—they'll look like authorized misuse.

This is the industry mistake worth naming in plain language: coding-agent sandboxing is necessary, but it addresses a different security dimension than coding agent authorization. You can be perfect on one axis and dangerously weak on the other. A fully isolated agent with a high-scope GitHub PAT and cloud CLI creds is still a high-authority operator.

The real credential surface of a coding agent

Most teams underestimate the credential surface because they reason only about what they explicitly passed to the agent in environment variables. But modern coding workflows leak authority through many side channels: local CLIs already authenticated, browser sessions already warm, CI tokens in repo secrets, and MCP servers that proxy additional capabilities. Least privilege for coding agents has to model all of that, not just .env.

The discussion around Claude Code security has already surfaced this reality in public practitioner forums. The Claude Fable Hacker News thread has multiple engineers explicitly calling out Gmail access, password-reset abuse, browser-profile exposure, and .env/MCP pathways as the real concern—not merely "can it delete local files." That framing is directionally correct: the dangerous path is often credential reuse, not sandbox breakout.

The credential inventory that matters in practice looks like this:

GitHub App tokens and PATs : Scope is everything. repo:read and metadata are very different from contents:write, pull_requests:write, or org-admin permissions. GitHub agent permissions should be task-scoped and repo-bounded by default.

Package registry credentials (npm, PyPI, crates.io, etc.) : This is distribution-plane risk. A compromised publish token can ship malicious artifacts to downstream consumers even if source control remains clean.

Cloud CLI/API credentials (AWS, GCP, Azure) : Access keys, service-account credentials, federated sessions, and managed identities all become infrastructure authority when reachable by an agent runtime.

Email/SMTP/Gmail credentials : Email authority is meta-authority. It enables phishing, workflow impersonation, and password-reset interception across unrelated systems.

Browser session cookies and OAuth tokens : Active browser sessions can bypass fresh MFA prompts and effectively hand over already-authenticated state.

CI/CD tokens and pipeline identities : These are operational credentials: run builds, inject artifacts, modify release flow, and deploy.

MCP server connections : MCP server security is now core, not optional. MCP tools can amplify authority by proxying to systems the agent otherwise couldn't reach.

SaaS API keys (Jira, Slack, Notion, etc.) : These create organization-wide side effects—ticket churn, notification abuse, data exposure, and social engineering opportunities.

The risk is not theoretical. Obsidian Security's LiteLLM privilege escalation research demonstrates a path from...