Coding agent sandboxing does not solve authority isolation

At a glance

What this is: This is an analysis of why coding-agent sandboxes do not solve the larger problem of authority isolation when the agent still holds high-scope credentials.

Why it matters: It matters because IAM and platform teams must govern what a coding agent can do through trusted APIs and sessions, not just what it can execute inside a container.

Context

Coding agents often look safer once they run inside containers, microVMs, or other locked-down runtimes. That framing focuses on host compromise, but the operational risk usually comes from the privileges already attached to the agent through GitHub tokens, cloud credentials, browser sessions, CI identities, and MCP tools.

Authority isolation is the missing control plane. If a coding agent can still merge to protected branches, deploy infrastructure, read secrets, or publish packages, sandboxing only narrows one attack path while leaving the delegated authority problem intact. For IAM and NHI teams, the governance question is who or what can act through those credentials, not where the code runs.

Key questions

Q: How should security teams secure coding agents beyond sandboxing?

A: They should treat coding agents as delegated principals and govern what they can do through tokens, sessions, and tools, not only where the code runs. Sandboxing reduces host risk, but it does not reduce the authority carried by GitHub, cloud, browser, CI, or MCP credentials. The control objective is authority isolation plus runtime containment.

Q: Why do coding agents create more risk than ordinary automation when credentials are involved?

A: Because coding agents can combine legitimate credentials with runtime decisions and high-speed tool use. A script runs a fixed path, but an agent can choose among tools, chain actions, and exploit broad authority if the surrounding identity model is weak. That makes delegated access and privilege scope the main control problem.

Q: What are the signs that a coding agent is overprivileged?

A: A coding agent is overprivileged when it can reach high-impact actions that are not required for the task, such as protected branch merges, production deploys, inbox access, package publishing, or secret reads. Another warning sign is when the same credentials persist across tasks instead of being issued and revoked per operation.

Q: What should teams do when a coding agent needs MCP or cloud access?

A: Teams should bind each tool to a specific policy tier, task scope, and time window, then approve only the operations that are necessary for that session. High-risk calls such as deploy, secret access, or destructive actions should require explicit invocation-level approval and leave a clear audit trail.

Technical breakdown

Host isolation vs authority isolation

Host isolation contains execution on the machine. It relies on controls such as containers, seccomp, read-only mounts, and network restrictions to reduce the impact of a compromised process. Authority isolation is different. It governs what the same process can do through legitimate tokens, sessions, and trusted APIs. A coding agent does not need kernel-level escape if it already has rights to merge code, deploy infrastructure, or read secrets. The key design error is treating runtime containment as if it were authorization control. They solve different problems and fail in different ways.

Practical implication: separate runtime hardening from delegated authorization and review both before trusting a coding agent.

Why coding agent credentials create privileged execution paths

A coding agent inherits authority through many channels, not just explicit environment variables. GitHub App tokens, cloud CLI sessions, browser cookies, OAuth grants, CI tokens, package registry credentials, and MCP tool access all expand what the agent can reach. That makes the effective credential surface much larger than the runtime image suggests. The article’s core point is that legitimate access paths are the main failure mode, because an agent with valid credentials can cause real damage without any exploit against the host. In practice, the dangerous path is authorised misuse, not sandbox breakout.

Practical implication: inventory every live credential path a coding agent can touch, including browser-backed and MCP-mediated access.

Risk-tiered authorization for agent tool calls

Not every tool call carries the same business impact. Read-only calls, file edits, branch pushes, merges, deployments, secret reads, and destructive shell actions represent very different risk levels and should not share one permission model. A useful authorisation scheme grades actions by side effect, reversibility, and blast radius. That is why the article distinguishes low-risk observation from high-risk authority such as production deployment or secret access. Fine-grained authorization is not extra ceremony. It is the only way to keep agent workflows usable while avoiding blanket trust for irreversible operations.

Practical implication: assign distinct policy tiers to read, write, merge, deploy, and secret-bearing actions instead of using one broad approval rule.

Threat narrative

Attacker objective: The attacker seeks to abuse legitimate agent authority to reach production systems, secrets, or distribution channels.

