Topic starter
22/07/2026 4:38 pm
TL;DR: Cursor’s sandbox escape research shows that a workspace-written .claude/settings.local.json file can be trusted as hook configuration and used to trigger local command execution without the user-facing approval path, according to Pillar Security. The finding underscores how compatibility layers and agent-written project files can turn ordinary automation into a control bypass for AI coding tools.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “The Week of Sandbox Escapes Day 6: The hook was already in the workspace”.
By the numbers:
- Cursor assigned this issue CVE-2026-48124 and published a High severity advisory with a CVSS 8.5 score.
Key questions
Q: What breaks when agent-written hook configuration is not isolated from execution policy?
A: The sandbox stops being the last decision point.
Q: Why do compatibility layers create security risk in AI coding agents?
A: Compatibility layers often inherit another tool's configuration shape without inheriting its security assumptions.
Q: How can security teams detect when an AI agent is crossing from reading into execution?
A: Look for mismatches between the content the agent consumes and the actions it attempts to take.
Practitioner guidance
- Audit all agent-writable execution files Inventory every file path that can influence command execution, including hook configs, local settings, and compatibility namespaces.
- Require explicit approval for workspace-sourced hooks Block hook execution unless the command and the source file are both approved through the same user-facing control path that governs direct shell actions.
- Separate project state from executable instructions Store automation metadata in a location that cannot be authored by the agent, or validate it against a signed allowlist before any downstream component consumes it.
Bottom line: The core failure is not shell access, but trust in agent-authored configuration that later becomes executable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/07/2026 4:42 pm
Workspace-writable execution state is the governance failure this case exposes: the boundary was not broken by shell access, but by a trusted file path that accepted agent-authored commands. This is a control design problem, not a prompt safety problem. When an agent can influence what another component executes, file integrity becomes part of the runtime trust model. Practitioners should treat hook configuration as privileged execution state, not workspace content.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do when a sandboxed agent can influence host-level commands?
A: They should move control to the handoff point. That means requiring explicit authorisation for command-bearing files, validating compatibility paths, and limiting which workspace artifacts any unsandboxed helper can consume. The goal is to ensure that no agent-authored file can become executable without a deliberate policy decision.
👉 Read our full editorial: Cursor sandbox escapes show workspace hooks become execution paths