Cursor security issues expose the IDE as an execution environment

At a glance

What this is: Pluto Security argues that AI-assisted coding environments turn the IDE into an execution surface, not just an editor, and that this creates security blind spots around generated code, commands, and dependency changes.

Why it matters: IAM, PAM, and NHI teams should care because AI coding tools change where trust is granted, how execution is triggered, and what activity can be governed before it reaches normal security controls.

By the numbers:

• Pluto is officially out of stealth, with $42 million in total funding.

Context

AI-assisted coding is shifting control points out of the repository and into the developer workstation, where generated code, dependency changes, and shell commands can be created and executed before central controls see them. That creates a governance gap for security teams because the old SDLC assumptions no longer match the way work actually happens in the IDE.

This is also an identity and access problem, not just a development workflow issue. When an assistant can suggest actions that a developer executes locally, the real control question becomes who or what is allowed to initiate change, under what context, and with what visibility into AI coding agents security.

Key questions

Q: How should security teams govern AI coding assistants that can execute commands?

A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: What are the signs that an AI coding agent is crossing from helpful automation into unsafe execution?

A: Look for command execution that does not match the visible approval, file writes outside the intended workspace, unexpected skill or MCP server installation, and autonomous changes to config or database targets. A second warning sign is when the agent starts resolving names from sources you did not explicitly trust. Those patterns indicate the agent is acting on manipulated context.

Q: How should organisations balance developer productivity with control over AI coding assistants?

A: The right balance is observability plus guardrails, not blanket restriction. Keep AI assistance available for drafting and refactoring, but constrain execution, review dependency changes, and monitor the endpoint where the work actually happens. That preserves velocity while closing the gap between suggestion and sanctioned change.

Technical breakdown

Why AI-assisted coding collapses traditional SDLC control points

Traditional SDLC controls assume work moves through distinct stages such as design, build, test, and deploy. AI-assisted coding compresses those stages inside the IDE, where code can be generated, edited, and executed in one session. That means review and policy enforcement no longer sit naturally at the same boundary as the action itself. The security impact is not just faster development, but weaker observability over how code and commands entered the environment. Practical implication: treat the IDE as part of the controlled software supply chain, not as a neutral authoring tool. See the AI Security Maturity Model.

Practical implication: Move governance earlier, into the workstation and IDE workflow, instead of relying only on repository and pipeline controls.

Why trusted commands create a new execution risk

AI coding tools can suggest shell commands, dependency installs, and configuration changes that look contextually correct even when they are unsafe. The risk is amplified because developers may treat the suggestion as authoritative and run it locally, outside the normal monitoring path. This is a command execution problem, but also a trust problem: the assistant is influencing privileged development actions without being a governed identity in the classic sense. Practical implication: separate suggestion from execution and require explicit scrutiny before any AI-proposed command is run.

Practical implication: Require explicit human confirmation and logging for any AI-suggested command or dependency action.

Why dependency drift becomes harder to detect in AI-assisted workflows

When an assistant introduces new libraries, package versions, or hidden transitive dependencies, the risk is not only code quality but supply chain expansion. Teams often monitor source control and CI/CD, but the dependency decision may have already been accepted inside the IDE before those controls see it. That creates a blind spot between local intent and downstream build integrity. Practical implication: dependency governance must start in the coding environment and not wait for build-time detection alone.

Practical implication: Lock dependency changes to reviewable workflows and scan for transitive additions as soon as they are proposed.

Threat narrative

Attacker objective: The attacker wants to influence trusted development activity so that unsafe code, commands, or dependencies are executed as part of ordinary work.

1. Entry occurs through the developer’s trusted AI-assisted coding workflow, where prompts can steer code generation or command suggestions inside the IDE.
2. Credential or execution abuse follows when the developer accepts a suggested command, dependency install, or configuration change without independent verification.
3. Escalation happens because local execution occurs outside normal enterprise monitoring, allowing malicious or faulty actions to blend into legitimate development work.
4. Impact is the introduction of insecure code, hidden dependencies, or compromised developer environments that can later affect build and production systems.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

