TL;DR: A malicious .junie/guidelines.md file could be treated as user-level instructions in CVE-2026-41153 in JetBrains Junie, enabling background command execution and proof-of-concept exfiltration of a .env file without expected human approval, according to Mindgard. The case shows that AI coding agents collapse the boundary between project guidance and runtime action unless workspace content is treated as hostile.
At a glance
What this is: Mindgard says CVE-2026-41153 let a malicious project guidance file in JetBrains Junie trigger command execution and secret exfiltration through an AI coding agent.
Why it matters: This matters because AI-assisted IDEs now sit inside the developer trust boundary, so project files, approvals, and tool execution need governance that assumes untrusted workspace content.
Context
AI coding assistants change the meaning of a project file. What used to be documentation or local configuration can become an instruction source that shapes tool use, command execution, and file access inside the developer’s environment. When that environment also holds source code, secrets, and deployment access, the security boundary is no longer just the IDE. It is the agent’s interpretation of workspace content.
This vulnerability sits in the trust gap between project-supplied instructions and user-approved actions. A malicious repository can exploit that gap if the agent treats workspace guidance as authoritative enough to trigger background work or terminal activity. That makes agentic AI security directly relevant, because the problem is not only code execution but the control model around AI-mediated action.
Key questions
Q: What breaks when project prompt files can change an AI coding assistant's behaviour?
A: The trust boundary breaks down. A repository file can quietly alter what the assistant believes it is allowed to do, so security controls that focus only on user prompts miss a persistent policy layer that can authorise harmful behaviour across every future session.
Q: Why do AI coding environments create more secret exposure risk than standard developer tools?
A: They can inspect repository context, read dotfiles, and infer where credentials are stored, then act on that information through commands or file changes. That means secrets can be exposed both by reading them and by persisting changes that keep access alive. Teams should assume workstation-local state is part of the secret attack surface.
Q: How can security teams stop background commands from bypassing approval controls?
A: They need to bind approval to every execution path, not just the obvious prompt flow. That means testing whether the agent can launch terminal activity, background work, or file access without an explicit confirmation step, and then constraining those paths so repository content cannot silently escalate into action.
Q: Should organisations treat AI coding agents like privileged software identities?
A: Yes. If an AI agent can install code, access secrets, or modify repositories, it is functionally acting as a privileged non-human identity and should be governed that way. That means task-scoped access, explicit boundaries, and monitoring of its downstream actions, especially when it can touch build and release systems.
Technical breakdown
How project guidance became an execution channel
Junie reads a project-local guidelines file and treats its content as additional user-level instruction. That design is useful when the file contains benign project preferences, but it becomes dangerous when repository-controlled text can influence agent decisions. In this case, a malicious .junie/guidelines.md file could instruct the agent to run a shell command in the background. The key mechanism is instruction inheritance: content from the project is elevated into the agent’s decision context, then acted on through terminal tooling. Once that happens, the agent is no longer just summarising or suggesting. It is executing within the developer session. See the Agentic AI Security Guide.
Practical implication: Treat any repository-supplied instruction channel as hostile until it is explicitly constrained to non-executable guidance.
Why human-in-the-loop checks failed to contain the action
Human approval controls only work when every execution path is routed through them. Mindgard’s finding shows that background command execution can bypass the expected read-only and confirmation checkpoints when an AI agent resolves a prompt into an action on its own. That is an agent governance problem, not just a UI issue. The risk appears when the model can infer that a hidden command is part of the task and then use available tooling to carry it out. In practical terms, the approval boundary must govern both foreground and background operations, not only the obvious user-facing prompts.
Practical implication: Verify that approval controls bind to all agent-mediated execution paths, including background and terminal actions.
Why developer environments turn a small flaw into a broad blast radius
AI-assisted IDEs sit next to credentials, package managers, build systems, and deployment workflows. That proximity matters because a successful command execution in the IDE can reach files, tokens, and systems that a developer can access. Mindgard’s proof of concept used a project file to exfiltrate a .env file, which demonstrates the path from instruction abuse to secret exposure. The architectural issue is that developer tools now combine content interpretation, automation, and execution in one place. Once workspace content can steer those capabilities, the blast radius extends far beyond the editor itself.
Practical implication: Assume an IDE compromise can become a credential and pipeline compromise, not just a local workstation issue.
Threat narrative
Attacker objective: The attacker wants to turn repository content into unauthorized command execution and steal sensitive development secrets from the victim environment.
- Entry occurred when a malicious repository supplied a project-local .junie/guidelines.md file that Junie accepted as additional instruction content.
- Credential access followed when the agent used terminal tooling to read a project .env file and send its contents to an attacker-controlled endpoint.
- Impact was secret exposure from a developer environment, with the malicious instruction path bypassing the expected human approval check.
Breaches seen in the wild
- JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
- JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
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 IDEs have crossed from documentation readers into action systems, and that changes the security model. Once a project file can influence tool use and command execution, the control question is no longer whether the file is trusted enough to open. It is whether the agent has been allowed to convert workspace content into runtime authority. That is a classic trust-boundary failure in a new form, and it demands policy around what repository content can ever become executable.
The specific failure mode here is instruction inheritance without execution isolation. Project-supplied guidance was allowed to shape agent behaviour in a way that could trigger background commands and suppress the expected approval moment. That is the governance gap the article exposes: semitrusted content was not kept semantically separate from user intent. Security teams should treat that as a control design problem, not a narrow product defect.
This is also an NHI governance issue because the agent functions as a non-human identity with delegated tool access. When the agent can inspect files, run commands, and act on repository content, it needs scope limits similar to any other privileged workload identity. The relevant question is not whether the assistant is useful, but whether its authority is bounded to the task and the workspace it should touch. Agentic AI security becomes operational when these boundaries are explicit.
Command execution trust gap: the article illustrates how a project file can be promoted into an instruction source that overrides the operator’s expectation of a read-only workflow. That failure mode is increasingly common wherever AI tools interpret untrusted workspace content. Practitioners should define which inputs can shape actions, which can only inform suggestions, and which must never reach execution logic.
What this signals
AI-assisted development creates a new class of trust boundary problems: the question is no longer only whether code is safe, but whether project content can safely influence agent behaviour. Organisations that allow coding agents to interpret repository files need policy that separates guidance, suggestion, and execution. Without that separation, an ordinary project artefact can become an attacker-controlled control plane.
The practical lesson is that AI governance in developer tooling now overlaps with NHI governance. A coding agent with terminal access, file access, and network access functions like a delegated non-human identity, so its permissions and instruction sources need explicit lifecycle control. Teams should expect more incidents where the abuse path begins in workspace content and ends in runtime action.
Security programmes should also assume that secret management and IDE governance are now linked. If developers can open untrusted repositories in environments that contain production credentials, the blast radius of a single malicious instruction grows quickly. Control design has to move upstream, before the agent receives the content it will later interpret.
For practitioners
- Patch AI IDEs and agents to the fixed version Confirm that JetBrains Junie or any similar AI-assisted development tool is on a release that includes the December 2025 fix, and verify deployment across all developer endpoints.
- Block untrusted repositories from secret-bearing workspaces Separate casual repository review from environments that hold production credentials, environment files, or deployment access, so malicious guidance files cannot reach high-value secrets.
- Constrain repository-supplied instructions to non-executable guidance Review how project files are parsed by AI coding agents and ensure repository content cannot trigger shell commands, background tasks, or hidden execution paths.
- Audit approval paths for background execution bypasses Test whether human approval is enforced for both visible prompts and agent-mediated terminal activity, including actions initiated through indirect instructions.
- Treat IDE governance as part of application security Inventory AI coding assistants, plugins, and developer automation across the estate, then classify where they can read files, run commands, and touch secrets.
Key takeaways
- The article shows that AI coding agents can turn repository-supplied guidance into active command execution if instruction channels are not tightly controlled.
- The proof of concept reached a sensitive .env file, which demonstrates how quickly a workspace-level flaw can become secret exposure.
- The most effective limit is not just patching, but separating untrusted project content from approval-gated execution paths and secret-bearing environments.
Related NHI Mgmt Group resources: Agentic AI Security Guide · Attack Surface Management Guide · JetBrains GitHub plugin token exposure · DeepSeek database exposure 2025
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 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on an AI agent accepting untrusted project input as actionable authority. |
| NHI-10 — Human Use of NHI | The agent acted on behalf of the user inside a developer workspace and could execute commands. | |
| Recommendation — Constrain AI agent trust boundaries so repository content cannot alter execution without explicit authorization. Separate user intent from agent action and require approvals before the agent uses human context to act. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The abuse path used delegated agent authority and tool access to carry out unauthorised actions. |
| Recommendation — Limit agent privilege scope and block repository content from escalating into tool-enabled action. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The demonstrated chain accessed a .env file and sent its contents to an external endpoint. |
| Recommendation — Map agent abuse to credential access and exfiltration so detections focus on file theft and outbound leakage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is fundamentally about whether the agent had excess authority over files, commands, and secrets. |
| Recommendation — Review entitlements for AI development tools and remove any permissions not required for the task. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Instruction inheritance: The practice of loading persistent project instructions into an AI assistant’s working context so they shape future behaviour. In this article’s context, inherited instructions can become a durable control layer, which means a repository file may influence authorisation outcomes long after it was edited.
- Human-in-the-Loop Controls: Human-in-the-loop controls are decision gates that require a person to approve, review, or override an automated action before it proceeds. They are used when speed matters but the impact is high, such as account blocking, endpoint isolation, or access revocation, to keep automation accountable and bounded.
- Developer Environment Blast Radius: The potential scope of damage when an issue in a developer workstation or IDE reaches source code, credentials, build systems, and deployment access. AI-assisted tools increase this blast radius when they can read files and execute commands in the same session.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security and identity teams build the control model needed when non-human actors can influence tools and execution.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org