Malicious behavior that starts when a folder or repository is opened in an editor or AI coding tool. The danger is that no explicit install or user action is required. Attackers use project files and workspace settings to trigger code under the developer’s own permissions and tooling context.
Expanded Definition
Project-Open Execution refers to a class of supply chain and development-environment abuse where malicious logic is triggered simply by opening a project in an editor, IDE, or AI coding tool. Unlike traditional malware delivery, the trigger happens through workspace metadata, task files, extensions, hooks, templates, or other project-scoped instructions that execute in the developer’s own context. The practical risk is that the malicious action blends into ordinary workflow and can appear to be a normal project action rather than a security event.
This term sits close to adjacent ideas such as malicious repository content, auto-run abuse, and trusted workspace misuse, but the defining feature is the open event itself. The attack path is especially relevant in environments where editors interpret project instructions automatically, or where developer tooling can launch scripts, fetch dependencies, or invoke agents without strong user friction. Definitions vary across vendors because no single standard governs this yet, so NHIMG treats the term as an execution-trigger model rather than a specific malware family. For broader governance context, the NIST Cybersecurity Framework 2.0 is useful for mapping the protections around software environments and access paths.
The most common misapplication is assuming a project is safe because no installer, macro, or explicit launch prompt was used, which occurs when teams overlook editor-level automation and repository-scoped execution triggers.
Examples and Use Cases
Implementing defenses against Project-Open Execution rigorously often introduces friction in developer workflows, requiring organisations to weigh automation speed against tighter inspection and execution controls.
- A repository includes workspace settings that cause an IDE to run a script when the folder is opened, giving the attacker code execution under the developer’s account.
- An AI coding tool reads project instructions on open and follows a hidden task to pull a remote payload or modify files without a separate install step.
- Build or test hooks embedded in the project fire automatically when the workspace loads, turning a routine clone-and-open action into an execution event.
- Malicious editor extensions or configuration references are bundled with the project so that trust in the repository transfers to the tooling environment.
- Open-source contributor workflows are abused when maintainers preview a fork in a trusted environment and the folder-open action activates unsafe commands.
These cases are closely related to secure-by-default workspace handling and software supply chain hygiene. Guidance from sources such as OWASP’s LLM guidance and CISA’s secure development resources helps teams think about untrusted inputs, execution boundaries, and developer trust decisions. The key operational question is whether opening content should ever be enough to trigger code paths that alter the host, the repository, or connected services.
Why It Matters for Security Teams
Project-Open Execution matters because it collapses the distance between review and compromise. Security teams often focus on signed packages, dependency integrity, or explicit command execution, yet this pattern exploits the assumptions behind day-to-day developer trust. In practice, the danger is not only malware execution but also credential exposure, source tampering, and downstream contamination of CI/CD pipelines and shared codebases. For organisations using AI-assisted development, the impact can extend to prompt injection-like behavior where project content manipulates agentic tooling into taking actions the user did not intend.
From a governance standpoint, teams need controls that treat project files as potentially executable inputs, especially in environments that automatically parse tasks, run setup steps, or grant broad workspace permissions. NIST-oriented risk management helps here, but the key is operational discipline: restrict auto-run behavior, sandbox untrusted workspaces, and separate review from execution. Developers and platform teams typically encounter the full cost only after a benign-looking repository open event leads to credential theft, unexpected network calls, or poisoned code changes, at which point Project-Open Execution becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access and execution paths should be limited to authorized users and trusted contexts. |
| OWASP Agentic AI Top 10 | Covers agentic tooling risks where instructions in project content can cause unintended actions. | |
| NIST AI RMF | Supports governance for AI system misuse when tools act on malicious project instructions. |
Restrict workspace auto-run behavior so opening untrusted projects cannot trigger privileged actions.
