Notifications
Clear all
Topic starter
23/06/2026 7:23 pm
TL;DR: Container hardening and VM isolation reduce host-compromise risk for coding agents, but they do not limit what an agent can do with valid GitHub, cloud, browser, or MCP credentials, according to PermitIO. The real control gap is authority isolation, not runtime containment, because the blast radius is defined by delegated privileges, not by the sandbox.
NHIMG editorial — based on content published by PermitIO: Coding Agent Sandboxes Don't Solve Credential Authorization
Questions worth separating out
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.
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 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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
PermitIO's full blog post covers the operational detail this post intentionally leaves for the source:
- The proposed risk-tier matrix for classifying tool calls by impact, from read-only actions to secret access and destructive operations.
- The example runtime authorization record that binds human principal, agent session, task scope, and policy decision into one audit trail.
- The delegated-access pattern showing how JIT grants can be issued, timed out, and revoked mid-task without leaving standing privilege behind.
- The discussion of MCP server access as a capability amplifier, including why proxy paths expand the agent's effective authority.
👉 Read PermitIO's analysis of coding agent sandboxing and authority isolation →
Coding agent credentials: why sandboxing is not enough?
Explore further
25/06/2026 3:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Coding agent sandboxing does not solve authority isolation
