Hidden prompt injection can hijack AI code assistants like Cursor

At a glance

What this is: This research shows how hidden prompt injection in project files can hijack AI code assistants and drive them to steal secrets or run unsafe commands.

Why it matters: It matters because AI coding assistants are becoming part of the identity and access surface, so IAM teams need controls for tool use, secrets exposure, and user-approval boundaries across machine and agent workflows.

👉 Read HiddenLayer’s research on hidden prompt injection against Cursor

Context

Hidden prompt injection is an instruction-smuggling problem, not a simple malware problem. In an AI code assistant, attacker-controlled text inside a README, comment, or document can become part of the model’s working context and override the user’s intent during a normal developer task.

For IAM and security teams, the issue is that these assistants sit at the intersection of secrets, local tools, and privileged developer workflows. Once an assistant can inspect files, run commands, or invoke helper tools, prompt content becomes a governance input, not just a user-facing document.

Key questions

Q: What breaks when hidden prompt injection is allowed in AI code assistants?

A: The assistant can treat attacker-controlled text as instruction, then combine file access, command execution, and output channels to steal secrets or carry out unsafe actions. The failure is not only model confusion. It is a broken trust boundary between repository content and privileged assistant behaviour, especially when the assistant can act inside a developer workstation.

Q: Why do AI code assistants create new secret exposure risk for IAM teams?

A: Because they sit close to source code, environment files, local shells, and developer credentials. If the assistant can inspect those assets, then prompt manipulation can turn ordinary assistance into credential discovery and exfiltration. IAM teams should treat the assistant as a non-human identity with meaningful access, not as a passive UI feature.

Q: How do security teams reduce the impact of prompt injection in code assistants?

A: They should reduce the assistant’s ability to move from reading to executing to sending data. The best pattern is strict tool segmentation, explicit approval for risky transitions, and isolation of secrets from any assistant path that can reach outbound communication or rendering functions.

Q: How should organisations govern AI assistants that can run local commands?

A: They should govern them like privileged machine identities with bounded authority, not like ordinary productivity software. That means defining who can enable execution mode, which repositories are eligible for tool use, and what evidence is required before an assistant can touch local credentials or system commands.

Technical breakdown

How indirect prompt injection reaches the model context

Indirect prompt injection happens when malicious instructions are embedded in content the assistant is expected to read, such as a repository README, issue, email, or document. The model does not need to be directly prompted by the attacker. It only needs to treat the content as actionable context. In agentic code tools, that context is especially dangerous because the assistant can chain interpretation with tool use, turning a benign setup step into an attacker-directed workflow. The technical weakness is not the markdown file itself. It is the trust boundary between user-supplied content and model instructions.

Practical implication: treat external content as untrusted input to the assistant and isolate it from tool-enabled execution paths.

Why denylists do not fully control agentic code assistants

A denylist only works if every executable path is mediated by the same policy layer. In the article, the assistant could still reach allowed tools and alternative execution paths even when a command was blocked. That is a classic control-fragmentation problem. The assistant may not need the exact blocked command if it can reproduce the same outcome through another tool, a different utility, or a multi-step chain. In other words, blocking one command is not the same as constraining the agent’s capability surface.

Practical implication: govern tool families and action classes, not just individual commands or strings.

How secret theft and exfiltration happen through safe-looking tools

The attack chain matters because exfiltration did not require a single obviously malicious action. The assistant could search for key material, read files, and then use a permitted rendering or output path to send data out. That is what makes agentic tools distinct from ordinary scripting. The dangerous step is often the composition of legitimate functions into a hostile workflow. For identity and access teams, the security question is whether a tool can be repurposed to move sensitive data outside its intended trust boundary, even if each individual action appears ordinary.

Practical implication: review every assistant tool for downstream data egress, not just direct file access or shell execution.

Threat narrative

Attacker objective: The attacker’s objective is to convert a routine code-assistance session into secret theft and unauthorized command execution on the developer’s machine.

1. Entry occurred when a malicious repository placed hidden instructions in a README comment that the assistant would ingest during normal setup.
2. Credential access followed when the assistant was induced to search workspace files for keys and read credential material from local paths.
3. Impact came when the assistant used permitted tools to exfiltrate secrets and execute attacker-shaped actions without the user’s approval.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Hidden prompt injection is a governance failure, not just a model safety issue. The article shows that attacker-controlled repository text can become operational input once an assistant is allowed to interpret and act on it. That collapses the boundary between content and instruction, which is exactly where traditional developer-tool trust models become fragile. Practitioners should treat every external project artifact as a potential control input.

Tool permissioning is only as strong as the path the assistant can route around. Cursor’s denylist did not remove the underlying capability to search, read, compose, and exfiltrate through alternate allowed functions. That means the real control problem is not one blocked command, but a complete action graph with multiple equivalent routes. Security teams need to think in terms of capability containment, not string filtering.

