Unexpected shells, outbound network requests, or file changes immediately after opening a project are strong indicators that automatic execution is occurring. Another sign is finding .vscode/tasks.json entries with folder-open triggers in repositories that are not supposed to run anything on open.
What a failing IDE trust control looks like in practice
An IDE trust control is meant to keep untrusted workspace content from running as if it were trusted. When it is failing, the environment stops behaving like a gated editor and starts behaving like an execution surface. The clearest signs are side effects at project open, unexpected task execution, and repository content that can influence the IDE before a developer has meaningfully reviewed it.
One practical way to think about this is whether opening a repository changes system state. If a workspace can trigger shells, network calls, or file writes without an explicit user action, the trust boundary has already been weakened. That is especially concerning when the project contains automation metadata that is supposed to remain inert until reviewed.
A second sign is inconsistency between policy and observed behaviour. If a team believes a repository is non-executable on open, but JetBrains GitHub plugin token exposure shows tokens can still be influenced through crafted project content, the control is not preventing the kind of workspace-triggered action it was meant to block. In practice, that means trust decisions are being bypassed by plugin logic, workspace hooks, or auto-run features.
Workspace-triggered execution is the most important warning pattern
The strongest behavioural indicator is execution that happens immediately after open or load. Unexpected shells, outbound requests, or file changes are not normal editing activity, they are evidence that the IDE is allowing project data to drive execution. A repository that is supposed to be passive should not be able to produce observable side effects until the user deliberately approves them.
Another warning pattern is auto-run configuration hidden in files that are easy to overlook. For example, entries in Amazon Q MCP config vulnerability 2026 demonstrate how repository-controlled configuration can turn a trusted coding surface into an execution path. Even if the exact mechanism differs, the failure mode is the same: content in the workspace gains more authority than it should.
Signs that the trust model is weakening also include extensions or plugins that request broad access without clear user intent. Secrets in VS Code extensions 2025 is a reminder that the editor boundary is only as strong as the extensions and automation it allows to run inside it. Once those components can read, transform, or exfiltrate sensitive material, trust is no longer being enforced consistently.
What to verify before you call the control healthy
The first verification step is simple: open an untrusted project in a controlled environment and confirm that nothing executes until a user grants explicit permission. Trust controls should suppress folder-open triggers, task auto-run, and similar workspace events by default. If a project can still trigger activity, the control is not doing its core job.
Next, inspect the repository for configuration that can override user expectations. Files such as .vscode/tasks.json, launch settings, extension recommendations, and workspace-specific automation should be treated as part of the trust surface. If those files can cause action on open, the issue is not just a bad project, it is a control gap in how the IDE interprets project trust.
A healthy control also leaves a trail. You should be able to explain why a workspace was trusted, which actions were permitted, and where exceptions were granted. If there is no durable record, it becomes impossible to distinguish legitimate developer behaviour from silent policy bypass.
Risk and Threat Considerations
When IDE trust controls fail, the main risk is that a developer workstation becomes an execution foothold for repository-delivered content. That can expose source code, cloud credentials, tokens, and downstream systems, especially when the IDE can invoke shells or automation on open without a meaningful approval step.
Failure mechanism: Workspace metadata, extensions, or trusted-project assumptions trigger commands or network activity before the user has validated the repository, allowing attacker-controlled content to act with local developer authority.
Impact: Attackers can steal secrets, modify files, plant persistence, or pivot into developer tooling and cloud accounts, turning a single project open into a broader compromise path.
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 API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | IDE trust failures can expose tokens and secrets through project-triggered execution. |
| NHI-04 — Insecure Authentication | Untrusted IDE actions can misuse valid tokens or sessions to act as the developer. | |
| NHI-10 — Human Use of NHI | Developer IDEs often let humans trigger non-human credentials and automation indirectly. | |
| Recommendation — Rotate exposed credentials and block workspace-driven secret exfiltration paths. Require explicit approval before the IDE can invoke authenticated actions. Separate human approval from machine-credentialed workspace automation. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | IDE trust failures often stem from unsafe workspace or plugin configuration. |
| Recommendation — Harden workspace and extension settings to prevent auto-execution on open. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Unexpected shells after opening a project indicate command execution from workspace content. |
| Recommendation — Hunt for workspace-triggered command execution and isolate the affected host. | ||
Practitioner Guidance
What to verify: Treat any open-time shell, network call, or file write as a control failure unless it is explicitly expected and documented. Validate that untrusted repositories cannot trigger tasks, launch profiles, or extension actions by default.
What good looks like: A secure IDE trust posture requires a clear separation between viewing code and executing code. The workspace should remain inert until the user intentionally marks it trusted or approves a specific action.
Common mistake: Teams often check whether the editor is “prompting” users, then assume the control is working. Prompts are not enough if the prompt can be bypassed, suppressed, or ignored while execution still occurs.
Practitioner takeaway: If opening a repository changes system state, the trust boundary has already failed, and the response should focus first on stopping implicit execution, then on reviewing any secrets or credentials that may already have been exposed.
Related resources from NHI Mgmt Group
- What are the signs that trust prompts are failing as a security control in agentic development tools?
- What are the signs that Exchange Online PowerShell access is failing because of identity or session control issues?
- What are the signs that a control environment is failing in practice?
- What are the signs that healthcare segmentation is failing to control east-west traffic?