AI coding assistants inherit workstation privileges through extension abuse

At a glance

What this is: This research shows that AI coding assistants can inherit full workstation privileges through extension abuse, letting injected JavaScript modify the IDE, persist across restarts, and access local files.

Why it matters: It matters because developer IDEs are now part of the control plane for code, secrets, and credentials, so workstation trust assumptions directly affect IAM, PAM, NHI, and software supply chain risk.

Context

AI coding assistants change the trust boundary of the developer workstation because they run inside Electron and Node.js contexts that can execute code with broad local privileges. Once untrusted extension content, MCP input, or injected JavaScript reaches that context, the IDE stops being just an editor and becomes a privileged runtime.

For IAM and NHI programmes, the governance issue is not only access to source code. It is the way workstation-level privilege, extension trust, and developer credentials combine to create a broader blast radius across repositories, vaults, and connected systems. That makes extension governance and execution control part of identity security, not just endpoint hygiene.

Key questions

Q: What breaks when an AI coding assistant can run untrusted extensions or MCP inputs?

A: The main failure is that the assistant no longer behaves like a bounded productivity tool. Once untrusted code reaches the Electron and Node.js runtime, it can inherit workstation privileges, alter the IDE, persist after restart, and reach files or credentials that were never meant to be exposed to third-party logic.

Q: Why do AI coding assistants create more risk than a standard IDE?

A: They can move code off the local machine, call external tools, and act on instructions with limited human review. That combination turns an editor into an execution environment with identity, data, and supply-chain implications. Security teams should govern the workflow, not just the application package.

Q: How can security teams tell whether an AI coding assistant is behaving outside its trusted boundary?

A: Look for changes in bundle hashes, unexpected extension installs, writes in IDE directories, and traffic to unfamiliar domains from the workstation. Those signals suggest the editor has crossed from normal user tooling into a persistent execution environment that can modify its own behaviour.

Q: How should organisations respond when developer tooling can access secrets and release credentials?

A: Treat the tooling as a privileged non-human identity and reduce its access to the minimum required for the workflow. Separate build, publish, and signing permissions, rotate credentials aggressively, and monitor for unusual dependency or package activity. If the tooling can ship code, it can also become a supply-chain attack path.

Technical breakdown

Why Electron-based coding assistants inherit local privileges

Cursor and similar AI coding assistants sit on top of Electron and Node.js, which means the IDE can expose native file-system and process-level capabilities to code running in the application context. If malicious JavaScript reaches that runtime through an extension, MCP server, prompt, or rule, it can immediately operate with the same privileges as the IDE. That is fundamentally different from a browser sandbox, because the application is already trusted to interact with local resources. The result is that a small injection point can become a full workstation execution path.

Practical implication: Treat the IDE runtime as privileged software and restrict what can execute inside it.

How extension abuse becomes persistence and lateral movement

A malicious extension does not need a separate exploit chain once it can modify the IDE state. It can alter installed extensions, write files, and persist code so the payload reattaches after restart. Because AI coding assistants also handle prompts and third-party components from outside the normal software inventory, the workstation becomes a distribution point for further compromise. That matters for lateral movement because developer machines often hold repository access, cloud credentials, and paths into build and deployment systems. The attacker does not need to remain inside the editor if the editor can already reach everything else.

Practical implication: Monitor extension installation, bundle integrity, and unexpected writes in IDE directories.

Why unvetted MCP servers and prompts widen the supply chain attack surface

The article frames MCP servers, extensions, prompts, and rules as parallel entry points into the same privileged execution environment. That widens the software supply chain because developers now import executable logic and behaviour from more places than a curated extension store. Traditional security review assumes discrete packages and predictable update paths, but AI coding assistants let external instructions shape runtime behaviour in a more fluid way. The security problem is therefore not just malicious code, but trusted tooling absorbing untrusted instructions that can alter the development environment itself.

Practical implication: Validate third-party assistant inputs and components with the same scrutiny you apply to build dependencies.

Threat narrative

Attacker objective: The attacker aims to turn the developer workstation and IDE into a persistent execution foothold for stealing data, modifying tooling, and reaching adjacent systems.

1. Entry occurs when a malicious extension, MCP server, or poisoned prompt reaches the AI coding assistant runtime inside the Electron and Node.js IDE.
2. Credential and control abuse follows because the injected JavaScript inherits the IDE's local privileges and can read files, alter extension state, and persist code.
3. Impact is workstation takeover, with the IDE becoming a malware distribution and exfiltration platform that can also support lateral movement into connected systems.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Amazon Q MCP config vulnerability 2026: A malicious .amazonq/mcp.json in a repository could make Amazon Q run commands with a developer's AWS credentials. Fixed before disclosure.

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

