AI coding agents turn Git hooks into a local code execution risk

At a glance

What this is: This is an analysis of a high-severity Cursor IDE flaw where AI-driven Git operations can trigger malicious hooks and execute attacker code locally.

Why it matters: It matters because developer workstations now sit inside the trust boundary for AI-assisted coding, and identity, secrets, and source-code access can all be exposed through one automated workflow step.

By the numbers:

• Cursor published the vulnerability as CVE-2026-26268 in February, 2026.

👉 Read Novee's analysis of the Cursor AI coding agent CVE-2026-26268 flaw

Context

AI coding assistants change the security boundary around development work because they can take actions, not just suggest code. In this case, the primary issue is not a broken authentication flow or a remote API flaw, but a trust failure between AI agent behaviour, Git features, and untrusted repository content. That makes this a developer security and identity governance problem as much as a vulnerability disclosure.

For IAM and NHI teams, the important intersection is that agent instructions, repository configuration, and tool invocation behave like delegated identity. When a coding agent can execute system-level operations, the question becomes who or what authorised the action, what context was inherited, and whether the resulting access path was constrained to the task. That is a typical failure pattern for emerging agentic workflows, not an edge case.

Key questions

Q: What breaks when AI coding agents are allowed to run Git operations on untrusted repositories?

A: The trust boundary breaks because the agent can trigger repository-local behaviour that was never meant to be safe by default. Malicious hooks, nested repositories, and injected instructions can turn a normal checkout into host-level code execution. That risk is highest when the workstation already contains tokens, source code, or internal access.

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 agent-driven repository access is operating outside policy?

A: Look for agent actions that touch untrusted repositories, trigger local automation, or request broader shell access than the task requires. If the workflow depends on hidden configuration, inherited privileges, or commands the user did not explicitly review, the agent is already outside the intended control boundary.

Q: What should organisations do after a developer tool is shown to allow arbitrary code execution?

A: Contain the exposure by limiting which repositories agents can process, tightening endpoint execution controls, and revoking any credentials that may have been present on affected machines. The priority is to prevent the same workflow from being replayed while the host, token scope, and repository trust model are still unchanged.

Technical breakdown

How Git hooks become executable attack surface inside AI coding workflows

Git hooks are local scripts that run automatically at defined repository events such as pre-commit or post-checkout. In normal development, they automate repetitive tasks and live in repository metadata, not tracked source files. The exploitable condition appears when a repository contains a nested bare repository with a malicious hook and the IDE or agent performs a Git action that activates it. Because the hook runs outside the application’s visible prompt flow, the execution looks like a normal workflow step while actually becoming code execution on the host.

Practical implication: restrict which repositories and metadata structures AI coding tools may process, especially where local hooks can fire.

Why autonomous Git operations change the trust model for developer machines

Traditional developer tooling assumes the human decides when to run commands and can inspect what is about to happen. An AI agent breaks that assumption by interpreting a prompt and selecting the Git operation itself. Once the tool is trusted to choose the action, attacker-controlled repository content only needs to shape the execution context. That turns routine operations like checkout, clone, and branch switching into a delegated decision path with security consequences, especially when the repository is untrusted or externally sourced.

Practical implication: treat agent-driven command execution as privileged activity and require explicit policy controls around repository trust.

Why local developer environments are part of the agentic attack surface

Developer endpoints often hold credentials, tokens, source code, and internal access to build systems, making them high-value compromise targets. When an AI assistant can execute commands locally, the endpoint itself becomes part of the attack path rather than a passive workstation. The security boundary extends beyond the IDE to the environment, the repository, and the instructions the agent is allowed to follow. That means endpoint hardening, secrets handling, and execution controls now intersect with agent governance.

Practical implication: classify AI-assisted developer workstations as sensitive systems and enforce tighter secrets, endpoint, and execution controls.

Threat narrative

Attacker objective: The attacker aims to turn an ordinary AI-assisted repository interaction into arbitrary code execution on the developer’s machine.

1. Entry occurs when a developer opens or works with an untrusted repository in an AI-powered IDE that can run Git operations autonomously.
2. Credential or code execution is triggered when a malicious nested bare repository exposes a hook that fires during the agent’s Git workflow.
3. Impact follows when the hook executes attacker-controlled code on the developer machine, giving the attacker a foothold inside a production-equivalent endpoint.

Breaches seen in the wild

• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI coding agents create a delegated execution problem, not just a tooling problem. The real risk is that the assistant can select and run actions that inherit trust from the human without receiving the same scrutiny. That makes repository content, instructions, and local automation part of the access decision. For identity teams, this is a form of machine-mediated delegation that must be governed explicitly, not assumed safe by default.

Local developer environments are now identity-critical assets. The article reinforces that workstation compromise is not a side issue when those machines hold tokens, code, and access to internal systems. Once an AI agent can trigger host-level execution, endpoint security and identity governance become inseparable. Practitioners should treat development endpoints as controlled execution zones, not ordinary user devices.

Trust boundary violations in agentic workflows are the named failure mode here. The key issue is not Git itself, but the assumption that the agent’s chosen action is safe because the prompt was benign. That is the wrong governance model for autonomous tool use. Zero standing privilege principles and task-scoped execution controls become relevant because the agent should not inherit more authority than the immediate workflow requires.

AI agent governance must extend to repository trust and execution policy. Security programmes that only review application code miss the operational layer where malicious hooks and instructions can be introduced. The control gap is lifecycle governance for agent permissions, allowed repositories, and command execution paths. Organisations that do not formalise those boundaries will keep discovering that “developer convenience” is functioning as a security exception.

OWASP-NHI thinking applies here because the agent is acting like a non-human actor with delegated authority. Even though the compromise lands on a human developer machine, the exploit path depends on how the agent was authorised to act and what it was allowed to execute. That intersection matters for IAM and NHI teams because it turns agent instructions into an access governance problem, not merely an application bug.

From our research:

• When an AI agent starts autonomously executing Git operations inside a repository it doesn’t control, attacker code execution can reach the developer’s machine, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For a broader NHI view: Review The 52 NHI breaches Report for recurring credential abuse patterns that also shape agentic risk decisions.

What this signals

Agentic developer tooling is collapsing the gap between code review and command execution. Security teams should expect more findings where the dangerous step is not the application response, but the automation chain that follows a prompt. The practical response is to make execution policy explicit and reviewable, because prompt-level approvals do not meaningfully constrain host-level behaviour.

Developer identity governance now extends to workload-like behaviour on endpoints. When a coding assistant can make trust decisions about repositories, the organisation needs visibility into which actions are delegated, which are blocked, and which inherit credentials. This is where Top 10 NHI Issues becomes relevant: delegated actors need lifecycle controls, not informal exceptions.

Task-scoped execution becomes the new boundary for AI-assisted development. The fastest way to reduce risk is to stop assuming that all repository actions are equivalent. Controls should distinguish reading code from executing code, and trusted repositories from arbitrary internet sources. For teams mapping governance to standards, OWASP Agentic AI Top 10 is the right lens for command misuse and agentic abuse patterns.

For practitioners

• Constrain autonomous Git execution Limit AI coding agents to approved repositories and disable automatic execution paths that can activate local hooks in untrusted codebases.
• Separate agent action from host trust Run AI coding assistants in controlled environments where command execution is sandboxed and host-level privileges are not inherited by default.
• Review repository metadata as attack surface Inspect nested repositories, hook locations, and agent instruction files as part of secure code ingestion, not just source files.
• Treat developer secrets as high-value identity material Reduce token exposure on developer machines, shorten credential lifetime, and scope access so a workstation compromise cannot immediately reach internal systems.

Key takeaways

• AI coding agents can convert ordinary Git activity into arbitrary code execution when repository content is hostile.
• Developer endpoints hold enough credentials and source access that a local exploit can become a broader identity and security incident.
• The control gap is not only in the IDE, but in how organisations govern delegated agent actions, repository trust, and execution policy.

Key terms

• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Git hook: A local script that Git runs automatically when a repository event occurs, such as commit, checkout, or merge. Hooks are legitimate automation features, but they become risky when attacker-controlled repository structures can cause them to run unexpectedly on a developer machine.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

What's in the full report

Novee's full post covers the operational detail this analysis intentionally leaves in the source:

• Reconstruction of the Git hook and nested repository interaction that enabled the exploit path
• Technical proof of how Cursor agent behaviour can be steered into executing attacker-controlled commands
• Responsible disclosure timeline and remediation context for CVE-2026-26268
• Security testing implications for AI coding assistants that operate on untrusted codebases

👉 Novee's full post covers the exploit chain, agent behaviour, and responsible disclosure details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect delegated access, execution control, and identity risk across modern programmes.