Coding agent sandboxing does not solve authority isolation

At a glance

What this is: This analysis argues that coding-agent sandboxes contain execution but do not contain authority, so credential scope determines real blast radius.

Why it matters: IAM and security teams need to treat agent permissions, delegation, and just-in-time authorization as the primary control plane, not as an afterthought to container security.

👉 Read PermitIO's analysis of coding agent sandboxing and authority isolation

Context

Coding agent security fails when teams confuse process containment with permission containment. A locked-down container can reduce host compromise, but it does not stop an agent from using valid tokens, browser sessions, or MCP-connected tools to act with broad authority across production systems.

The problem sits squarely in identity governance for non-human identities. If a coding agent can merge to protected branches, publish packages, deploy infrastructure, or read secrets, the question is not where the code runs. The question is which privileges the agent can exercise, for how long, and under whose delegated authority.

Key questions

Q: How should security teams govern coding agents that already have access to production tools?

A: They should govern the agent as a delegated identity, not as a piece of software. That means scoping every token, browser session, and MCP connection to the task, requiring just-in-time grants for high-impact actions, and binding the agent's rights to the human principal's permissions. If the human cannot do the action, the agent should not inherit it.

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 breaks when teams rely on sandboxing to secure coding agents?

A: The assumption that container isolation limits real damage breaks down as soon as the agent holds valid GitHub, cloud, or browser credentials. The sandbox may protect the host, but it does not stop authorized misuse of trusted APIs. Teams end up with a hardened runtime and an overpowered identity.

Q: How do you know if coding-agent authorization is actually working?

A: You should be able to show that every high-impact action was evaluated against policy at runtime, issued with a narrow scope, and recorded with a clear approval path. If the agent can merge, deploy, or access secrets without an invocation-level decision, the authorization model is still standing privilege in disguise.

Technical breakdown

Host isolation vs authority isolation in coding agents

Host isolation constrains what untrusted code can do to the machine. Authority isolation constrains what a process can do through legitimate APIs, sessions, and control planes. A coding agent may be fully boxed in at the OS layer and still hold enough GitHub, cloud, or SaaS authority to merge code, deploy services, or read secrets. That is why sandboxing and authorization answer different security questions. One limits escape from the runtime. The other limits legitimate misuse of granted credentials.

Practical implication: Treat container controls as a containment layer, then enforce separate policy controls on every credentialed tool path.

Why coding-agent credentials create a larger blast radius than the sandbox

The credential surface is broader than a single environment variable. It includes GitHub App tokens, registry publish credentials, cloud API sessions, browser cookies, email access, CI tokens, and MCP server connections. Each one can amplify privilege in a different direction, from source control to production deployment to social engineering. In practice, damaging incidents are more likely to look like authorized misuse than kernel escape because the agent already has legitimate access to high-value systems.

Practical implication: Inventory every token, session, and proxy path an agent can reach, then classify them by business impact rather than by technical convenience.

Risk-tiered authorization for high-impact agent actions

Tool calls are not equal. Read-only operations can often be allowed with logging, while merge, deploy, secret access, and destructive shell actions need stronger checks. A tiered model turns vague policy into operational guardrails by binding each action to resource scope, time bounds, and approval requirements. This is the point where just-in-time access becomes essential: the agent should receive only the minimum authority needed for the current invocation, then lose it automatically when the task ends or changes scope.

Practical implication: Map tools to risk tiers and require invocation-level approval for merge, deploy, secret, and destructive actions.

Threat narrative

Attacker objective: The objective is to turn delegated agent authority into production-impacting actions without needing to break out of the sandbox.

1. Entry occurs when a coding agent is given legitimate access to GitHub tokens, cloud credentials, browser sessions, or MCP-connected tools as part of its working environment.
2. Escalation happens when those credentials authorize actions far beyond the original task, such as pushing to protected branches, reading secrets, publishing packages, or invoking high-power tools.
3. Impact follows when authorized misuse reaches production systems, downstream package consumers, inboxes, or infrastructure control planes, creating business damage without any host compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sandboxing is a host-control story, not an identity-control story. Coding agent hardening has been overread as a solution to authorization risk when it only addresses runtime containment. The authority problem remains if the agent can still act through trusted APIs, sessions, and MCP-connected tools. The implication is that identity teams must judge agent risk by effective privilege, not by container posture.