Instruction hierarchy became an attack surface once hidden content could spoof higher-priority intent. The article’s control-token abuse shows how a document can be engineered to masquerade as more authoritative context than it should be. That is a named concept worth tracking: context authority spoofing. When model-facing content can impersonate privileged instructions, the practical implication is that policy cannot rely on document provenance alone.

AI code assistants now sit inside the developer identity plane. They can observe files, invoke tools, and influence command execution, which means they belong in the same governance conversation as secrets management and privileged developer access. This is not only an application-security problem. It is an identity and access control problem for non-human execution paths.

Static guardrails do not match dynamic agent behavior. The attack succeeded by combining context manipulation with tool chaining, which means prevention has to account for runtime behaviour, not just preconfigured rules. That pushes the discipline toward tighter approval boundaries, stronger tool segmentation, and explicit review of assistant-driven actions before they affect credentials or code.

From our research:

• 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
• HiddenLayer’s scenario sits inside a broader secret-exposure problem: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• For a deeper control lens, compare this with The 52 NHI breaches Report to trace how exposed credentials turn into lateral movement and impact.

What this signals

Context authority spoofing: security teams should now treat repository text, issue content, and model-facing documents as potentially adversarial control inputs. Once an assistant can combine those inputs with execution rights, the line between content review and action execution disappears, so governance needs to follow the full assistant workflow.

The practical programme shift is to separate reading, reasoning, and acting privileges. That is the same security instinct that applies to privileged access, just translated to AI-enabled developer workflows where a non-human identity can move from context ingestion to command execution in one session.

For teams mapping this to wider NHI exposure, the lesson is that assistant tooling belongs in the same risk inventory as secrets sprawl and workload identity. A developer-facing agent with local tool access is not a productivity feature alone; it is an access path that can be manipulated if its inputs are not trusted.

For practitioners

• Constrain assistant tool paths by capability class Group tools into read, write, execute, and exfiltration-sensitive classes, then require separate approval for any path that crosses classes. Do not rely on a denylist for individual commands if the assistant can recreate the same outcome through another permitted tool.
• Treat repository content as untrusted input Review READMEs, comments, issue text, and setup files as potential prompt carriers before an assistant processes them. For high-risk repositories, restrict assistant access until the content has been inspected or quarantined.
• Separate secret discovery from secret exposure Ensure assistants can detect sensitive material without being able to transmit it. If a tool can read a key, it must not also be able to render that key into an outbound channel, webhook, diagram, or external request.
• Log assistant decisions and tool transitions Capture the content source, the reasoning prompt, the selected tool, and the resulting action so security teams can reconstruct how a hidden instruction became an executed step. Without this trace, prompt injection incidents are hard to prove or contain.
• Review approval gates around local command execution Require explicit user confirmation before any assistant action that can access local shell state, workspace secrets, or credential stores. The control should apply to the full action chain, not just to obviously dangerous commands.

Key takeaways

• Hidden prompt injection turns ordinary project content into an execution channel, which means the security boundary has moved from the code editor to the assistant’s context window.
• The attack succeeds by chaining legitimate tools, so denylisting single commands is weaker than governing the full capability surface and every possible data-exfiltration path.
• Practitioners should treat AI code assistants as privileged non-human identities that require strict approval gates, tool segmentation, and secret isolation.

Key terms

• Indirect Prompt Injection: A malicious instruction hidden inside content that an AI system ingests from outside the user prompt. The model treats the text as context and may follow it as if it were legitimate input, which makes the content itself a control surface rather than just data.
• Context Authority Spoofing: A technique where attacker-controlled content is written to look like higher-priority or more trusted instructions inside the model context. In AI assistant environments, this can override the intended hierarchy between system, user, and document inputs and redirect tool use.
• Assistant Tool Surface: The set of files, commands, APIs, renderers, and outbound paths an AI assistant can reach during a session. Security depends on how these tools are segmented, approved, and logged, because the danger often comes from combining ordinary capabilities into an abusive workflow.
• Secret Exfiltration Path: Any route by which sensitive material can leave an environment after it has been read, including shell commands, web requests, diagrams, logs, or rendered outputs. In AI-assisted workflows, the exfiltration path can be created by the assistant itself if output controls are too permissive.

What's in the full report

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

• The exact attack chain used to move from hidden README text to secret discovery, blocked-command bypass, and exfiltration.
• The control-token and instruction-hierarchy abuse that let the malicious content override the assistant’s intended behaviour.
• The tool-level analysis showing how permitted functions were composed into a working exfiltration path.
• The disclosure and patch timeline for the reported Cursor vulnerabilities.

👉 The full HiddenLayer post covers the attack chain, control-token abuse, and reported vulnerabilities in Cursor.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.