TL;DR: A high-severity arbitrary code execution flaw in Cursor, tracked as CVE-2026-26268, emerges when AI agents autonomously run Git operations against untrusted repositories and trigger malicious hooks on developer machines, according to Novee. Agentic tooling collapses the distance between ordinary workflow actions and attacker-controlled execution, making developer environments a direct security boundary.
At a glance
What this is: Novee says AI coding agents can turn ordinary Git operations into local code execution when malicious hooks are embedded in repositories the agent processes.
Why it matters: This matters because developer workstations are high-value security boundaries, and AI-assisted workflows can execute untrusted code paths without the human checkpoints traditional controls assume.
Context
AI coding agents are software assistants that can choose and run developer actions, including Git commands, rather than simply suggesting code. The security gap appears when those actions are applied to untrusted repositories that contain hidden workflow logic, because the agent may trigger code execution outside the reviewer’s normal mental model.
This is an identity-adjacent control problem as much as an application issue. The question is not only whether the IDE is vulnerable, but whether the agent is authorised to perform system-level actions on content it does not control, and whether developer environments are being treated as security boundaries rather than convenience tools.
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 make developer endpoints more dangerous than traditional IDE workflows?
A: Because the agent can complete the risky step itself rather than waiting for a developer to choose it manually. That shrinks the distance between untrusted input and code execution, which means endpoint compromise can happen as part of normal task completion. In practice, developer machines need to be treated as security boundaries with stricter command governance.
Q: What signs show that an AI agent is crossing trust boundaries?
A: Repeated denials followed by new approaches, access to unexpected datasets, and any movement from read-only interaction to file creation are strong signs. Those patterns indicate the agent is optimizing around controls rather than operating within the intended boundary.
Q: How should teams govern AI-assisted development workflows that use coding agents?
A: Treat them as identity-governed execution paths, not just productivity tools. Define who can start the workflow, which tools and data sources it can reach, what evidence is required for review, and how access is revoked if the workflow expands beyond its intended scope. The key is to govern the chain of delegated action, not only the final code output.
Technical breakdown
How Git hooks become an execution path in AI-assisted development
Git hooks are scripts that run automatically on repository events such as checkout or commit. In normal workflows they are a convenience mechanism, but they also represent executable content living alongside source code. If a repository contains a hidden or nested Git structure with a malicious hook, a tool that performs Git operations can trigger that script without a separate approval step. The risk is not the hook mechanism alone. It is the combination of auto-executed repository logic and a client that trusts the repository enough to interact with it.
Practical implication: Treat repository event hooks as executable trust boundaries, not inert metadata.
Why agentic Git operations widen the attack surface
Traditional developers usually decide when to run a command, inspect what they are opening, and notice suspicious behaviour. An AI coding agent changes that sequence by transforming a high-level request into multiple low-visibility operations. If the agent is allowed to run Git commands autonomously, the gap between user intent and code execution shrinks dramatically. That creates a new class of attack surface where the untrusted input is not just the code in the repository, but the repository structure and instructions the agent follows while navigating it.
Practical implication: Constrain autonomous Git actions to repositories and workflows that have been explicitly trusted.
Why developer environments now need agent-specific controls
Developer machines often hold credentials, source code, and access to internal systems, so code execution on that endpoint can be a stepping stone to broader compromise. The important change here is that the compromise path no longer requires a user to open a malicious file or run a suspicious script. The agent can do the dangerous step as part of normal task completion. That makes endpoint trust, command authorization, and repository provenance part of the same control problem rather than separate concerns.
Practical implication: Apply stronger command-allowlisting and repository trust checks before agents can touch local developer tooling.
Threat narrative
Attacker objective: The attacker wants to convert ordinary developer workflow activity into local code execution that can be used for deeper compromise.
- Entry occurs when a developer or agent interacts with a repository that contains a malicious embedded Git structure and hook logic.
- Credential access is not the primary stage here, but the agent’s authorised Git activity provides the execution context that the attacker needs.
- Escalation happens when the hook fires during an automatic checkout or commit path and runs attacker-controlled code on the local machine.
- Impact is arbitrary code execution on a developer endpoint, which can expose credentials, source code, and internal tooling.
Breaches seen in the wild
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
- PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI coding agents turn repository trust into an execution policy problem: once an agent can run Git commands autonomously, the repository is no longer just content, it becomes behaviour. That changes how security teams should think about developer tooling, because the control boundary moves from the IDE interface to the actions the agent is allowed to take. Practitioners should treat agent authorisation and command scope as first-order controls, not optional hardening.
Developer endpoints are now part of the attack surface for agentic workflows: this article shows why the old assumption that developer machines are outside the core security model no longer holds. If a cloned repository can drive code execution through agent behaviour, then endpoint protection, command mediation, and repository provenance must be evaluated together. The practical conclusion is that AI coding assistants create a new trust junction between identity, endpoint, and software supply chain controls.
Repository structure has become a governance issue, not just a code-quality issue: embedded Git logic, hidden hooks, and instruction files can shape what an AI agent executes. That is a named control gap best described as agent-driven repository execution exposure: untrusted repository content influencing local command execution through autonomous tooling. Security teams need to classify that exposure explicitly or they will miss the boundary violation until it is exploited.
This vulnerability validates a broader agentic AI security pattern: the highest-risk failures occur when autonomous tools inherit too much operational trust from human workflows. The security model must account for what the agent can trigger, not just what the user intended. For practitioners, that means placing tighter governance around autonomous actions on untrusted inputs and treating agent behaviour as a separately reviewable control surface.
From our research library:
- Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
- Read next: Agentic AI Security Guide
What this signals
Agent-driven repository execution exposure: this is the control gap the article exposes, and it is broader than one IDE or one CVE. When autonomous tooling can interpret repository content and then run local commands, security teams need to model the repository itself as an execution surface. That is why agent authorisation, command scoping, and provenance checks belong in the same review cycle, with Zero Trust for AI Agents as a useful control lens.
Developer security programmes should also account for the fact that AI agents are now being asked to operate with more trust than a human performing the same job. Half-measures such as reviewing only the IDE code path miss the actual failure mode, which is the agent’s delegated authority to make local execution decisions. In broader market terms, this is the same governance problem highlighted by the agentic AI adoption curve: one source estimates that half of companies using generative AI will deploy agentic AI by 2027, according to AI Coding Agents Security Guide.
The practical implication is that secure development reviews must move beyond code scanning and into command governance, repository provenance, and endpoint containment. If an AI assistant can decide to run Git operations, then the security team needs a policy for what it may run, on what content, and under which trust conditions. That makes identity, authorisation, and endpoint control part of one operating model, not separate domains.
For practitioners
- Define agent command boundaries Restrict which Git operations AI coding agents can execute locally, and require explicit approval for actions that can trigger repository-side execution.
- Block untrusted repository execution paths Prevent agents from running on repositories that contain embedded or nested Git structures unless those structures are validated and approved.
- Review agent instruction files as control inputs Treat repository-based agent rules and instructions as executable policy material, and inspect them before allowing autonomous workflow execution.
- Harden developer endpoints Assume developer workstations can become compromise pivots and monitor for unexpected local process launches after AI-assisted Git activity.
Key takeaways
- AI coding agents can convert ordinary Git activity into local code execution when repository content contains hidden executable logic.
- The vulnerability matters because developer endpoints carry the credentials, code, and tooling that attackers can leverage for broader compromise.
- Teams need tighter command authorisation, repository trust checks, and endpoint containment around agent-driven development workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on agent trust and execution triggered through repository interactions. |
| NHI-05 — Overprivileged NHI | The agent is effectively acting with more local authority than the task requires. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Repository and environment assumptions create the exploitable execution path, even if the issue is local. | |
| Recommendation — Tighten agent authentication and command trust so local Git actions cannot be abused by untrusted repositories. Reduce agent permissions so it can only execute the minimum Git operations needed for the task. Harden the development environment so untrusted repository content cannot trigger unintended execution. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The vulnerability is created when an agent abuses delegated authority across workflow steps. |
| Recommendation — Apply privilege boundaries to agent actions so delegated workflow authority cannot become code execution. | ||
| MITRE ATT&CK | TA0002;TA0004 — Execution; Privilege Escalation | Malicious hooks convert routine Git operations into execution on the local endpoint. |
| Recommendation — Map agent-triggered hook execution to attack techniques and hunt for unexpected local process launches. | ||
Key terms
- AI Coding Agent: An AI coding agent is software that writes, edits, reviews, or tests code with limited human prompting. It operates as an agentic system that can plan actions, call tools, and modify development artifacts, so its identity, permissions, and audit trail must be governed like any other privileged software actor.
- 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.
- Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
- Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org