Cursor terminal guardrail bypass shows AI editor risk in code workflows

At a glance

What this is: Noma Security identified a critical Cursor flaw that allowed terminal command restrictions to be bypassed through markdown obfuscation, leading to arbitrary command execution without user approval.

Why it matters: For IAM, PAM, and NHI practitioners, the issue shows how AI-assisted developer workflows can turn a local command approval control into an unreliable gate when untrusted context can steer execution.

Context

AI-assisted code editors do not just suggest text, they can also trigger actions in the developer workflow. That means command approval, script execution, and file modification controls now sit inside a system that parses both human instructions and model-generated content, which creates a new governance gap when those layers disagree.

In this case, the gap is not about authentication alone but about execution authority inside the development environment. A command allowlist or an "Ask Every Time" prompt only works if the parser that interprets context cannot be manipulated into treating an untrusted command as safe. That makes AI editor security part of broader identity and privilege governance for developer machines and toolchains.

Key questions

Q: What breaks when AI editors can bypass terminal approval prompts?

A: The control assumption breaks at the point of execution. If an editor can transform untrusted text into a command that skips allowlists or approval prompts, the guardrail no longer separates suggestion from action. That means the real control boundary has to move to the parser and execution layer, where the command is actually launched.

Q: Why do prompt injection attacks create workstation risk in code workflows?

A: They let attacker-controlled text steer an AI assistant into issuing commands the user did not intend to approve. In a code workflow, that can expose local secrets, modify files, or trigger downloads and scripts on the developer machine. The risk is higher because repository content is often treated as trusted context.

Q: What signs suggest an AI coding agent’s controls are failing?

A: Unexpected startup commands, modified hooks, writable policy files, or host activity that appears after a session ends are strong warning signs. If a tool can still change execution behaviour from inside the sandbox, the boundary is not holding where it matters.

Q: Should organisations treat AI agent permissions differently from normal developer tooling?

A: Yes, because AI agents often combine file access, command execution, and repository context in one workflow. That increases the blast radius of a trust bypass, so permission scope, startup sequencing, and local execution paths need to be governed as a single risk surface rather than separate implementation choices.

Technical breakdown

How markdown parsing created a terminal bypass

The flaw arose because the editor's terminal guardrail depended on filtering logic that did not fully account for markdown rendering behavior. Triple backticks normally mark formatted code blocks, but in this case the same syntax changed how the command was processed, letting the restriction layer misclassify the content. The result was a parser mismatch: the AI-facing context and the execution control did not apply the same trust rules to the same input. That is a classic control boundary failure in AI-enabled tooling, where the model, parser, and terminal each see different versions of the same instruction.

Practical implication: security teams should test whether execution controls still hold when commands arrive through formatted or transformed text paths.

Why prompt injection matters in developer workflows

Prompt injection is dangerous here because the malicious instruction does not need to be typed into the terminal. It can arrive through documentation, repository files, or code comments that the editor reads as context, then influence the agent’s output or command selection. Indirect prompt injection is particularly risky in code workflows because developers routinely trust repository content as operational context. Once the AI can be induced to issue a shell command, the attack stops being about text manipulation and becomes a local execution problem with real privilege consequences.

Practical implication: treat repository content as untrusted input to the AI layer, not as a safe source of execution context.

From command execution to developer workstation compromise

Once arbitrary command execution is available, the attacker can move from editor abuse to workstation impact. In a developer environment, that may mean reading environment variables, SSH keys, or cloud credentials, altering source code or build scripts, and using the compromised machine as a foothold for lateral movement. The important security point is that the editor is not the end state. It is the control break that hands the attacker a trusted execution surface inside the software delivery chain. That is why this type of flaw has supply chain implications even when the initial exploit occurs on a single laptop.

Practical implication: map editor-level command abuse to downstream credential exposure, code integrity, and workstation containment controls.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI-assisted development context into silent command execution that exposes secrets, alters code, and expands access beyond the initial workstation.

