Yes, because extensions can acquire and reuse non-human credentials that reach source code and secrets. Governance should cover who can install extensions, how session reuse is controlled, and how inherited access is revoked. If the tool can act through a shared identity, it belongs in the identity boundary.
Why VS Code extensions belong inside identity governance
VS Code extensions are not just local productivity add-ons. In many developer environments they can read tokens, reuse authenticated sessions, reach repositories, and interact with cloud or CI/CD services through the developer’s own standing access. That makes them part of the identity boundary whenever they inherit or act through credentials that can touch code, secrets, or deployment paths.
Once an extension can operate through a shared login, a cached browser session, or a developer token, the governance question changes from “is this tool useful?” to “what authority does this tool inherit, and who is accountable for that authority?” The practical test is whether the extension can amplify the user’s access without separate review, approval, or revocation controls.
Teams should treat this as an access-governance problem, not only a software supply-chain problem. The same control logic used for privileged accounts applies here: inventory what can reach production data, define who may install or approve extensions, and set explicit boundaries for where inherited access is allowed to flow.
What governance needs to cover in practice
Extension governance needs three decisions. First, installation control, because the extension itself becomes part of the trusted software set. Second, session and token handling, because many extensions can piggyback on an already authenticated developer context. Third, revocation, because disabling the tool or removing it from the marketplace does not automatically remove access it already obtained.
This is where the identity boundary becomes concrete. If a tool can inspect repository content, invoke APIs, or surface secrets from the editor context, the question is not whether the tool “is a user,” but whether it inherits user or service authority in a way that should be reviewed, logged, and time-bounded. That is the same governance pattern used when an application or automation consumes non-human credentials on behalf of a person.
For teams building policy, useful controls are the ones that map to actual access pathways: approved extension allowlists, environment-specific restrictions, high-risk publisher review, token scoping, and extension deprovisioning when a developer leaves or changes role. IAM and IGA Basics is a useful reference point for the broader access-governance model, while Access Reviews and Certification Guide shows how to make review programs actually remove access instead of rubber-stamping it.
Where the real failure modes appear
The main failure mode is authority leakage: a harmless-looking extension inherits more access than the team intended, then uses that access against source code, secrets, or downstream tooling. A second failure mode is persistence. If credentials are cached, reused, or refreshed automatically, the risk can survive long after the extension was installed or the original user action ended.
Another common failure is scope confusion. Developers often assume an IDE extension only touches the editor, but many extensions connect to remote services, telemetry endpoints, package registries, and internal APIs. That means a single extension can become a bridge between local workflow and privileged systems, especially when it is allowed to read environment variables, repository metadata, or authentication material.
Threat-wise, malicious or compromised extensions are attractive because they sit close to developer secrets and trusted workflows. Secrets in VS Code extensions 2025 and GlassWorm campaign 2025 both illustrate how extension ecosystems can expose publishing tokens, developer tokens, and follow-on access paths. GitHub internal repositories breach 2026 shows the downstream impact when a stolen token lets an attacker publish a poisoned extension and exfiltrate repositories.
What teams should do instead of treating extensions as personal preferences
Developer teams should manage extensions with the same discipline they use for other access-bearing tools. Start by defining which extension types are allowed in each environment, then separate low-risk productivity tools from tools that can reach source, secrets, build systems, or cloud consoles. Extensions that can see or reuse credentials should be reviewed like other access-bearing components, not installed on convenience alone.
Ultimate Guide to NHIs, Key Challenges and Risks is relevant because the same patterns show up here: visibility gaps, over-privilege, and unmanaged credentials. For operational sequencing, Lifecycle Processes for Managing NHIs is the right mental model for revoke, rotate, and offboard when an extension or related credential is no longer trusted.
Publishers should also verify that extensions are not a backdoor into high-value workflows. If an extension can read tokens, call APIs, or access CI/CD, require explicit justification, owner approval, and a clear removal path. If it cannot be observed, revoked, or scoped independently, it should be treated as a higher-risk access 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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Extensions may reuse tokens and sessions that need lifecycle control. |
| AC-6 — Least Privilege | Extension access should be constrained to the minimum authority needed. | |
| IA-9 — Service Identification and Authentication | Extensions can act through non-human credentials and shared service-like access paths. | |
| Recommendation — Inventory and rotate extension-related credentials, tokens, and cached authenticators on a defined schedule. Restrict extension permissions and block broad access to source, secrets, and cloud tooling. Use distinct non-human credentials for extensions and separate them from developer identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Manage identities and access privileges for users, devices, and systems | Extension installation and inherited access are identity and privilege governance issues. |
| Recommendation — Govern extension authority as part of identity and privilege management. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Extensions can expose or reuse tokens and other secrets inside the IDE. |
| Recommendation — Scan extensions for secret handling paths and block any that can expose credentials. | ||
Practitioner Guidance
What to prioritise: Focus first on extensions that can touch repositories, secret stores, cloud APIs, or build pipelines. Those are the ones most likely to create meaningful inherited access rather than simple editor convenience.
What to verify: Confirm whether an extension can inherit authenticated sessions, read environment variables, or reuse tokens without a separate review point. If it can, treat that as governed access, not just a developer preference.
Common mistake: Teams often review extension code quality but not extension authority. A safe-looking plugin can still be a high-risk access conduit if it operates inside a trusted, logged-in development context.
Practitioner takeaway: The key judgment is whether the extension can act with someone else’s authority; if yes, it belongs in the access inventory, the review cycle, and the revocation plan.
Related resources from NHI Mgmt Group
- Should organisations treat browser extensions as part of identity governance?
- Should identity teams treat proofing as part of access governance?
- How should teams assess risky VS Code extensions before allowing them on developer machines?
- Should organisations treat application authentication code as part of identity governance?