Extension trust has become an identity problem, not just an endpoint problem. Once an AI coding assistant accepts unvetted extensions, prompts, or MCP inputs, it can inherit the workstation privileges that protect source, secrets, and build access. That means the security boundary now sits at the point of code and instruction ingestion, not just at the operating system. Practitioners should treat assistant inputs as governed identity-bearing artefacts, not harmless productivity add-ons.

IDE privilege now creates a wider NHI and human credential blast radius. Developer workstations often hold tokens, SSH keys, cloud sessions, and repository access that belong to both humans and non-human workflows. A successful injection can therefore pivot from the assistant runtime into NHI secrets, repo write access, and deployment paths without ever leaving the workstation. The control gap is not a missing alert, but a workstation assumed to be safely trusted after a single local approval.

Workbench integrity is the named failure mode this class exposes. The article shows that checksum tampering, extension modification, and restart-persistent code can defeat the assumption that an IDE remains what the user installed. That is a software supply chain issue, a runtime trust issue, and an identity issue at once because the compromised editor acts with the developer's privileges. Practitioners should design controls around verified bundle integrity and tightly scoped extension authority.

Prompt, extension, and MCP governance must converge. Organisations cannot manage these inputs as separate controls because the attacker only needs one path into the shared runtime. This aligns with broader NHI governance concerns: when tooling can import executable behaviour from outside the approved estate, the identity of the tool itself becomes part of the threat model. Security teams should consolidate review, provenance, and runtime monitoring around the assistant environment as a single governed surface.

Attackers benefit from developer-side trust shortcuts. The article makes clear that users are nudged toward installing, updating, and restarting tools that are assumed to be safe. That user journey creates the same kind of trust exploitation seen in other social and supply chain attacks, but with much higher operational privilege. The practical implication is that security teams need approval gates and integrity checks before execution, not after compromise.

From our research library:

• Developers using GenAI tools like GitHub Copilot are reporting 35% productivity gains, according to IDC’s 2024 Generative AI Study.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Workbench integrity is now part of identity governance. When an AI coding assistant can modify its own bundles, the organisation loses confidence that the runtime still matches the approved control state. That is why bundle verification, extension provenance, and execution approvals belong in the same governance conversation as secrets handling and privileged access.

Adoption teams should expect assistant risk to spread from productivity tooling into repository access, cloud credentials, and build pipelines. In practice, the most useful programme response is to govern the assistant as a privileged endpoint with identity-aware controls rather than as a standard developer application.

Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025. Even when the article focuses on workstation takeover, that figure reinforces the broader point that AI-assisted developer workflows can amplify secret exposure when trust boundaries are weak.

For practitioners

• Harden extension and MCP approval paths Require explicit allowlisting for IDE extensions, MCP servers, prompts, and rules that can execute code or alter behaviour in the assistant runtime.
• Verify bundle integrity before every update Track checksums for workbench bundles and product files, and alert when the IDE package changes outside a trusted update flow.
• Monitor for workstation-level persistence signals Watch for unexpected writes in IDE directories, modified extension state, and restart-persistent code that survives application relaunch.
• Scan for exposed secrets in developer environments Search IDE configuration files, extensions, and local workspaces for tokens, API keys, and SSH material that could be harvested after injection.
• Separate assistant trust from developer trust Apply minimum necessary permissions to AI coding assistants so that a compromised extension cannot reach broader workstation, repo, or cloud access.

Key takeaways

• AI coding assistants can inherit workstation privileges through extension abuse, so the real control problem is runtime trust, not just extension hygiene.
• The attack path matters because untrusted code inside Electron or Node.js can persist, modify the IDE, and reach local files or credentials.
• Security teams should govern assistant inputs, verify bundle integrity, and reduce privileges available to the IDE before compromise creates a wider identity event.

Key terms

• Electron Runtime: Electron runtime refers to an application framework that combines browser rendering with Node.js capabilities. In security terms, it can blur the line between UI code and local system access if isolation is weak, which is why desktop apps built this way often inherit browser-style and workstation-style attack surfaces at the same time.
• Workbench Integrity: Workbench integrity is the assurance that an IDE's core bundle files, UI logic, and extension state have not been altered outside an approved update path. When that integrity fails, attackers can persist code, change the interface, and keep control across restarts.
• Extension provenance: Extension provenance is the trust history behind a browser add-on, including who published it, how it is updated, and whether it was sideloaded. In practice, it determines whether the extension should be treated as managed software or as an ungoverned supply-chain dependency.
• Workload Blast Radius: The amount of data, systems, and business processes a workload can reach if its permissions are misused or compromised. In GenAI environments, blast radius is determined by entitlement scope, connected services, and how much sensitive information the workload can process or influence.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in modern environments. It helps practitioners apply identity controls to developer tools, AI assistants, and the workflows that sit between code and production.