What breaks when IDE extensions are allowed broad workspace and shell permissions?

Why This Matters for Security Teams

IDE extensions sit at a dangerous intersection: they can read source code, inspect workspace files, invoke shell commands, and often reach secrets stored in local configs or developer tooling. That makes broad permissions more than a convenience issue. They become a privilege boundary problem, especially when the extension is signed, trusted, and installed by default across teams. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG research both point to the same pattern: once a tool can act on behalf of the developer, it needs the same scrutiny as any other non-human identity.

The real risk is not only malicious code. A legitimate extension can be updated, compromised, or misconfigured and still expose code, secrets, and build artifacts. NHIMG has documented how broadly accessible credentials and developer tooling accelerate secret exposure, including in the Ultimate Guide to NHIs — Key Challenges and Risks. When shell access is included, the extension is no longer just observing the workspace; it is participating in execution.

In practice, many security teams encounter extension abuse only after a secret has been copied, a repository has been modified, or a command has already run, rather than through intentional review of extension permissions.

How It Works in Practice

Broad workspace and shell permissions collapse three distinct controls into one trust decision: file access, command execution, and identity context. A safe design should separate those concerns. Workspace access should be limited to the minimum folders required. Shell execution should be explicitly approved per command class, not granted as a blanket capability. Any extension that handles credentials should be treated as an NHI consumer and subject to the same lifecycle discipline described in JetBrains GitHub plugin token exposure.

Practitioners should assume that an extension with broad access can chain actions: read .env files, inspect Git metadata, run package managers, and exfiltrate tokens through a normal outbound request. That is why current best practice is evolving toward least-privilege extension models, scoped workspace trust, and policy-based command approval. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports limiting privileged functions and monitoring high-risk execution paths.

• Restrict extensions to known projects and specific folders instead of full-workspace access.
• Deny shell execution by default and require explicit per-action approval for high-risk commands.
• Separate read-only analysis from write or execute capabilities.
• Review what secrets managers, environment files, and Git credentials are reachable from the extension context.
• Log extension prompts, command invocations, and unusual file access for later review.

These controls tend to break down in fast-moving developer environments where teams install many extensions ad hoc and cannot reliably track which one has shell access because the permission model is inherited from convenience rather than explicit risk review.

Common Variations and Edge Cases

Tighter extension permissions often increase developer friction, requiring organisations to balance productivity against containment. That tradeoff is real, especially in monorepos, remote development sessions, and AI-assisted coding workflows where extensions need broader visibility to be useful. Current guidance suggests that the right answer is not zero functionality, but explicit scoping and stronger policy boundaries around the riskiest actions.

One edge case is teams that rely on extensions for refactoring, test generation, or dependency management. Those tools may legitimately need write access, but they still do not need unrestricted shell access or full repository visibility. Another edge case is the use of AI-powered IDE assistants. Their prompt context can unintentionally include secrets, config values, and internal code paths, so workspace scope alone is not enough. OWASP guidance for non-human identities and agentic tooling is still evolving here, so organisations should treat current recommendations as operational guidance rather than universal standard.

For teams building policy, the safest default is deny, then grant by use case. In practice, that means separating extensions by trust tier, requiring review for elevated permissions, and revoking access when the extension is no longer active. Security teams that align this model with NHI governance reduce the chance that a convenience tool becomes an unmonitored execution path.

Related resources from NHI Mgmt Group

• What breaks when a development IDE can inherit broad workspace permissions through MCP?
• What are MCP Authorization Extensions and how do they help organizations?
• How should security teams manage permissions for AI agents?
• Why is defining permissions important for AI agents?