Sandbox escapes in AI coding agents expose Git trust gaps

At a glance

What this is: This is a research post showing how an AI coding agent escaped a sandbox by exploiting Git directory indirection and auto-triggered helper execution.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly depend on workspace trust boundaries that can be bypassed when agents create files later treated as executable input.

👉 Read Pillar Security's analysis of sandbox escapes in AI coding agents

Context

AI coding agents are changing the trust model around developer workspaces because they can now write the files that tools later interpret as authority. In this case, the primary security problem is not just a sandbox boundary, but the handoff between sandboxed file creation and unsandboxed automation that consumes repository state.

Git metadata is especially sensitive because local configuration can control hooks, filters, and helper programs. For identity and access practitioners, that creates a subtle NHI-style governance issue: an agent may not be a human user, but it can still shape machine-readable trust inputs that cause privileged execution later. That is atypical for traditional developer tooling, but increasingly plausible in agentic workflows.

Key questions

Q: What breaks when sandbox rules only protect specific file paths in developer tools?

A: Path-only rules fail when the protected object can move or be represented differently, such as Git metadata stored outside .git. The control appears to work until a valid alternate layout is used, then privileged tooling reads the same authority from a different location. Security teams need object-level policy, not pathname matching alone.

Q: Why do AI coding agents increase trust risk in developer workspaces?

A: They can write repository state that other tools later treat as trusted configuration or executable input. That creates a trust transfer from a constrained agent session to a more privileged automation layer. The risk grows when tools auto-discover repositories and run helpers without user confirmation.

Q: How do security teams know if repository helper execution is creating hidden exposure?

A: Look for automated Git probing, repository-local helper use, and any editor or extension host that runs commands against newly created workspaces. If untrusted repos can trigger fsmonitor, hooks, or similar helpers, the boundary is already porous. The signal is not the presence of Git alone, but unsupervised execution tied to workspace discovery.

Q: Who is accountable when an agent-created repository triggers unsandboxed execution?

A: Accountability usually sits with the team that owns the trust boundary, not the agent itself. That means platform, developer productivity, and security owners must agree on which workspace artifacts are trusted, who can promote them, and what confirmation is required before helper execution. The control failure is governance, not just configuration.

Technical breakdown

Why Git directory indirection breaks path-based sandbox rules

Git does not require repository metadata to live in a literal .git directory. With --separate-git-dir, the worktree contains a pointer file while the real config and hooks live elsewhere. That means a sandbox rule written against one pathname can miss a valid Git repository that stores its authority under a different directory name. The core problem is abstraction mismatch: the control protects a string, while Git operates on a repository object. When the repository object is valid, Git will still read its config and may execute helpers defined there.

Practical implication: sandbox policies should model repository semantics, not just fixed paths.

How fsmonitor turns repository config into execution

core.fsmonitor is a Git performance feature that lets a helper program report file changes instead of scanning the tree every time. That helper is defined in repository-local configuration, so if an attacker can write the config, they can point Git at an executable they control. In this pattern, the danger is not the config file itself but the trust Git grants to repository-local settings during routine operations such as git status. A tool designed to improve speed becomes a code execution trigger when untrusted repositories are auto-probed.

Practical implication: disable or override hook-like helpers when evaluating repositories created by an agent.

Why auto-detection makes sandbox escapes cleaner

The exploit chain becomes stronger when a trusted host automatically detects and probes new repositories. If an editor extension notices a repository created by an agent and runs Git against it without confirmation, the extension host becomes the execution path outside the sandbox. This is a common pattern in agentic environments: a sandboxed process prepares state, and a more privileged service interprets it. The risk is not limited to Git. Any auto-discovered workspace artifact that can influence a privileged helper carries the same trust-transfer hazard.

Practical implication: treat newly discovered agent-created repositories as untrusted until a user explicitly confirms them.

Threat narrative

Attacker objective: The attacker objective is to turn agent-written repository state into unsandboxed code execution through trusted developer tooling.

1. Entry began when a sandboxed AI coding agent created a repository using Git's separate git directory option, allowing metadata to live outside the protected path the sandbox expected.
2. Escalation occurred when the agent wrote repository-local configuration that pointed core.fsmonitor at an attacker-controlled helper script, turning benign workspace state into executable instruction.
3. Impact followed when the editor's Git integration auto-detected the repository and ran Git outside the sandbox, which executed the helper and demonstrated boundary escape.

NHI Mgmt Group analysis

Path-based sandboxing fails when the protected object is a repository, not a filename. This finding shows that developer-tool controls often anchor to implementation detail instead of security meaning. Git can store trusted state in multiple locations, so a rule written for .git/config leaves a policy gap wherever the repository abstraction can move. Practitioners should map controls to the object being trusted, not the path spelling.