1. Entry begins with a coding agent being granted legitimate access through GitHub tokens, cloud sessions, browser state, or MCP tools rather than through a host compromise.
2. Escalation occurs when the same agent uses that authority to push to protected branches, deploy infrastructure, read inboxes, publish packages, or access secrets beyond the original task scope.
3. Impact follows when authorized misuse turns into production changes, package publication, secret exposure, or broader operational disruption without any sandbox escape.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authority isolation is the real security boundary for coding agents. Container and VM hardening address host compromise, but they do not constrain what a delegated agent can do through valid credentials. That means the blast radius is set by authorisation scope, not by runtime containment. Practitioners should stop treating sandboxing as a proxy for access governance.

Legitimate credentials are the dominant failure path. Coding agents increasingly inherit effective authority through GitHub tokens, cloud sessions, browser cookies, CI identities, and MCP connections. Those channels bypass the intuition that the agent only has the permissions explicitly typed into a prompt or env file. The governance problem is therefore broader than secret storage and closer to delegated privilege control.

Zero standing permissions is the right baseline, but only if the delegation chain is explicit. A coding agent should not start with durable access and should only receive task-scoped rights that intersect with the human principal’s own permissions. That model turns agent security from static trust into contextual authorisation. Teams that cannot express the delegation chain clearly will not be able to explain agent actions after an incident.

Named concept: authority isolation gap. This article sharpens the control failure where teams harden the execution environment but leave the agent free to act through trusted APIs and sessions. The gap is not the container itself; it is the mismatch between containment and delegated privilege. Practitioners should treat that mismatch as the primary design flaw in current coding-agent programmes.

Risk-tiered tool governance is becoming the practical operating model. Read paths, write paths, merge and deploy paths, and secret-access paths need different approval thresholds and different evidence trails. That is not a product preference. It reflects the reality that one high-scope call can outweigh hundreds of low-risk observations. Security teams should align their policies to the side effect of the action, not the fact that an LLM selected the tool.

What this signals

Authority isolation gap: The most important control question is no longer whether the agent can escape its sandbox, but whether it can exercise broad authority through trusted credentials and sessions. That shifts programme design toward delegated access governance, per-tool policy, and task-scoped grants.

Coding-agent programmes need to be judged by the authority they expose, not by the hardness of the container they run in. If the agent can still act as a publisher, deployer, or mailbox reader, runtime containment has not materially reduced blast radius.

For practitioners

• Map the full credential surface Inventory every path a coding agent can use, including GitHub scopes, cloud sessions, browser cookies, CI identities, package publish tokens, and MCP tools. Treat implicit sessions as first-class authority.
• Remove standing authority Replace durable agent secrets with just-in-time grants that expire at the end of the task and inherit only the human principal’s applicable permissions.
• Tier tool permissions by side effect Separate read-only, edit, merge, deploy, and secret-access actions into distinct policy levels so high-impact operations require explicit approval.
• Gate MCP tools as privileged capabilities Treat each MCP connection as an authority multiplier and apply per-tool authorization before the agent can reach downstream systems.
• Log the delegation chain Record the human principal, agent session, target resource, requested action, and policy decision in one audit trail so authorization can be reconstructed later.

Key takeaways

• Sandboxing reduces host compromise risk for coding agents, but it does not address the delegated privileges that determine real-world blast radius.
• The practical failure mode is authorised misuse through GitHub, cloud, browser, CI, and MCP credentials that remain valid inside the sandbox.
• Effective control depends on task-scoped authority, just-in-time access, and policy tiers that separate read, write, deploy, and secret-bearing actions.

Key terms

• Authority Isolation: Authority isolation is the practice of separating what a process can do at runtime from where it runs. For coding agents, it means valid credentials, sessions, and delegated permissions are governed independently of container or VM containment, because sandboxing alone cannot stop authorised misuse.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Zero Standing Permissions: Zero standing permissions means an actor holds no durable broad privileges between tasks. Access is issued only when needed, scoped tightly to the action, and removed or contracted when the task ends or the context changes. For agents, this is a behavioural control as much as an access model.
• Risk-Tiered Authorization: Risk-tiered authorization classifies tool calls by business impact and applies different approval thresholds to each class. In agentic workflows, read-only actions can be lightweight, while merge, deploy, secret access, and destructive actions require stricter, invocation-specific controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.