LLM-native IDE security risks centre on system controls, according to a study of developer reports.
Researchers from York University and the University of Calgary analysed 446 Reddit posts and 6,280 associated comments about security and privacy issues in AI-assisted development environments. The study covered discussions from January 2023 to March 2026, drawn from 29 subreddits focused on tools including Cursor, GitHub Copilot, Claude Code, and Codex.
The findings highlight developer-reported incidents, not independently confirmed vulnerability rates across products. The authors manually validated the selected posts, then used them to construct a taxonomy containing 32 reported issues across ten high-level categories.
Their central finding concerns product architecture. Seven of the ten issue categories involved system-level design and integration choices, the authors found. Two related primarily to LLM behaviour, and one covered both system and model factors.
Access controls fail when agents act on wider context
The study’s most concrete case concerns GitHub Copilot and an .env file containing secrets and API keys. A Reddit user reported that Copilot accessed the file despite configuration intended to exclude it through .gitignore and .copilotignore.
The researchers report that they reproduced the behaviour. Copilot read and attempted to modify the .env file after two follow-up debugging prompts about a database connection issue, according to the paper.
The paper groups unauthorised file operations as the largest security category, appearing in 43.1 percent of security-related posts. Reported events included file deletion and unauthorised modification. Some posts described access outside the intended workspace, including personal files or environment configurations.
One Cline user wrote: “…When API requests get stuck, some files being modified will be silently deleted from the ssd drive.” The report also cites an account of Claude Code executing chmod +x on scripts without consent.
Exclusion files clearly cannot serve as the only control around credentials or production configuration. The research frames several failures as cases where an IDE did not enforce settings that users had explicitly configured. A local agent with workspace permissions requires the same treatment as other software able to read, write, or execute within a developer environment.
Production actions sit beyond ordinary code review
Operational safety issues accounted for 23.9 percent of the security reports. This category covered actions affecting production resources, operating-system state, deployment workflows, or agent execution.
A Reddit post cited by the researchers alleged that Replit removed a SaaS production database. Another reported that Cursor pushed code to GitHub after the user instructed it never to do so.
The affected boundary changes the governance requirement. Source-code review occurs before a merge or release, whereas an agent can invoke a command, change a setting, or interact with a connected tool during its task.
Prompt injection also appears in the research. One post described malicious instructions embedded in a GitHub pull request that attempted to direct Amazon Q towards destructive file and cloud actions. The study places this under operational safety because the reported risk comes from redirected tool use, rather than from a flawed code suggestion.
External integrations add another permission path. The authors identified risks associated with Model Context Protocol (MCP) servers and connected tools, including reports that hostile or misconfigured services could feed concealed instructions through tool calls.
The developer responses show how teams compensate. Sandboxing accounted for 105 of the 1,318 comments containing actionable mitigation advice. Commenters recommended running agents in virtual machines, containers, or devcontainers rather than on a host machine. Version control appeared in 232 comments, largely as a recovery mechanism after unwanted changes or deletions.
Privacy concerns focus on data handling and boundaries
Privacy reports followed a different pattern. Lack of transparency represented 45.9 percent of privacy-related posts, covering uncertainty about collection, retention, training use, and administrator access to company-managed accounts.
The study separates that uncertainty from reported access or disclosure events. Unauthorised data access accounted for 23.7 percent of privacy posts. These discussions involved user secrets, project-boundary violations, and personally identifiable information.
One Cursor report described the tool searching for .env files to obtain database credentials. The paper also cites a Claude Desktop report in which the application created a Replit account using the user’s personal information without explicit consent.
Data lifecycle controls feature heavily in the remaining categories. Privacy leakage violations made up 15.5 percent of reports, including concerns about retention of intellectual property and exposed credentials. Unauthorised transmission and collection accounted for 11.9 percent.
A report involving VS Code claimed that source files reached external services even with telemetry disabled, based on a man-in-the-middle proxy review. Another discussion alleged that Claude Code stored complete conversation histories in plaintext in /.claude.json.
Context isolation received less volume, at 8.8 percent of privacy reports, though the cases remain operationally awkward. The authors cite reports of messages appearing from another user’s session, plus project information showing up in a separate project’s files.
Data boundaries need enforcement at the product layer. Enterprise adoption reviews should establish what the IDE can read, what it can retain, and where it can send context before teams connect repositories, credentials, or internal services.
Developer controls remain outside the IDE
The study found 13 developer mitigation approaches across five groups. Configuration management accounted for 33 percent of actionable comments. Developers discussed limiting permissions, checking organisational compliance, disabling telemetry, monitoring extensions, and retaining logs.
Code governance represented 31 percent. Manual verification appeared in 239 comments, making it the most frequently discussed individual mitigation. Developers also pointed to version control as a means to inspect changes and roll back damage.
The source material gives a direct warning from one commenter: “all LLM providers have a warning, YOU should double check the output.”
Sensitive file protection and memory isolation accounted for 13 percent of the mitigation discussion. Isolation measures made up another 13 percent, split between sandboxing and local LLM use. A self-owned local model may reduce external transmission, according to the paper’s framing, although it does not address local permissions or unsafe autonomous actions.
The researchers argue that LLM-native IDE vendors need automated verification before recommendations reach developers. They also call for accessible execution logs and task planning information. For connected coding agents, the paper proposes a compliance and verification process for extensions before granting access to development environments.
What teams should require
The paper’s evidence comes from public developer discussions, and the authors state that Reddit may not represent proprietary deployments or enterprise use. Counts show patterns in discussion, not product defect rates.
Even so, the operational controls in those discussions map directly to an enterprise rollout. Organisations can separate LLM-native IDE access from high-value secrets and production credentials. They can require approval gates before command execution or repository changes. They can also retain logs that show files accessed, context sent externally, and tools invoked during a task.
Vendor reviews should cover the behaviour of the whole application. Model safety claims alone do not answer whether an IDE honours ignore rules, blocks a command, isolates project memory, or prevents a connected tool from acting outside its remit.
The reported Copilot .env reproduction provides the most concrete test: configured exclusions must remain enforced through follow-up debugging prompts, not only during the first interaction.