TL;DR: Hidden prompt injections in GitHub READMEs can steer Cursor into exfiltrating secrets, bypassing denylisted commands, and executing attacker-chosen actions through seemingly ordinary coding workflows, according to HiddenLayer. The core problem is that agentic code assistants can be manipulated through trusted content and permitted tools, so governance must extend beyond prompt hygiene.
At a glance
What this is: This research from HiddenLayer shows how hidden prompt injection in project files can hijack AI code assistants like Cursor and drive secret exfiltration and blocked-command execution.
Why it matters: It matters because security teams now have to govern what agentic coding tools ingest and execute, not just the permissions around the developer account using them.
Context
Hidden prompt injection is a control-plane problem for AI code assistants. When an assistant reads project content and can act on it through workspace tools, malicious instructions can ride inside ordinary files and redirect behaviour without changing the developer’s intent.
For identity and access teams, the issue sits at the boundary between NHI governance and agentic AI governance. The same workflow that lets a coding assistant inspect files, run commands, and move data also creates a path for untrusted content to influence what that assistant does next.
Cursor is the example in this article, but the underlying risk applies to any coding assistant that can consume repository content and invoke tools locally or remotely. The governance question is not whether the assistant is helpful; it is whether its inputs, tool use, and approval boundaries are actually trustworthy.
Key questions
Q: What breaks when an agent can read untrusted repository content as if it were instructions?
A: The trust boundary breaks first. A malicious issue, comment, or file can redirect the agent’s behaviour and turn delegated access into unintended data movement. The real failure is not that the model was fooled, but that untrusted content was allowed into the instruction path without isolation, validation, or pre-execution policy control.
Q: Why do hidden prompt injections create risk for AI assistants that summarise messages?
A: Hidden prompt injections create risk because the model may treat embedded instructions as part of the message content rather than as hostile manipulation. When an assistant can summarise, rewrite, or act on email, attackers can steer output, expose system prompts, or trigger downstream actions. The danger is not only wrong text, but unintended trust placed in malicious input.
Q: What are the signs that an AI coding assistant is misusing tool permissions?
A: Watch for unexpected tool chains, especially when a single assistant task touches file search, secret discovery, and outbound rendering or command execution. Another warning sign is when apparently harmless repository content changes the assistant’s behaviour in ways the user did not request. That often means instruction hierarchy or tool gating is not holding.
Q: Should teams treat coding assistants like privileged non-human identities?
A: Yes. If an assistant can read private code, access local files, and trigger tools on behalf of a developer, it behaves like a governed non-human identity with real blast radius. Teams should apply least privilege, approval boundaries, and lifecycle controls to the assistant’s access just as they would to any other machine actor.
Technical breakdown
How indirect prompt injection reaches a coding assistant
Indirect prompt injection happens when attacker-controlled text is embedded in content the model is likely to read, such as a README, email, or document. The model treats that text as part of its context window and may follow it if instruction hierarchy is weakly enforced or spoofed. In this article, the payload was hidden in a markdown comment, which made it invisible in normal rendering while still present to the model. The real mechanism is trust transitivity: the assistant treats repository content as operationally relevant because it is part of the task, then executes the attacker’s instructions as if they were workflow guidance.
Practical implication: separate model-readable content from trusted operational instructions and treat repository files as untrusted input.
Why denylists and permission gates can fail in agentic workflows
A denylist only works when the assistant actually respects it at execution time. The article shows a gap where blocked commands could still be reached through prompt steering, and where some tools remained usable without a fresh approval step. That matters because agentic systems often combine reasoning, tool selection, and local execution in a single loop. Once the assistant is willing to reinterpret instructions from a repository file, the approval model becomes porous unless enforcement sits below the model layer and applies consistently across every tool path.
Practical implication: enforce command and tool restrictions at the execution layer, not only in the model prompt or UI workflow.
How secret exfiltration works through seemingly safe tools
The article’s attack chain did not rely on a single dangerous API. Instead, it chained ordinary capabilities: read workspace data, identify secrets, and leak the result through a permitted output channel. That pattern is important because many assistant tools look harmless in isolation. In practice, the risk is the combination of file access, context accumulation, and outbound rendering or network-capable features. Even when direct egress is restricted, an allowed visualization or content-generation tool can become the exfiltration path if it can embed attacker-controlled data into a rendered artefact.
Practical implication: review every allowed tool for compound misuse, not just for its standalone function.
Threat narrative
Attacker objective: The attacker wants the coding assistant to disclose secrets and carry out blocked or malicious actions while appearing to be part of normal development work.
- Entry occurs through a hidden prompt injection embedded in a GitHub README comment that the user is unlikely to inspect closely.
- Credential access follows when the assistant is steered to search the workspace for keys and other sensitive material.
- Impact occurs when the assistant uses permitted tool paths or rendered outputs to exfiltrate secrets and execute attacker-chosen actions without user approval.
Breaches seen in the wild
- 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.
- 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.
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
Hidden prompt injection turns repository content into an execution surface: The security boundary is no longer the code editor alone. When a coding assistant ingests project files and can act on them, README text becomes an attack input, not documentation. That means the trust model for developer tooling must account for hostile content inside ordinary workflow artefacts, not just malicious binaries or obvious phishing lures.
Prompt hygiene is not a sufficient control for agentic code assistants: The article shows that the issue is not merely bad prompting but instruction transitivity across context, tools, and output channels. A hidden instruction can survive rendering tricks, bypass user scrutiny, and influence the assistant even when the developer never intended to execute it. The governance lesson is that model-facing trust boundaries must be explicit, enforced, and observable.
Command allowlists and denylists do not solve tool-chain abuse on their own: If an assistant can still reach sensitive state through a sequence of permitted actions, then command filtering only narrows the path rather than closing it. HiddenLayer’s example shows how blocked commands, workspace search, and exfiltration can be combined into one attack chain. Practitioners should treat compound tool use as the primary risk unit, not individual tool permissions.
Tooling that can read, reason, and render needs governance across the whole loop: AI coding assistants are becoming de facto non-human operators inside developer environments. That makes them subject to NHI-style lifecycle, access, and containment questions even when the immediate threat is prompt injection. The practical conclusion is that identity governance for developer assistants must cover input trust, tool scope, and output egress together.
Trusted workflow artefacts now carry identity risk: The named concept here is trust transitivity in coding assistants. A file that exists to help developers can also steer machine behaviour, which collapses the old assumption that documentation is passive. Once workflow artefacts can direct execution, practitioners need to classify them as governed inputs with security consequences, not just project metadata.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Agentic AI Security Guide
What this signals
Trust transitivity is the hidden failure mode: Coding assistants do not need to be fully autonomous to become dangerous. If they can act on content merely because it appears inside the developer workflow, then repository artefacts inherit execution authority by proximity. That is a governance problem for agentic tooling, not just a content-moderation problem.
Developer programmes should assume that prompt injection will arrive through ordinary software-maintenance paths, not exotic malware. The control question shifts to whether assistants can distinguish human-authored instructions from attacker-authored instructions before any file, command, or render step becomes actionable.
A practical programme response is to align assistant permissions with the narrowest trustworthy scope and to make outbound data movement explicit, reviewed, and logged. Where coding tools can inspect private code and invoke local utilities, the security boundary must follow the assistant’s tool chain rather than the user interface.
For practitioners
- Classify repository content as untrusted input Review how coding assistants ingest README files, issue text, docs, and comments, and treat each as a potential instruction source rather than passive context.
- Move enforcement below the model layer Apply command, file, and network controls at the tool execution layer so the assistant cannot bypass policy by reinterpreting instructions inside its prompt.
- Audit compound tool paths for exfiltration Map sequences where file read, secret discovery, and outbound rendering or network-capable actions can be chained into one data-loss path.
- Restrict assistant access to high-value workspaces Limit which repositories, local directories, and connected services the coding assistant can inspect so a compromised prompt cannot roam across sensitive projects.
- Separate approval for data-moving actions Require explicit user confirmation for any tool that can export, render, or transmit data outside the current development boundary, even if the tool itself looks safe.
Key takeaways
- Hidden prompt injection can turn a routine repository file into a covert control channel for AI code assistants.
- The article shows that blocked commands, workspace search, and permitted output tools can be chained into one secret-exfiltration path.
- Security teams need governance around assistant inputs, tool permissions, and outbound egress, not just better prompt hygiene.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | The article shows malicious instructions hijacking assistant behaviour through hidden content. |
| ASI02 — Tool Misuse | The attack chains safe-looking tools into secret discovery and exfiltration. | |
| Recommendation — Harden agent goal handling so untrusted repository content cannot redirect task execution. Constrain tool permissions and inspect chained tool use for misuse paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The assistant acts as a governed non-human actor whose access to tools and data must be authenticated and bounded. |
| NHI-05 — Overprivileged NHI | The article centres on a machine actor with more workspace and tool access than the task requires. | |
| Recommendation — Apply strong identity and authorization controls to coding assistants before they access private workspaces. Reduce assistant scope to the minimum workspace and tool set needed for the coding task. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack includes secret discovery and data theft as core threat stages. |
| Recommendation — Map assistant compromise paths to credential access and exfiltration techniques in your detection logic. | ||
Key terms
- 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.
- Instruction Hierarchy: Instruction hierarchy is the order of authority a model applies when interpreting context, system prompts, role messages, and user input. When attackers can influence that hierarchy through templates or wrappers, they can steer behaviour without needing to change the model itself.
- Trust Transitivity: The risk that trust granted to one party is implicitly inherited by others through integrations, support channels, or delegated access. In practice, it means a compromise in one supplier or device class can extend into environments that were never directly breached.
- Tool Chain Abuse: Tool chain abuse happens when individually allowed tool calls are combined into an unauthorised outcome. Each call may look valid in isolation, but the sequence produces privilege escalation, data exposure, or destructive action that no single approval was meant to allow.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 5, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org