Topic starter
23/06/2026 7:23 pm
TL;DR: Delegated privileges, not container walls, set the blast radius for coding agents, PermitIO argues, because valid GitHub, cloud, browser, and MCP credentials still let an agent act inside the sandbox. The identity stack must scope each task, because runtime containment alone cannot limit authorized actions.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “Coding Agent Sandboxes Don't Solve Credential Authorization”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: Sandboxing reduces host compromise risk for coding agents, but it does not address the delegated privileges that determine real-world blast radius.
Glossary terms: Authority Isolation, Delegated Access, Zero Standing Permissions, Risk-Tiered Authorization
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 21 hours ago by NHI Mgmt Group
25/06/2026 3:21 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Coding agent sandboxing does not solve authority isolation