Topic starter
28/07/2026 6:15 pm
TL;DR: Unosecur's analysis of Claude Cowork's SharedRoot case finds host credentials and files were already within the agent's practical blast radius. Teams need to treat runtime privilege as a measurable control, not assume isolation alone contains the damage.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “SharedRoot: What a Sandbox Escape in Claude Cowork Says About Identity, Not Just Isolation”.
Key questions
Q: Why do sandboxed AI agents create more risk when they inherit human-level access?
A: Because the governance assumption behind human access review is that a person's reach is easier to understand, limit, and certify.
Q: How can security teams tell whether an agent's permissions are too broad?
A: A simple test is whether the agent can access anything unrelated to its immediate task, especially credentials, repositories, or cloud resources outside the folder or workflow it needs.
Q: What breaks when an AI agent has sandboxed execution but still inherits host credentials?
A: The control model breaks because isolation and identity scope are not the same thing.
Practitioner guidance
- Map each agent's reachable blast radius Inventory the folders, repositories, cloud accounts, and internal tools each agent can reach today, then compare that to the smallest task scope actually needed.
- Remove standing host-level exposure Reduce broad filesystem sharing, mounted paths, and inherited host access so a sandboxed agent cannot reach unrelated credentials if isolation fails.
- Tie agent access to observed use Compare granted agent permissions with last month's actual tool and resource usage, then shrink anything the agent never touched.
Bottom line: SharedRoot demonstrates that AI agent security is not only about sandbox hardening but also about how much trust the agent inherited before the failure.
Glossary terms: Sandbox Escape, Identity Blast Radius, Agentic Access, Ambient Privilege
What's in the full article
Unosecur's full analysis covers the operational detail this post intentionally leaves for the source:
- The specific SharedRoot chain and how the Linux kernel bug combined with guest configuration choices
- The MCP Gateway control model for binding AI client actions to a real human identity
- The access analyzer, DLP, and tool-monitoring functions described in the article
- The distinction between kernel patching and identity scoping as separate layers of defence
👉 Read Unosecur's analysis of SharedRoot and AI agent identity blast radius →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
30/07/2026 10:53 pm
AI agent blast radius is an identity design problem, not just a containment problem: SharedRoot shows that a sandbox can fail after the access model has already overreached. The agent's practical reach was broad enough that a single escape exposed credentials and host resources. That means containment and identity scoping have to be designed together, not treated as separate layers. Practitioners should evaluate agent access as a blast radius question before they evaluate it as an isolation question.
A question worth separating out:
Q: When should organisations treat AI agent containment as an IAM problem?
A: Treat it as an IAM problem whenever the agent can read secrets, write to trusted workflow paths, or invoke tools without direct human approval. At that point, the harness is making authorisation decisions on behalf of the organisation, so access scope, delegated authority, and offboarding matter as much as they do for service accounts and privileged users.
👉 Read our full editorial: SharedRoot shows why AI agent identity is the real blast radius