AI coding agents create a new kind of workspace trust handoff. The issue is not just that the agent can write files. The deeper problem is that other tools later treat those files as authoritative inputs, including hooks, helpers, and repository-local config. That is the same governance shape NHIs create in production systems: a non-human actor writes state that a privileged service later interprets. Identity and access teams should treat agent-created workspace state as untrusted machine authority.

Git helper execution is a privileged boundary, not a convenience feature. Features such as fsmonitor are operationally useful, but they also expand the set of code paths that can be triggered from repository state. That means secure developer tooling needs control-plane awareness, not just file-system restrictions. Teams should assume that any automation which reacts to workspace discovery can become part of the attack surface.

Agent sandboxing must extend to post-write consumers. A sandbox that blocks direct execution is only one layer if an unsandboxed extension host, indexer, or build helper later replays the agent's output. This is where NHI governance thinking helps: the risk sits in the trust chain after creation, not just in the initial action. Security teams should model every downstream consumer of agent-written artifacts as part of the control boundary.

Git trust amplification: the sandbox escape concept here is broader than Cursor. The named concept is Git trust amplification, where repository-local configuration written in a constrained context is later amplified by a privileged tool. That matters for any environment that auto-discovers code, loads local settings, or executes repository helpers. Practitioners should look for the same amplification pattern anywhere workspace metadata can influence privileged automation.

What this signals

Workspace trust will become a board-level software governance issue before it becomes a classic security incident. As agentic coding workflows spread, teams will need to decide which machine-generated artifacts can ever be treated as authoritative. The practical signal is that developer experience tools, extension hosts, and repo scanners now sit inside the identity-and-privilege conversation, not outside it.

Agent-created repositories are a governance boundary, not just a file-system event. Once an autonomous or semi-autonomous process can shape local configuration, the next control question is who may consume that state with elevated trust. The same logic that applies to NHI lifecycle management applies here: creation, use, and offboarding of machine-authored authority need explicit ownership.

Git trust amplification should be treated as a repeatable design pattern to hunt for. Any system that auto-discovers local state and turns it into execution, including build tools and IDE extensions, deserves the same scrutiny. For practitioners building policy around agentic AI, the priority is to separate workspace creation from trust promotion and to enforce that boundary consistently.

For practitioners

• Model repository semantics in sandbox policies Update path controls so they understand Git repository indirection, including separate git directory layouts and relocated metadata paths such as alternate config and hook directories.
• Disable helper execution during repository discovery Run Git with safe overrides when probing repositories created by agents, especially where fsmonitor, hooks, or other repository-local helpers could be invoked automatically.
• Treat agent-created workspaces as untrusted inputs Require explicit confirmation before editor services, scanners, or extension hosts trust a repository that a sandboxed agent has just created or modified.
• Inventory all post-write consumers of workspace state Identify every service that reads agent-written files after the sandbox has ended, including indexers, Git integrations, build systems, and automated review tools.

Key takeaways

• AI coding agents can bypass sandbox assumptions when tools trust repository metadata rather than the repository object itself.
• The exposure is not limited to Git paths, because auto-detection and helper execution can turn workspace state into unsandboxed code execution.
• Practitioners should harden repository discovery, model post-write consumers, and require explicit trust promotion for agent-created workspaces.

Key terms

• Repository-local configuration: Settings stored inside a code repository that change how tools behave when they read that repository. In Git, local configuration can control hooks, filters, and helper programs, which makes it security-sensitive because it can influence execution rather than just appearance.
• Separate git directory: A Git layout where the working tree contains a pointer file and the actual repository metadata lives in another directory. This is legitimate Git behaviour, but it complicates security controls that assume metadata always exists under a literal .git path.
• Fsmonitor: A Git helper mechanism that speeds up file change detection by asking a program what changed instead of scanning the tree from scratch. Because the helper is defined in repository configuration, it becomes a code execution path if untrusted configuration can point Git at an attacker-controlled script.
• Trust Amplification: A condition where a small identity or policy exception expands into a much larger attack path after compromise. In Microsoft 365, broad allow lists, unmanaged device enrollment, and default external access settings can multiply the effect of one stolen credential or one trusted sender.

What's in the full report

Pillar Security's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step proof-of-concept for the separate git directory bypass and the exact sandbox interaction.
• The specific fsmonitor configuration and helper execution sequence used to demonstrate the escape.
• Comparative context from the rest of The Week of Sandbox Escapes series, including related workspace trust failures.
• The exact remediation discussion around repository discovery, helper suppression, and trust confirmation.

👉 The full Pillar Security post shows the Git directory bypass, helper execution chain, and remediation detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, identity lifecycle, and secrets management. It is designed for practitioners who need to govern machine authority across modern security programmes.