1. Entry begins when malicious instructions are embedded in external content that the AI editor reads, including files, comments, or documentation.
2. Credential access follows when the bypassed terminal control permits arbitrary commands that can read local secrets such as .env files, SSH keys, or cloud credentials.
3. Escalation and lateral movement become possible once the compromised workstation can modify code, alter build scripts, or probe internal resources.
4. Impact is achieved when attacker-controlled commands turn a developer machine into a beachhead for code tampering, exfiltration, or broader network access.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

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 editor guardrails are becoming a privilege boundary, not just a UX feature. When an editor can execute terminal commands on behalf of a user, the control is effectively part of the privilege model for the workstation. That means allowlists, approvals, and parsing logic need to be treated as security boundaries with the same rigor as identity and access controls. Practitioners should govern AI editors as execution-capable systems, not as passive productivity tools.

This flaw illustrates a parser trust gap, not merely a prompt injection problem. The real failure mode is that trusted execution depended on how content was rendered, transformed, or escaped before command handling. Once trust decisions vary across parsing layers, a single obfuscation trick can bypass the intended control. Security teams should look for places where model output, markdown formatting, and shell execution are governed by different assumptions.

Developer AI now creates a new form of non-human execution authority. The AI does not need to be autonomous to be risky; it only needs enough agency to select or shape commands that the user would otherwise approve manually. That creates an identity and privilege governance problem for code tools, because the system can act with delegated human authority while obscuring the moment of execution. The practitioner conclusion is to align AI tool permissions with the minimum command surface required.

Supply chain risk now starts before code is committed. If an attacker can use an editor to modify files, scripts, or config locally, the compromise can propagate into repositories and build pipelines before any conventional security checkpoint sees it. That shifts the control question from post-commit scanning to pre-execution containment on the developer endpoint. Teams should treat AI editor guardrails as upstream software supply chain controls.

Named concept: execution-context mismatch. This article shows how a command can be interpreted as safe by one layer and dangerous by another, because the execution path and the security policy do not share the same parsing model. That is the condition attackers exploit in AI-assisted workflows, and it demands controls that validate at the exact point of execution. Practitioners should design for one trust decision per command, not one decision per representation.

What this signals

Execution-context mismatch: AI-assisted development tools create a control problem when the text that informs the model is not governed by the same trust rules as the command that reaches the shell. That gap is what turns a formatting trick into an execution path, and it is why editor security now belongs in developer privilege governance.

For practitioners, the immediate takeaway is that AI-assisted coding workflows need endpoint and supply chain controls, not just prompt filtering. If an editor can read untrusted repository content and act on it, then containment has to happen at the exact boundary where the command is launched.

The practical risk is no longer limited to prompt injection as a model safety issue. It is a workstation security issue, because the attack outcome is secret exposure, code tampering, and foothold creation on a trusted development machine.

For practitioners

• Harden terminal approval paths against formatted input Test whether command allowlists and approval prompts still block execution when commands are wrapped in markdown, code fences, or other transformed text forms.
• Treat repository content as untrusted AI context Review whether documentation, comments, and README files can influence AI agent command selection or execution without a separate trust decision.
• Constrain editor command authority to minimum necessary scope Limit which shell actions an AI editor can initiate, especially filesystem writes, secret access, and script execution in developer environments.
• Monitor for secret exposure from developer endpoints Prioritise detection for environment variable dumping, SSH key access, and unusual outbound transfers originating from AI-assisted coding workstations.
• Validate pre-commit integrity of AI-altered files Check whether AI-assisted edits can reach build scripts, config files, or source control with no human review at the point of execution.

Key takeaways

• The vulnerability showed that command approval controls can fail when the parser and execution layer do not evaluate the same input in the same way.
• The risk is not limited to the editor itself, because arbitrary command execution can expose secrets, alter code, and open a path to lateral movement.
• The control that matters most is validation at the point of execution, with untrusted AI context separated from terminal authority.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Execution-Context Mismatch: Execution-context mismatch is a control failure where the system that interprets a request and the system that executes it apply different trust rules. In AI-assisted development, that gap can let formatted or transformed text bypass command restrictions and reach the shell.
• Command Allowlist File: A local file that records commands a tool is permitted to run again without asking. In AI coding assistants, that memory can become sensitive because the command text may include tokens, headers, or environment variables that should never leave the developer machine.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security decisions that shape modern development and operations.