Credential scope is now the real blast-radius variable for coding agents. GitHub tokens, cloud sessions, browser state, registry credentials, email access, and CI identities each widen the operating envelope in different ways. That is why agent governance belongs in NHI controls, not in an OS hardening checklist. The implication is that privileged pathways need lifecycle control, not just sandboxing.

Zero standing permissions was designed for static secrets and stable review windows. That assumption fails when an agent can acquire and exercise authority dynamically across tools in a single task. The implication is that access review cadences alone cannot describe or govern agent behaviour, because the meaningful control point is the invocation, not the standing entitlement.

Risk-tiered authorization is the right governance pattern because tool calls are not equivalent. Read, write, merge, deploy, secret, and destructive actions carry different identity consequences and deserve different approval thresholds. That framing aligns with OWASP-NHI and zero trust thinking: the control objective is to constrain effective authority, not to treat every call as a generic app action. The implication is that teams should classify agent operations by blast radius, not by interface name.

Authority isolation will become the dividing line between mature and cosmetic agent security. Programs that only harden the runtime will keep producing fragile confidence while leaving delegation chains under-governed. This is where NHI governance, PAM discipline, and agentic workflow controls converge. The implication is that practitioners must redesign policy around delegated authority, not around the illusion that the sandbox is the boundary.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which underlines how weak identity visibility remains.
• For a broader view of how credential governance failures create breach conditions, see 52 NHI Breaches Analysis, which maps recurring control failures across real incidents.

What this signals

Credential visibility, not just runtime hardening, is the control boundary that matters. When agents can inherit browser sessions, cloud credentials, or MCP access, the security programme must track effective authority across every delegation path. Teams that cannot inventory those pathways will not be able to prove least privilege, regardless of how tight the sandbox is.

Zero standing privilege for agents is becoming a policy design question, not a secret-management slogan. The practical challenge is aligning task scope, human entitlement, and invocation-level approval so that authority exists only when the work exists. That is where runtime authorization, auditability, and delegated access governance intersect.

Authority isolation should become the programme term for agent security that goes beyond container controls. It captures the core issue: the agent may be safely trapped inside the runtime and still be dangerously free inside the organisation's control planes.

For practitioners

• Separate containment from authorization Keep container, microVM, and egress controls in place, but require a distinct policy layer for every credentialed tool call an agent can make. Do not assume runtime isolation reduces the need for delegated access governance.
• Inventory the full agent credential surface Map GitHub tokens, cloud sessions, browser cookies, CI identities, registry credentials, email access, and MCP connections to explicit owners and risk tiers. Include any persistent credentials already warm in developer environments.
• Enforce just-in-time grants for high-impact actions Issue short-lived credentials only for the active task and expire them automatically when the task changes, stalls, or completes. Reserve merge, deploy, secret access, and destructive actions for invocation-specific approval.
• Bind delegation to the human principal's rights Ensure the agent can never exceed the permissions of the human delegator. If the human cannot deploy, merge, or publish, the agent should not inherit those rights through environment variables or shared sessions.
• Log the policy decision, not just the action Record principal, agent identity, task, requested operation, resource, policy result, and outcome in one audit trail. That is what makes post-incident attribution and review possible when the agent acts through legitimate access.

Key takeaways

• Coding agent sandboxes reduce host risk, but they do not solve the authorization problem created by valid credentials.
• The main exposure comes from delegated authority across tokens, browser sessions, cloud access, and MCP-connected tools.
• Practical control requires risk-tiered, just-in-time authorization tied to the human principal and the exact invocation.

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.
• Zero Standing Permissions: Zero standing permissions means an identity has no durable privileged access outside the task in progress. For coding agents, authority is issued just in time, scoped to the operation, and revoked automatically, which reduces the blast radius of compromised tokens and prevents long-lived hidden privilege.
• 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.
• Delegated Access: Delegated access is permission exercised by one identity on behalf of another. In coding-agent environments, the agent should inherit only the human principal's allowable rights within the task scope, so the delegation chain cannot exceed the delegator's own authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Coding Agent Sandboxes Don't Solve Credential Authorization. Read the original.