Cursor security issues are really governance issues about where execution authority lives. The core failure is not that AI-assisted coding exists, but that organisations are still treating the IDE like a drafting surface instead of an execution environment. Once commands and code changes can be proposed and acted on in the same place, conventional SDLC gatekeeping becomes too late. Practitioners need to decide where authority is granted, logged, and reviewed before the IDE becomes the de facto control plane.

Trusted commands create a new class of privilege drift inside development work. The problem is not limited to malicious prompts; it is that human developers begin to delegate judgment to the assistant and then execute the output locally. That creates a governance gap similar to over-broad access in other identity systems, except the “identity” here is the assistant influencing action. Organisations should map this to agentic AI policy and treat command suggestion as a controlled privilege, not a convenience feature.

AI-assisted coding exposes a visibility gap that mirrors the worst NHI failures. In both cases, the dangerous action happens outside the controls most teams monitor, which means the issue is not detection after the fact but lack of issuance-time governance. That makes this a useful bridge case for identity teams: the control question is who can act, what they can trigger, and how those actions are bounded before execution. Practitioners should align IDE governance with the same rigor used for high-risk non-human access.

Dependency changes made through AI suggestions should be treated as supply chain events, not just developer preferences. A suggested library or version may look minor in the moment, but it can expand the trusted software base and introduce hidden transitive risk. Security teams that only review the repository after the fact are already behind. The better model is to govern dependency intent where it first appears, then validate it through build and runtime controls.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Coding Agents Security Guide

What this signals

Developer-endpoint governance is becoming the missing layer in software supply chain control. Security teams that only watch repositories and CI/CD pipelines will continue to miss the highest-risk decisions because AI-assisted coding shifts action into the local IDE. That means the next control plane is the workstation itself, where command suggestion, dependency selection, and execution all converge.

Cursor-style workflows are pushing identity governance into the development lifecycle. The important question is no longer only what code was written, but what authority was exercised to generate and run it. Teams that already manage NHI, privileged access, and agent oversight should extend those governance patterns to AI-assisted development before the workflow normalises hidden execution.

Behavioural monitoring will matter more than static policy if AI coding becomes the default workflow. Policy files and review gates help, but they do not close the gap if local execution remains invisible. The practical signal to watch is whether assistant-driven actions are being logged, correlated, and challenged before they become part of the build path.

For practitioners

• Define the IDE as a governed execution environment Add AI-assisted coding tools to the organisation’s software supply chain and threat models, including local workstation activity and command execution paths.
• Require human approval for AI-suggested commands Block unattended execution of shell commands, dependency installs, and configuration edits that originate from assistant prompts.
• Lock dependency changes to reviewable workflows Treat package additions, version bumps, and transitive dependency drift as security-relevant changes that must be reviewed before merge.
• Instrument developer endpoints for behaviour monitoring Collect endpoint telemetry for unusual command patterns, local script execution, and IDE-to-repository correlation so that unsafe automation is visible.
• Train developers on AI trust boundaries Make it explicit that model outputs are probabilistic suggestions, not authoritative instructions, and require scrutiny before any execution step.

Key takeaways

• AI-assisted coding changes the security problem from code generation alone to governed execution inside the IDE.
• The visibility gap matters because key decisions now happen before repository and pipeline controls can inspect them.
• The most effective response is to combine endpoint observability, command guardrails, and dependency review discipline.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · LLM Security Guide · Agentic AI Security Policy Template · LiteLLM PyPI package breach

Key terms

• AI-assisted coding: The use of a language model or coding assistant to generate or modify software code with human guidance. It increases speed, but it also creates a trust problem because the output can look correct while hiding insecure logic, unsafe defaults, or poor handling of credentials and access paths.
• Trusted Command: A command proposed by an AI assistant that a developer is likely to accept because it appears contextually relevant and useful. In security terms, this is risky because the suggestion can become executed action without the same scrutiny applied to a manually authored change.
• Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
• IAM Attack Surface: The IAM attack surface is the total set of identity-related points where an attacker can try to gain access, change privileges, or impersonate users and workloads. It includes accounts, credentials, tokens, policies, federation paths, admin consoles, APIs, and misconfigurations across cloud, applications, endpoints, and directories.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions now appearing in AI-assisted development workflows.