arXiv:2607.26390v1 [cs.SE] 29 Jul 2026
“Impossible to hide secret ...”: Uncovering Security and Privacy Issues in LLM-native IDEs Mostafijur Rahman Akhond
Afif al mamun
York University Toronto, ON, CANADA [email protected]
University of Calgary Calgary, AB, CANADA [email protected]
Gias Uddin
Song Wang
York University Toronto, ON, CANADA [email protected]
York University Toronto, ON, CANADA [email protected]
Abstract
1
LLM-native IDEs (Integrated Development Environments), aka LIDEs, are designed from the ground up to work with Large Language Models (LLMs). LIDEs have found remarkable success in Software Engineering (SE) tasks such as coding, debugging, and program comprehension. LIDEs are software systems, and, like any system, they can exhibit vulnerabilities. In this paper, we study the security and privacy issues that developers reported while using popular LIDEs in their development tasks. We collected 1.1M posts from 29 popular subreddits related to LIDEs. We identified 446 posts and analyzed over 6K comments to the posts that discussed security and privacy issues in almost all popular LIDEs, such as Cursor, Copilot, Codex, etc. Using a mix of qualitative and quantitative methods, we constructed a taxonomy of the reported security and privacy issues. Our results show that most issues in LIDEs stem from system-level design choices, rather than the underlying LLMs, such as user data access, unchecked autonomous actions, etc. To overcome these issues, developers frequently relied on external safeguards like code sandboxing and manual reviewing, highlighting prevalent mistrust among developers about LIDEs. We share lessons from our study to support future design of secure and privacy-aware LIDEs.
Large Language Models (LLMs) have rapidly transformed the landscape of software development [12]. Beyond standalone chat-based assistants, LLMs are now deeply embedded into development workflows through LLM-native Integrated Development Environments (IDEs), aka LIDEs. Unlike traditional IDEs that merely integrate external tools or plugins [32], LIDEs are designed from the ground up to work in tight collaboration with LLMs, enabling capabilities such as real-time code generation, debugging assistance, automated refactoring, and program comprehension. Popular LIDEs, including Cursor, GitHub Copilot, Claude Code, and Codex, have been widely adopted and have demonstrated remarkable success in supporting a broad range of software engineering (SE) tasks. However, because LIDEs are built on machine learning systems, they may inherit security and privacy vulnerabilities that can arise both from the underlying LLMs or the system itself [36]. Prior research on LLM-assisted coding has largely focused on correctness, performance, and isolated vulnerabilities in LLM-generated code snippets [5, 25, 41]. Several empirical studies have shown that LLMs frequently generate insecure code patterns, violate secure coding practices, or hallucinate APIs and dependencies when prompts are underspecified [27]. Other work has demonstrated that LLM-generated code may reproduce vulnerable patterns present in training data or omit essential validation and access-control logic [8, 11]. However, these studies typically evaluate LLMs as standalone generators and therefore fail to capture the additional risks that emerge in LIDEs, where LLMs are embedded within complex systems involving tool invocation, persistent state, user data access, and autonomous actions. In this paper, we focused on understanding the security and privacy issues in LIDEs by empirically studying online developer discussions in Reddit. Reddit offers an unfiltered version of developers’ posts and comments, and a unique view of their actual usage
Keywords LLM, IDE, Security, Privacy, User Study, AI4SE
ACM Reference Format: Mostafijur Rahman Akhond, Afif al mamun, Gias Uddin, and Song Wang. 2018. “Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs. In Proceedings of Make sure to enter the correct conference title from your rights confirmation email (Conference acronym ’XX). ACM, New York, NY, USA, 13 pages. https://doi.org/XXXXXXX.XXXXXXX
Introduction
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Conference acronym ’XX, Woodstock, NY © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Akhond et al.
Reddit Post (1lkwwp6)
Reproduction Steps 3 Asking copilot to debug the database connection issue in a.py file Copilot Debugging Step 1 (Planning)
Developer Prompt
Database connection in {file_name}.py is not working
A Reddit post describing unauthorized access to user's secret file
1 2
- Read {file_name}.py - Identify the problems in line 100 - Requires .env to set the connection
Observation
4
Copilot Debugging Step 2 (Execution)
- Reads the .env file (though it is set to be ignored by copilot) - Spot the issue - Suggest changes
User Suggested Steps to Reproduce
5
1. Set the configuration file to be ignored by IDE 2. add .env in .gitignore and .copilotignore 3. Ask IDE to solve a problem encountered due to the configuration 4. The IDE reads the secrets
The .env file contains sensitive information, i.e. secrets and API keys. Accessing this information is a serious security breach
6
Figure 1: A Reddit post reported unauthorized access to a secret (.env) file (left). We confirm that it still persists (right). of LIDEs. For example, Figure 1 illustrates an incident reported by a Reddit user. The user configured a development environment with GitHub Copilot and managed secrets using an .env file. Although access restrictions were configured to prevent GitHub Copilot from accessing the .env file, these rules were not properly enforced. We attempted to replicate this issue, and during the process, we observed that after two debugging cycles (i.e., consecutive follow-up prompts) of a database connection issue, GitHub Copilot read and attempted to modify the .env file, ignoring the configured access restrictions. This behavior raises serious security and privacy issues, as the file contained private secrets and API keys, exposing developers to significant confidentiality risks. These findings motivated us to study (1) the security and privacy issues in popular LIDEs reported by developers in social forums like Reddit, (2) how they are currently mitigating the issues with or without help from the LIDEs designers, and (3) what suggestions we can offer to the LIDEs designers to make their applications more security- and privacy-aware. For our study, we first collected 1.1M posts from 29 manually curated subreddits that focused on LLM-assisted programming. Each subreddit explicitly used one or more popular LIDEs (e.g., r/cursor for the Cursor IDE). Second, we filtered posts using an LLM-based binary classifier targeting security and privacy discussion, followed by manual human verification, resulting in 446 posts and 6K associated comments. Each filtered post reported a real security/privacy issue a developer experienced while using an LIDE. The comments contained replies and suggestions from other developers on how to address the issue. Third, we labeled each post to identify the nature of the reported issues (e.g., unauthorized access to secrets, operational safety). This step produced a taxonomy of security issues and privacy issues in LIDEs. Fourth, we studied the suggestions discussed in the comments. These mitigation styles were identified by using an AI-assisted approach to extract actionable suggestions from comments, followed by manual verification and consolidation of semantically similar suggestions. Fifth, based on the mitigation styles discussed by developers and the issues observed in the posts, we distilled six high-level lessons that highlight key considerations for designing and using more secure LIDEs.
Our taxonomy reveals a broad range of developer-reported concerns, including unauthorized file operations, unsafe or unexpected code execution, triggering of destructive actions, opaque data flows, telemetry collection, and potential leakage of sensitive information through expanded context access. Many of these concerns stem from LIDEs being a system rather than from their usage of an LLM, such as operating with extensive project context, limited transparency, and insufficient user control over autonomous actions. Across tools, developers rarely rely solely on built-in safeguards and instead adopt external mitigation strategies such as sandboxing, manual code review, and restricted usage. This reliance on external controls highlights a persistent gap between user trust expectations and the security and privacy guarantees currently provided by LIDEs. In this paper, we make the following contributions: • Taxonomy of Security and Privacy Issues in LLM-native IDEs (Section 3). We present a total of 32 security and privacy issues in LIDEs as reported by developers. We grouped those issues into 10 high-level categories. • Mitigation Strategies (Section 4). We report 13 mitigation strategies that developers currently employ to address the issues with minimal/little help from the LIDEs. • Recommendations (Section 5). We offer six suggestions based on the lessons learned from our study. The suggestions could be useful for LIDE creators/vendors to design more secure and privacy-aware LIDEs.
2
Study Setup
Figure 2 outlines the pipeline of the mixed-methods approach consisting of data collection (see Section 2.1), data pre-processing (2.2), and data analysis (2.3). This pipeline enables us to first narrow a large corpus of developer discussions to a focused dataset of security- and privacy-relevant content. We then systematically analyze the filtered contents.
2.1
Data Collection
First, a comprehensive list of LIDEs was compiled by synthesizing information from different websites and blog posts [3, 31, 33, 34]. Second, by using the names of each identified IDE, we searched
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs
Open Coding
Extract Mitigation Strategies
Human Verification
446 Labeled Posts
1.4K Labeled Comments
3801 Posts 37K comments
Axial Coding
Human Verification
15.4 M posts and comments
Subreddit Posts
Search and Filter related posts
5 Security Topics 5 Privacy Topics
Taxonomy
13 Mitigation Strategies
Strategies
Data collection
Collect Posts
Data preproces
Subreddit List
Post analysis
...
Subreddits
446 Posts 6K Comments
Verified Posts
6k Comments
r/CLine r/cursor
46 subreddits
Comment analysis
Collect Subreddit List
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Table 1: Human-validation outcomes for a random audit of 200 unseen posts stratified by LLM prediction: 100 posts labeled by the LLM as relevant and 100 as irrelevant. TP
FP
TN
FN
Accuracy
Precision
Recall
F1
21
79
100
0
0.61
0.21
1.00
0.35
Table 2: Manual validation agreement for the 3,801 LLMfiltered candidate posts.
Figure 2: Workflow of the Study Agree
Reddit to locate associated subreddits. We then identified relevant subreddits on software development, programming tools, and AIassisted coding. To the end, our dataset includes both formal subreddits dedicated to specific AI-assisted IDEs (e.g., r/Cursor, r/GithubCopilot) and broader programming communities where discussions of these tools frequently occur (e.g., r/programming, r/ChatGPT ). The initial list comprised 46 subreddits. Third, we downloaded 15.4 million posts and comments from the 46 subreddits published between January 2023 and March 2026.
2.2
Data Preprocessing
Not all posts in our 46 subreddits contained security and privacy issues. To isolate such discussions from the raw dataset, we employed an LLM-assisted filtering approach combined with manual validation. Given the scale of the collected data, fully manual screening was infeasible; however, we took several steps to ensure that the use of an LLM did not compromise the validity of the dataset. LLM-based filtering. We used the GPT-OSS:20B model to identify potential posts that discussed security or privacy issues in LIDEs. Rather than relying on the model out of the box, we first constructed a small, manually curated seed set of 20 posts from the period January 2023 – October 2025 that contained diverse security or privacy issues, such as data leakage, unauthorized access, unsafe code generation, and policy or compliance risks. This seed set was used only for prompt development and refinement. Since false negatives are the most consequential error in our pipeline, our prompt was designed to maximize recall over precision to include as many security/privacy concerns as possible. After finalizing the prompt, we ran it on all the posts in our dataset. This step resulted in 3,801 candidate posts labeled by the LLM as relevant. Validation of LLM filter. We manually audited the frozen LLM filter on 200 previously unseen posts randomly sampled from its outputs: 100 predicted relevant (LLM-positive) and 100 predicted irrelevant (LLM-negative), drawn from the latest portion of our dataset that was not consulted during our prompt design (i.e., November 2025–March 2026). We then manually assessed these 200 posts. The confusion matrix is constructed as: 1) TP = LLM labeled as 1 (i.e., relevant) which the human also found as 1, 2) FP = LLM labeled as 1 which the human found as 0 (i.e., irrelevant), 3) TN = LLM labeled as 0 which the human also found as 0, and 4) FN = LLM labeled as 0 which the human found as 1.
Relevant
Not relevant
431
3,344
Disagree
Observed agreement
Cohen’s 𝜅
Retained posts
26
99.3%
0.967
446
Thus, the validation sample was only seen by the humans after the LLM labels. We note that while this validation sample is balanced (i.e., equal number of posts labeled as 1 and 0 by the LLM), the entire dataset is heavily skewed towards posts labeled as 0. Thus, the validation sample does not represent the natural prevalence of security/privacy discussions in the Reddit corpus. Instead, it evaluates both output streams of the filter by measuring false positives among LLM-positive posts and false negatives among LLMnegative posts. This design is appropriate for our pipeline because LLM-positive posts are later manually validated, whereas LLMnegative posts would normally be excluded from further analysis. Therefore, the audit primarily assesses whether the recall-oriented filter risks discarding relevant discussions. Table 1 summarizes the human-validation outcomes and corresponding metrics. The audit yielded 21 true positives, 79 false positives, 100 true negatives, and no false negatives, corresponding to 0.61 accuracy, 0.21 precision, 1.00 recall, and an F1-score of 0.35. These results confirm that the filter was recall-oriented within the audited sample: it retained all relevant posts but also admitted many irrelevant ones. The low precision increased manual-review effort, but the false positives did not impact our final dataset (which we used to create our taxonomies) because every LLM-positive post was manually verified before qualitative coding. Audit of LLM-negative posts. The validation set evaluates the filter on a balanced unseen sample, but it does not, by itself, rule out false negatives in the full corpus. This threat is crucial as false negatives would remove relevant discussions before manual review and could therefore affect the completeness of the taxonomy. To estimate this residual risk, we manually audited 200 additional randomly selected posts that the LLM had classified as not relevant. The audit identified 0 missed relevant posts among those posts. This result suggests that the residual false-negative risk after LLM filtering is low. Manual validation of LLM-positive posts. The first two authors independently reviewed the title and body of each of the 3,801 LLMpositive candidates and assigned a binary relevance label using shared inclusion and exclusion criteria, formalized in a screening codebook provided in the replication package (Appendix E). Posts were retained if they concerned an LIDE and reported, questioned, or warned about an observed or identifiable security or privacy
Total Number of Posts
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Table 3: Post-level summary of multi-label coding among the 446 final posts.
50 40 30 20
Security/privacy classification
10
20 2 20 3-02 2 20 3-03 2 20 3-05 2 20 3-07 2 20 3-11 2 20 3-12 2 20 4-01 2 20 4-03 2 20 4-05 2 20 4-06 2 20 4-07 2 20 4-08 2 20 4-09 2 20 4-10 2 20 4-11 2 20 4-12 2 20 5-01 2 20 5-02 2 20 5-03 2 20 5-04 2 20 5-05 2 20 5-06 2 20 5-07 2 20 5-08 2 20 5-09 2 20 5-10 2 20 5-11 2 20 5-12 2 20 6-01 2 20 6-02 26 -03
0
Time
Figure 3: Monthly counts of the security & privacy posts
issue. The principle-based criteria covered confidentiality, integrity, availability, authorization, data handling, transparency, etc., while allowing plausible, previously unseen issues to be retained for subsequent open coding. Table 2 summarizes the agreement between the two annotators. As shown in Table 2, the annotators agreed on 3,775 of the 3,801 candidate posts. They agreed that 431 posts were relevant and 3,344 posts were not relevant. The observed agreement was 99.3%, and Cohen’s 𝜅 was 0.967, indicating near-perfect agreement. The annotators disagreed on 26 posts: 15 were marked relevant only by Author 1 and 11 were marked relevant only by Author 2. All disagreements were resolved through consensus discussion among all the authors; 15 disputed posts were retained, and 11 were excluded. This process resulted in 446 final posts for qualitative coding. The relatively low retained proportion among LLM-positive candidates reflects our recall-oriented filtering strategy, such that false positives increased manual validation effort, but they did not contaminate the final dataset because every retained post was manually verified. Preprocessing outcome. We initially selected 46 subreddits for data collection. After preprocessing and manual validation, the final dataset contained 446 security/privacy-relevant posts, drawn from 29 of those subreddits. The rest were discarded due to a lack of LIDE-related security & privacy issues. Figure 3 presents the monthly distribution of the validated posts during the study period. Overall, reporting peaked in mid-2025 and, after a decline, remained comparatively stable. This distribution reflects the frequency of relevant reports in our collected Reddit data. Furthermore, we also analyzed the comments associated with the 446 validated posts, yielding 6,280 comments for mitigation analysis.
2.3
Akhond et al.
Data Analysis
We manually assessed each filtered post and comment. We observed that the posts contained security and privacy issues developers encountered while using LIDEs, and the comments to the posts contained affirmation from other developers and suggestions from them on how to mitigate the issues. We thus labeled the posts to collect the reported issues and the comments for the mitigation strategies. Post Analysis We used an open coding approach [35] to manually label each post based on reported security and privacy issues. First, all authors reviewed a pilot set of 50 Reddit posts and established four principles: (1) multi-label annotation to capture multiple themes per post; (2) a three-level taxonomy (category–subcategory –leaf) for granularity, following prior work [23]; (3) iterative bottomup merging of independently generated labels; and (4) hybrid card
Distribution
#
Principal taxonomy categories per post %
Security only 252 56.5 Privacy only 149 33.4 Both 45 10.1
Distribution
#
Posts with multiple low-level issue labels %
One category 365 81.8 Two categories 78 17.5 Three categories 3 0.7
Issue type
#
%
Security (𝑛 = 297) 27 9.1 Privacy (𝑛 = 194) 12 6.2
sorting with predefined top-level categories (Security and Privacy) informed by ISO/IEC 27001/27002/29100. To ground the taxonomy, we adopted ISO/IEC security and privacy principles. ISO/IEC 27001 guided our classification of security issues using the CIA triad—confidentiality, integrity, and availability—while ISO/IEC 29100 informed our interpretation of privacy violations related to unauthorized data collection, use, or exposure. Detailed operationalization is provided in replication package. Next, the first two authors assigned descriptive, low-level codes closely reflecting the original language (e.g., “Read API keys from .env file,” “generating SEO spam”). This inductive process surfaced both expected risks (e.g., prompt injection) and emergent ones (e.g., hallucination-driven unsafe behavior). Posts covering multiple issues were labeled accordingly. Finally, the two authors conducted axial coding, grouping related open codes into higher-level categories based on shared mechanisms and affected assets [35]. Codes were iteratively refined to improve clarity, resulting in a structured taxonomy of security and privacy issues in LIDEs. All four authors met regularly to review and finalize the taxonomy. Category Boundaries and Assignment of Multiple Labels. After relevance validation, the authors jointly reviewed the retained posts to construct the taxonomy, focusing on the concrete securityor privacy-relevant behavior described in each post. Most posts reported one dominant issue, so we assigned the code capturing the main action attributed to the LIDE, considering the action described, its source or actor (e.g., the LIDE itself, an external tool, a plugin, or prompt/context manipulation), and the affected development domain—files, secrets, databases, production systems, GitHub or deployment workflows, telemetry, or conversation context. Since Reddit posts sometimes describe more than one failure mode, our taxonomy categories are not mutually exclusive. We used multi-label coding only when a post explicitly described multiple distinct S&P issues. We did not assign additional labels merely because an issue could imply a secondary risk. For example, one post reported that Cursor bypassed .cursorignore and modified files the user had explicitly excluded (1ortu5j); we assigned two labels, for unauthorized file modification and for violating the configured constraint. In contrast, a post describing only silent file deletion (1m92q5a) received a single Destructive Actions code. Table 3 summarizes multi-label coding at the dimension, category, and issue levels. Among the 446 posts, 45 contained both security and privacy concerns. At the category level, 365 posts received one taxonomy category, 78 received two, and 3 received three. Multi-label coding also occurred within the security and privacy taxonomies when a post explicitly described multiple issue types. The three
Figure 4: Distribution of LIDEs mentioned in Reddit posts with security or privacy issues
08
25-
12
25-
200 400 600
300 600 900
03
26-
Windsurf Bolt Roo Zed Cline
04
25-
08
25-
12
25-
03
26-
Less-discussed IDEs
Codeium Kiro Kilo Warp Trae Aider
0
04
25-
Moderately-discussed IDEs
0
#Posts
900 1800 2700
Highly-discussed IDEs
Cursor VS Code Replit Copilot JetBrains
0
Others (30)
VSCode (16) Replit (16) Cline (7)
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Windsurf (23)
Copilot (31)
Codex (41)
Claude (89)
Cursor (130)
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs
04
25-
08
25-
12
25-
03
26-
Figure 5: Monthly pattern of Reddit posts on LIDEs
table sections describe different levels of coding and should not be summed, because the same post may appear in more than one section. Consequently, the category and issue percentages reported in Section 3 are post-level multi-label percentages and do not form mutually exclusive partitions of the dataset. Comment Analysis. The filtered Reddit posts received 6,280 comments (avg. 14 per post), many containing practitioner mitigation suggestions. We identified these strategies using a two-step process: LLM-assisted extraction followed by human verification. First, we used GPT-OSS:20B to extract concise, actionable mitigation suggestions from comments in the context of the reported issue. This yielded 2737 candidate suggestions. We then consolidated semantically similar suggestions via an additional prompting step (e.g., merging persistent memory across sessions and use contextual memory into AI memory isolation). The first two authors refined the consolidated results into a codebook of 13 mitigation categories. Using this finalized codebook, we re-labeled all comments with LLM assistance for consistency. This step assigned 1,392 comments to one or more categories, labeled 18 as uncategorized, 8 as a parsing error, and marked the remainder as not a suggestion. Prompts and the codebook are provided in the replication (Section 9). Second, the first two authors manually reviewed all comments and labels. Inter-rater reliability was near perfect (Cohen’s 𝑘 = 0.99). We corrected 91 labeling errors (≈1%), including misclassifications (88) and missed suggestions (3). The final dataset contains 1,318 comments with actionable mitigation strategies. A few categories were sparsely represented, such as Data Redaction (3 comments), Disconnecting from the Internet (2), Upgrading Subscription Plans (1), and Use of Data Recovery Techniques (1).
3 Reported Security and Privacy Issues 3.1 IDEs with Security & Privacy Issues We found that developers reported security and privacy issues against 16 popular LIDEs. Of the 446 posts, 383 explicitly named a LIDE; Figure 4 shows the frequency of those mentions. Where Cursor (130) is found as the most discussed LIDE. While Figure 5 presents the monthly Reddit post distribution for these LIDEs, grouped into Highly- (>3000 posts), Moderately- (3000-1000), and Less-discussed categories based on total post counts. Thresholds reflect natural separations and are used for comparison only. Highdiscussion IDEs—such as Cursor, Visual Studio Code, JetBrains, Replit, and Bolt—generate the majority of posts, while mediumand low-discussion tools show sparser activity, reflecting smaller or specialized user bases.
LIDE Security Issues in Developer Discussions
Destructive Actions (28.3%)
C1. Unauthorized File Operations (43.1%)
Unauthorized Modification (8.8%) Unauthorized Content Access (5.7%) File Permission Changes (0.6%)
C2. Operational Safety Issues (23.9%)
Production-Level Destructive Action (3.7%) Prompt Injection (2.7%) System-Level Modification (2.2%) General Security Concerns (15.5%) Unsafe Code Generation (9.8%)
C3. Unsafe Generation of Code (18.2%)
Hallucinations-Driven Unsafe Behavior (7.7%)
C4. User-Specified Constraint Violations (16.5%)
Breaking Explicit User Constraints (8.4%)
Using Untrusted Dependency (1.4%)
Unauthorized Command Execution (7.1%) Ignoring Permission-Required Settings (2.0%)
C5. Third-Party Tools Integration Risks (4.7%)
Risky or Compromised Integrations (2.4%) MCP Server Risks (2.0%) Unsafe Tool Execution (1.0%)
Figure 6: Taxonomy of the reported security issues
Figure 7: A post on Codex Unusual deletion of contents
3.2
Reported Security Issues in the IDEs
In total, 297 posts described security issues related to LIDEs. We group the issues into five high-level (C) and 17 low-level categories and present them in our taxonomy (Figure 6). The categories are not mutually exclusive, 27 posts (9.1%) received two security labels (Table 3). Consequently, the sum of low-level category counts exceeds the number of unique security-related posts. Unauthorized File Operations (C1, 43.1%) C1 captures unauthorized access, modification, deletion, or permission changes to files and directories in the developer’s workspace, affecting workspace artifact (e.g., source code, project directories, configuration files, local project data, or file permissions). The LIDEs removed project directories or files without authorization (Destructive Actions 28.3% times). For example, Figure 7 shows that Codex deleted files autonomously. Another case where Cline silently removed files: “...When API requests get stuck, some files being modified will be silently deleted from the ssd drive.”–1m92q5a. LIDEs modified project files without explicit user consent (Unauthorized Modifications 8.8%). We also observed more severe cases involving unauthorized changes to critical project metadata, such as project licenses (e.g., 1nbgrv0). A user complained: “...50% of the time, I say "analyze this problem, root cause analysis only, no code changes allowed".. and it would go ahead and randomly start editing my code..." – 1kg24hz
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
LIDEs accessed content beyond the active workspace, risking exposure of sensitive data (Unauthorized Content Access 5.7%). For instance, Windsurf accessed personal files (1mju0jz), and Copilot summarized files, although claimed to be unable to open (1mc7cof). When the accessed content contained secrets, credentials, personal information, or proprietary data, we coded the post under the corresponding privacy category. In one severe case (1npqf2f), Claude Code executed chmod +x on scripts without consent (File Permission Changes 0.6%). Although rare, such actions pose disproportionate security risks. Observation# 1 28.3% of LIDE security incidents involve deletion of critical code or assets, often resulting in direct monetary and integrity losses. Operational Safety Issue (C2, 23.9%) C2 arises when LIDE behavior affects runtime stability, production infrastructure, deployment state, databases, operating-system state, service availability, or agent execution. It also includes prompt-based manipulation where adversarial or hidden instructions redirect the LIDE’s actions, tools, or commands. The defining feature of C2 is the system- or production-level impact beyond ordinary workspace file operations. Unlike C1, which captures unauthorized operations on workspace artifacts, C2 captures broader operational and production-level consequences. For example, Replit removed a SaaS production database (1m5biur) (Production-level Destructive Action, 3.7%), which we coded as C2 because the affected asset was live production data rather than a local workspace artifact. In another case, Cursor deployed code to production - “...told Cursor to NEVER push code to GitHub. Despite this, every once in a while, it gets a little overconfident and ignores these rules.”–1n1zdwp. Cursor was also found changing operating system files (System-Level Modifications, 2.2%): “...Out of nowhere, while the project was open in the IDE, my entire Windows desktop began glitching. Icons on my desktop started shifting around slightly..." – 1n2xy30 We also observed Prompt Injection (2.7%), where malicious instructions attempted to redirect LIDE behavior toward unsafe operational actions. For example, a malicious prompt introduced through a GitHub pull request instructed Amazon Q to perform destructive file and cloud operations: “Last week, someone slipped a malicious prompt into Amazon Q via a GitHub pull request. It told the AI to delete user files and wipe cloud environments. No exploit. Just cleverly written text that made it into a release.”–1m91d4t. We also coded posts as General Security Concerns (15.5%) when users discussed possible system-level compromise, agent manipulation, or standards for preventing unsafe operational behavior, even when no concrete incident was reported. For example, “Is there a concrete roadmap/standard for preventing manipulation and “infection” of Claude Code? ”–1m77t4d O# 2 Operational safety accounts for 23.9% of the security issues, including cases where LIDEs affected production resources, system stability, or safe control of agent execution. Unsafe Generation of Code (C3, 18.2%) C3 covers unsafe code produced or recommended by a LIDE, including vulnerable code, hallucination-driven changes, and untrusted dependency recommendations. Its defining feature is that the risk originates in the
Akhond et al.
Figure 8: A Reddit post on generating spam with Cursor
generated code or recommendation itself, rather than in an unauthorized workspace operation or broader operational impact. The most direct form was vulnerable or malicious code generated by the LIDE (Unsafe Code Generation, 9.8%). Figure 8 shows cursorgenerated code containing SEO spam; in another case, virustotal detected nine viruses in Cursor-generated software (1ld3qlz). LIDEs also produced code, commands, and behaviors based on incorrect contextual understanding (Hallucinations-Driven Unsafe Behavior, 7.7%), as when Cursor generated hallucinated code beyond requirements—“When using Cursor, I noticed that after more than 10 rounds of dialogue, it starts to hallucinate and secretly modify code outside the requirements...”–1l3wwq3 LIDEs were also found to suggest unverified or potentially malicious packages as part of generated code or recommendations (Using Untrusted Dependencies, 1.4%). For example, Windsurf introduced dependencies that expanded the attack surface: “...In Python especially, I’ve encountered instances where the AI adds unnecessary dependencies or tools that aren’t relevant to the task. This poses a significant security risk, especially with the increase in attacks targeting Python ..." – 1i23dwc O# 3 Unsafe generation included producing vulnerable code, hallucinated behaviors, or untrusted dependencies (18.2%) User-Specified Constraint Violations (C4, 16.5%) C4 captures cases where an LIDE ignored explicit user instructions, allowlists, approval gates, permission settings, or .ignore files. The defining feature of C4 is the violation of a user-specified rule, rather than the production of unsafe code or the modification of a workspace artifact. In several cases, LIDEs executed commands without confirmation (Unauthorized Command Execution, 7.1%). For example, a user reported that Cursor ran a git commit despite not being in the allowlist (1ocm0e0). Cursor was reported to bypass .cursorignore settings (Breaking Explicit User Constraints, 8.4%): “... it works around cursorignore and uses filesystem access to edit files which I clearly do not want to be touched..." – 1ortu5j Other posts described LIDEs ignoring approval requirements for sensitive actions (Ignoring Permission-Required Settings, 2.0%). For instance, a user noted that Claude Code, despite being configured to request permission before Git commits, eventually began autocommitting within the same session (1ldi19c). O# 4 User-specified constraint violations (16.5%) comprise systematic failures where LIDEs disregard explicit instructions, bypass approval gates, or execute unauthorized commands. Third-Party Tools Integration Risks (C5, 4.7%) C5 captures risks from plugins, MCP servers, external tools, or other integration boundaries connected to a LIDE. Unlike C3’s untrusted dependencies—recommended or installed by the LIDE during code
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
LIDE Privacy Issues in Developer Discussions
Unclear/ Vague Policies (12.4%)
C6. Lack of Transparency (45.9%)
C7. Unauthorized Data Access (23.7%)
Data-Collecting Default Settings (6.7%) General Privacy Concerns (26.8%) Accessing User secrets (14.4%) Violating Project Boundary (6.7%) Accessing PII (3.1%) Training/Retention of User Data and IP (9.3%)
C8. Privacy Leakage Violations (15.5%)
User Secrets Exposure (5.2%) Violations of Data Flow and Persistence (1.0%) Data Transmission without Consent (4.1%)
C9. Unauthorized Transmission & Collection (11.9%)
Sending Sensitive Information (3.6%)
C10. Context Integrity Failure (8.8%)
Cross-Session Data Leakage (4.6%)
Uncontrolled Telemetry (3.1%) Cleartext Transmission (1.0%)
Conversation Context Contamination (4.1%)
Figure 9: Taxonomy of Detected Privacy Issues
synthesis—C5 covers risks from separately connected tools or extensions with their own permissions, or hidden behaviors. We observed MCP Server Risks (2.0%), where misconfigured or malicious MCP servers could embed hidden instructions or deliver malicious payloads through tool calls. For example, a Cursor-related post stated: “the mcp installs...then it sends malicious payloads under the guise of call_tool. this is 1, of many attack vectors its actually insane.”–1l1tmcg. We also observed Unsafe Tool Execution (2.4%), where connected tools performed unauthorized or malicious actions through the LIDE’s tool interface. For example: “...enables ‘Tool Poisoning Attacks’. This exploit allows malicious MCP servers...Cursor are susceptible to this attack..." – 1jqf1u5 O# 5 Third-party integration risks (4.7%) stem from an expanded attack surface. External components leverage broad permissions and opaque data flows to execute unsafe tools or embed malicious logic with minimal oversight.
3.3
Reported Privacy Issues in the IDEs
In total, 194 posts corresponded to privacy issues, grouped into five high-level and 15 low-level categories (see Figure 9). We define privacy from the LIDE end user’s perspective—the developer and their workspace—covering credentials, project secrets, proprietary code, local files, conversation history, and organization-owned assets accessible through the developer’s environment. Organizational privacy is included when a post reports exposure or handling of company code, credentials, managed accounts, or proprietary data; downstream-user privacy is included only when access, exposure, transmission, or retention of users’ PII is explicitly described. Lack of Transparency (C6, 45.9%) C6 covers cases where users lacked clear information about what data an LIDE collects, retains, transmits, uses for training, or exposes to administrators. Its defining feature is opacity or uncertainty about data use and control, rather than a confirmed access, transmission, or leakage incident. Users frequently reported uncertainty about how LIDEs handle development data, including confusion about data-use policies (Unclear or Vague Policies, 12.4%) and what administrators could access when company-managed accounts were used for personal projects (1nj6ojg, 1olyysx, 1n3fqvg). Transparency concerns also arose from default data collection or unexpected shifts in data-sharing settings (Data-Collecting Default Settings, 6.7%): “... your plan is switched to Free Plan automatically, ALL YOUR DATA IS OPEN FOR THEIR
MODEL TRAINING”–1ntd0cc. Broadly, users expressed general uncertainty about privacy implications (General Privacy Concerns, 26.8%)—for instance, questioning whether the JetBrains AI plugin might transmit proprietary code despite configuration safeguards: “How is everyone dealing with possibility of proprietary code being transmitted to third parties? ... having some doubts after seeing AI plugin not respecting ‘uninstalled’ status..." – 18m3k29 O# 6 Transparency issues make up 45.9%, underscoring user uncertainty about privacy and data use. Unauthorized Data Access (C7, 23.7%) C7 concerns unauthorized inspection or retrieval of sensitive data, such as secret keys, PII, proprietary code, or files outside the intended project scope. LIDEs accessed private or restricted information such as API keys, database credentials, or environment variables without explicit user intent (Accessing User Secrets 14.4%). A user reported that Cursor autonomously searched for and accessed environment files to retrieve database credentials: “...Essentially, it determined that it needed database credentials and specifically went looking for .env files...”–1l7fwgk. A smaller number of posts described incidents involving the retrieval or use of personally identifiable information without user awareness (PII Accessed Without Consent 3.1%). A user reported that Claude Desktop autonomously created a new Replit account using the user’s personal information without explicit consent. “...Claude Desktop created a new Replit account...proceeded to create its very own anthropic computer use app..." – 1m70vxh O# 7 23.7% of LIDE privacy issues involved in retrieving user secrets, crossing project boundaries, or handling PII without consent, compromising data isolation and user trust. Privacy Leakage Violations (C8, 15.5%) C8 covers cases where sensitive user, project, or organizational data was retained, exposed, or persisted beyond the user’s expected data boundary. Its defining feature is loss of control over the data lifecycle after access or processing, rather than mere uncertainty about data practices or the initial act of unauthorized access. Users raised concerns about retention of user information (Training/Retention of User Data and IP 9.3%) by LIDEs. From Claude policy— “By September 28, 2025, all Claude users... must decide: let Anthropic use your conversations for AI training and keep them for 5 years, or lose the memory/personalization features..." – 1nd73si Users also reported secret exposure in LIDEs (User Secrets Exposure, 5.2%), including leaked API keys and credentials inserted into code: “Claude Code will sneakily add a password or API key or Auth token directly into a script”–1mdk90e. Other concerns raised about expected data-flow and persistence violations (Violation of Data Flow and Persistence, 1.0%), including cross-user exposure due to misrouting (1oqb66h). O# 8 Privacy leakage violations (15.5%) occur when AI assistants retain data, mishandle persistence, or expose credentials, undermining user control and trust over the data lifecycle. Unauthorized Transmission & Collection (C9, 11.9%) C9 identifies cases where an LIDE transmitted, collected, or stored user data—via movement, telemetry, or plaintext storage—beyond explicit approval or user control. We found cases of confidential data
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Akhond et al.
being sent to external services without user confirmation (Sending Sensitive Information, 3.6%). For example, Windsurf changed environment files and transmitted their contents externally (1l3zhdr). Other posts described data transmission without explicit consent (Data Transmission Without Consent, 4.1%), including a case where VS Code sent source code and project files despite telemetry being disabled, as revealed via a man-in-the-middle proxy analysis:
Unauthorized File Operations (123) Operational Safety Issues(62) User-Specified Constraint Violations (47) Unsafe Generation of Code (41) Third-Party Tools Integration Risks (12)
“... I searched the proxy records and sure enough the file i was working on was being sent along with every other file with a whole heap of other data, with telemetry turned off..." – 1nd73si LIDEs were also reported to collect or transmit usage data with limited user awareness or control (Uncontrolled Telemetry 3.1%). For example, one redditor reported that Trae repeatedly connected to more than five ByteDance-associated domains at regular intervals, even while idle (1m5o9sz). In other cases, sensitive data was transmitted or stored without encryption (Cleartext Transmission 1.0%). One discussion noted that Claude Code recorded complete conversation histories in plaintext on the local system: “every message I send is being recorded in my /.claude.json”–1moe4nq. O# 9 11.9% of privacy issues involved in transmitting telemetry or sensitive data without user consent, sometimes storing or sending it in plaintext, reducing transparency and user control. Context Integrity Failures (C10, 8.8%) C10 concerns failures of contextual separation, where information from one user, session, project, or conversation improperly appears in another context. Unlike C8, which emphasizes the exposure of user secrets and data flow. LIDEs were reported to leak contextual data across user sessions, exposing private code, conversations, or files (Cross-Session Data Leakage 4.6%). For example, a user of Claude Desktop reported receiving messages originating from another user’s session: “...I started getting messages in my chat from another user"– 1nfkfqs LIDEs also reused contextual information across separate projects or conversations within the same account (Cross-Conversation Context Contamination 4.1%). In one case, a user reported that content from a previous project appeared in the artifacts of a different project, indicating a failure to differentiate project boundaries: “. . . you’ll find the critical request from the previous project in your FINDINGS.md, two completely different projects, it can’t differentiate between projects”–1n1gdzr. O# 10 8.8% of privacy issues involved context integrity breaches, where AI reused information across sessions or chats, undermining data isolation and confidentiality.
3.4
Distribution of the Issues Across the IDEs
The distribution of issues is skewed towards some studied LIDEs (see Figure 10). Cursor accounts for 130 of the 376 IDE-referenced posts (Figure 4). Claude and Codex follow with 89, and 41 mentions, respectively, while Copilot receives 31 mentions. Windsurf (23), VSCode (16), and Replit (16) appear less frequently. This imbalance is reflected not only in discussion volume but also in topic breadth. Cursor and Claude appear across nearly all identified security and privacy categories, whereas other IDEs exhibit narrower profiles. Cursor’s prominence should be interpreted in context. It is among the most frequently discussed (∼24K) AI-assisted IDEs on Reddit (Figure 5), suggesting that higher issue counts partly reflect broader
31.7 22.8 4.9
5.7 19.5 1.6
6.5
7.3
46.8 24.2 6.5
3.2
3.2
8.1
4.8
3.2
6.4
6.4
4.3
6.4
34.1 29.3 4.9 12.2 9.8
2.4
4.9
2.4
33.3 50.0
16.7
31.9 36.2 8.5
t t r r x e e rf Curso Claud CopiloWindsu Code VSCod Repli Othe
(a) Security-related discussions across IDEs.
Lack of Transparency (65) Unauthorized Data Access (39) Privacy Leakage Violations (23) Unauthorized Transmission & Collection (19) Context Integrity Failures (13)
32.3 21.5 13.8 7.7
9.2
4.6
1.5
9.2
41.0 17.9 7.7 10.3 12.8 5.1
2.6
2.6
34.8 30.4 8.7
4.3
4.3
4.3 13.0
21.1 10.5 15.8 10.5
15.8
26.3
30.8 30.8 7.7
7.7 23.1
t t r r x e e rf Curso Claud CopiloWindsu Code VSCod Repli Othe (b) Privacy-related discussions across IDEs.
Figure 10: Percentage distribution of security and privacy issues across LIDEs
adoption. VSCode, although widely discussed (∼22K), delivers AI functionality via extensions. As a result, issue-related discussions are distributed across multiple tools rather than concentrated in the core IDE, contributing to lower and more fragmented attribution. O# 11 Cursor (34.5%) and Claude (23.7%) combined dominate discussions across most issue categories, underscoring the need for strong safeguards in agent-driven development environments.
4
Reported Mitigation Strategies
We identified 13 mitigation strategies discussed by developers in Reddit comments addressing reported security and privacy issues. After manual verification, 1,318 comments contained actionable suggestions. Individual comments may include multiple strategies. We group these strategies into five higher-level categories. Table 4 shows for each the total number of comments and the corresponding percentage relative to all actionable comments. Because comments can mention multiple strategies, category totals may not sum to the overall count. The categories are described below. Configuration Management. This category represents five strategies reflecting the necessity of deliberate LIDE safeguarding. The primary tactic, Secure IDE Configuration (S1), focuses on restricting permissions, file-system access, and agent autonomy to mitigate overly permissive default settings. A practitioner advised: “Run Claude in a dedicated user, remove access for those files”–1m1t2z9. Additionally, Organizational Compliance (S2) emphasizes aligning LIDE usage with internal governance and regulatory mandates. For example, a user asked How are y’all dealing with sensitive data?, a developer suggested to: “...Unless your employer has approved it, do not use it. Check IT department’s policy regarding AI. If they do not have
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs
Table 4: Mitigation strategies from Reddit comments Topic
Count
Definition
Category 1: Configuration Management (501, 33%) S1: Secure IDE Con345 Configuring IDE settings to restrict unsafe behaviors, permissions, figuration and unintended AI actions. 74 S2: Check OrganizaEnsuring LIDE usage aligns with internal security policies and tional Compliance regulatory requirements. S3: Disable Teleme38 Disabling data collection and outbound communication that may try expose sensitive development information. 24 S4: Tool and ExtenMonitoring third-party plugins and extensions to prevent unausion Monitoring thorized or risky behavior. S5: Logging and 20 Tracking IDE and AI activities to detect misuse, anomalies, or Monitoring policy violations. Category 2: Code Governance (471, 31%) S6: Manual Code 239 Requiring human review of AI-generated code before acceptance Verification or deployment. S7: Use Version Con232 Using version control systems to track changes, enable rollback, trol and ensure accountability. Category 3: Data Protection and Privacy Control (199, 13%) S8: Sensitive File Preventing AI tools from accessing or modifying secrets, creden143 Protection tials, and confidential files. 56 S9: Memory/ConRestricting how conversational context or memory is shared text Isolation across sessions or projects. Category 4: Isolation (199, 13%) S10: Sandboxing 105 Executing AI-generated or suggested code in isolated environments to limit potential harm. S11: Use Local LLM 94 Running a self-owned or local model to avoid external data transmission and maintain data sovereignty. Category 5: External Guidance (139, 9%) 74 S12: Consult VenEngaging with tool vendors to clarify security guarantees, limidors tations, and best practices. Also refers to upgrading or changing the version of the tool. S13: Refer to Docu65 Consulting official documentation to understand secure configumentation ration and intended tool behavior.
a policy, ask they draft one... HIPPA?! Just no, man”– 1n11a3e. Users are recommended to Disable telemetry (S3) to prevent data leakage, and to employ Tool and Extension monitoring (S4) and Logging (S5) to detect unauthorized behavior and ensure policy compliance. O# 12 Configuration Management (33%) focuses on securing IDE configurations, improving settings, disabling telemetry, and enforcing compliance checks. Code Governance. Code Governance requires Manual Code Verification (S6), discourages full LIDE autonomy, favoring manual review of code changes and explicit approval gates. As a user warned: “all LLM providers have a warning, YOU should double check the output”– 1lrbov5. Closely related to this, Use Version Control (S7) serves as a critical recovery mechanism. Practitioners advocated for frequent, incremental commits to enable rollbacks after unintended deletions or silent corruptions: “You shouldn’t have had 30,000 lines of code in something not backed up...Sync to GitHub.”– 1olmaj3. O# 13 Code Governance (31%) can be achieved by manual code verification and disciplined use of version control to ensure accountability, auditability, and recovery from AI-induced errors. Data Protection and Privacy Control. This category details defensive strategies against unauthorized access. The primary strategy, Sensitive File Protection (S8), emphasizes secret isolation via .env files and enforced exclusion rules (.gitignore) to block AI access to hardcoded credentials. For example, in reply to a .env related issue, one practitioner suggested: “You should have different env for local dev and production, don’t trust any tool or AI...”–1l3zhdr.
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Security System
Cursor Claude Replit Codex Windsurf Vscode Copilot Other
Security LLM
70% 59% 66%
75%
40
4%
37%
90%
72%
8% 14%
33%
95% 77% 79% 85%
20
Privacy LLM
30% 40%
85%
62%
0
Privacy System
91%
9% 22% 20% 14%
96%
27%
93%
25%
93%
60
Percentage of Issues
80
4%
6% 6%
100
Figure 11: LIDEs mentioned in System and LLM Level Issues
Similarly, Memory/Context Isolation (S9) guides for restricting crosssession context sharing to prevent memory mechanisms from retaining sensitive data beyond its intended scope. These strategies reflect a zero-trust posture, where practitioners prioritize constraints over built-in LIDE protections. O# 14 Protecting sensitive files and memory isolation (13%) are treated as necessary countermeasures against inadvertent data exposure rather than optional safeguards. Isolation. The Isolation strategy treats AI agents as actors requiring explicit containment. The primary strategy, Sandboxing (S10), mandates executing AI-generated code within isolated environments like containers, VMs, or devcontainers to prevent system-wide harm. Following a report where an agent attempted to delete a home folder, a practitioner advised: “...you should always run these agents in a VM of some sort, not your host machine”–1ordvv6. Practitioners also advocate for Use Local LLM (S11) to maintain data sovereignty and eliminate external API data transmission. This approach addresses risks regarding opaque vendor retention policies and proprietary code exposure, prioritizing local execution to ensure total control over sensitive data flows. O# 15 Sandboxing or running local LLMs helps developers limit risks from AI-generated code, emphasizing containment rather than trust in AI (13%). External Guidance. External Guidance emphasizes leveraging official resources to mitigate the opacity of rapidly evolving LIDE behaviors. The primary strategy, Consult Vendors (S12), involves clarifying security guarantees and resolving functional ambiguities. In response to data privacy issues, practitioners recommended: “Request their API data privacy policy.”–13b4u1v. Complementing vendor engagement, Refer to Documentation (S13) focuses on identifying secure configuration options and intended tool behaviors. These strategies underscore the necessity of authoritative guidance and community reporting to reduce uncertainty and ensure informed LIDE adoption in complex development environments. O# 16 Developers favor following vendor-provided guidelines over relying on built-in guarantees for securing LIDEs (9%).
5
Recommendations from Lessons Learned
We offer recommendations to design security- and privacy-aware LIDEs based on the lessons learned from our study.
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Akhond et al.
Zed
Windsurf
VS Code
Warp
Trae
Replit
Roo
Kiro
JetBrains
Kilo
Copilot
Cursor
Cline
Bolt
Codeium
Feature ↓ | LIDE →
Aider
Table 5: Feature support matrix for the studied LIDEs. A shaded cell indicates IDE support for a feature.
DEBUG - Code/Bug Debugging DOCUMENT - Code Documentation REFACT - Code Refactoring TEST - Test Generation AUTOCOMPLETE - Code Completion SEARCH - Code Search EXTOOL - External Tool Execution MMI - Multi-Modal Input
Security Topics Unauthorized Unauthorized File File Operations Operations
IDE Features AUTOCOMPLETE AUTOCOMPLETE DEBUG DEBUG DOCUMENT DOCUMENT
User-Specified User-Specified ConstraintViolations ConstraintViolations Third-Party Third-Party Tools Tools Integration Integration Risks Risks Operational Operational Safety Safety Issues Issues Unsafe Unsafe Generation Generation of of Code Code
EXTOOL EXTOOL MMIN MMIN REFACT REFACT SEARCH SEARCH TEST TEST
Privacy Topics Lack Lack of of Transparency Transparency Unauthorized Unauthorized Data Data Access Access Unauthorized Unauthorized TransmisTransmission& sion& Collection Collection Privacy Privacy Leakage Leakage Violations Violations Context Context Integrity Integrity Failures Failures
Figure 12: Mapping of AI-assisted IDE features to observed security and privacy issues.
System Issues vs LLM Issues. While LLM safety has been widely studied, considerably less attention has been paid to the safety implications that emerge from integrating LLMs into IDEs. Many security and privacy failures arise not solely from the LLM’s reasoning behavior, but from how its outputs are interpreted, constrained, and executed by LIDEs. Figure 11 shows that most issues discussed in Reddit posts are attributable to insecure integration logic rather than to the mere presence of an LLM. Overall, 7 out of 10 security and privacy issues were system-level issues, and 2 were LLM-level issues (see replication package); the other one belongs to both categories. For example, unauthorized file access issues were prevalent across all LIDEs. These incidents typically occurred when the LIDE executed LLM-generated actions without enforcing developerspecified access controls. Therefore, LIDE designers need to ensure that proper security and privacy principles are adopted in their system design, irrespective of their usage of an LLM. Balancing Features vs S&P Guardrails. Table 5 outlines the features supported by LIDEs with AI/LLM-enabled capabilities (see replication package). Since identifying these features from potentially incomplete documentation poses a threat, we validated official descriptions through hands-on installation and use of popular LIDEs. While these features enhance the development workflow, AI Debugging (DEBUG), Code Completion (AUTOCOMPLETE), and External Tool Execution (EXTOOL) are the most prominent contributors to security and privacy issues (see Figure 12), collectively connected to all identified issues. Since DEBUG and AUTOCOMPLETE are ubiquitous across major LIDEs, there is a clear empirical link between widely deployed features and observed issues. Although essential for making LIDEs more proactive, these capabilities simultaneously expand the attack surface and deepen the impact of design flaws. LIDE architectures must therefore enforce proactive security and privacy guardrails as a fundamental requirement for LLM-based
feature development, ensuring productivity gains do not come at the cost of system integrity. Verification-First Code Recommendations. The proliferation of LIDEs has inverted the software development lifecycle, shifting the primary developer role from code synthesis to verification. This transition introduces a silent security debt, where unverified AI output bypasses traditional audits and violates user-specified constraints. Our analysis attributes 17.8% of security vulnerabilities to unsafe generation (O3), including vulnerable logic and hallucinated dependencies, compounded by a 16.5% rate of explicit constraint violations (O4). While practitioners advocate for treating AI output as untrusted input (S6, S2), the seamless Auto-apply features in modern LIDEs often circumvent manual scrutiny. Consequently, we contend that LIDE architectures have to incorporate a native verification layer to validate generated code against security and privacy standards before integration, ensuring both system integrity and developer liability. Promises and Perils of Coding Agents. Autonomous coding agents significantly enhance developer productivity by automating complex, multi-step engineering workflows. However, this autonomy introduces security risks through expanded system access. Our findings in Figure 12 show that External Tool Execution (EXTOOL) is responsible for 5 out of 10 identified security and privacy issues. These vulnerabilities often stem from third-party integration risks (O5). External components leverage broad permissions and opaque data flows to execute unsafe tools with minimal oversight. To mitigate these threats, the community recommends rigorous monitoring of tools and extensions to detect unauthorized behavior (S4). We argue that LIDE designers must establish a formal protocol to ensure agent trustworthiness. Similar to the Android and Apple app stores, LIDEs require a centralized compliance and verification process. This system must vet coding agents and extensions before granting them access to the development environment. Balancing Privacy vs. Contextual Integrity. Contextual integrity is vital for AI-assisted development, but it often conflicts with privacy preservation. LLM effectiveness relies on a rich context, which frequently contains sensitive data. Transparency issues and ambiguous retention policies account for 45.9% of all privacy concerns (O6), whereas AI assistants have been observed retrieving secrets or crossing project boundaries without consent (O7–O10). These data flows sometimes occur in plaintext, which reduces transparency and user control. LIDE designers must balance these competing needs during context enrichment. To protect user privacy, designers should implement sensitive file protection to prevent AI tools from accessing secrets or credentials (S8). Additionally, context isolation must restrict the sharing of memory across separate sessions or projects (S9). While data sanitization can strip sensitive information from prompts, excessive filtering often degrades model performance. Designers must therefore implement granular filters that preserve logic while masking sensitive literals to ensure secure yet accurate recommendations. Issue Mitigation Prioritization with Developer-in-the-Loop. Our observations in Section 4 show developers resorting to both proactive and reactive strategies to mitigate reported issues, with comments reflecting prevalent mistrust toward LIDEs. Designers can prioritize incorporating such strategies into their toolkits to ensure more productive, trustworthy “Dev-LIDE" collaboration. To
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs
0.70
Average Sentiment Score
0.72
Unauthorized Transmission & Collection
Lack of Transparency
0.64
0.66
0.68
Privacy Leakage Violations Unauthorized Data Access User-Specified Constraint ViolationsOperational Safety Issues Third-Party Tools Integration Risks Unsafe Generation of Code Context Integrity Failures 0
20
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
40
60
80
Number of Posts
Unauthorized File Operations
100
Security Topics Privacy Topics 120 140
Figure 13: Distribution of security and privacy issues based on user engagement and negative sentiment. Researchers evaluate LLM's effectiveness for code generation (Jiang et al. 2024, Agrawal et al. 2024) Researcher studied How Modern IDE suggestions help Developers (Jalil et al. 2023, Sergeyuk et al. 2024)
Studies found how developer productivity is boosted with LLM supported IDEs (Salma et al. 2025, Witting et al. 2025, Lyu et al. 2025,
Studies show that LLMs can unintentionally leak sensitive data... (Carlini et al. 2021, Das et al., 2025)
Studies show how AI integrated IDEs are vulnerable against attacks (Lin et al. 2024, Liu et al. 2025
Researcher explored to secure, validate and repair LLM generated code (Tang et al. 2024, Mou et al. 2025, Pearce et al. 2025, Albayral et al. 2025)
Our Work We are first to : Investigate security and privacy issues in LIDEs from unfiltered developer discussions Present a taxonomy of realworld security and privacy issues in LIDEs as directly reported by developers Generate developersuggested mitigation strategies Propose Implications for LIDE stakeholders
Figure 14: Comparison of our work with related works on LIDEs and the security of LLM-generated code support this, Figure 13 plots each reported issue as a bubble: higher position (y-axis) reflects more negative developer sentiment (scored via TimeLMs [22]), rightward position reflects more posts reporting the issue, and bubble size reflects comment volume. Bubbles higher and further right are thus more critical to developers (e.g., unauthorized file operations, transparency issues). LIDE designers must implement strict security defaults while letting users tune the privacy-performance balance (S1); since developer awareness is essential, the IDE should highlight critical security and privacy trade-offs during installation and configuration.
6
Related Works
Our related work spans three areas: LLM support in modern IDEs, the impact of LLM-powered IDEs on developer productivity, and the security and privacy implications of LLM-generated code. Figure 14 summarizes the related work and highlights our contributions. Unlike the related work, we use unfiltered Reddit discussions to understand security and privacy issues in LIDEs in their real-world use. We summarize selected related works below. LLM-native IDEs (LIDEs): The emergence of LIDEs marks a shift from rule-based assistance to probabilistic, autonomous execution environments [13, 37]. Tools such as GitHub Copilot and Cursor utilize IDE-derived static context [19] to enable multi-file reasoning and natural-language-driven task orchestration [38]. However, this architecture fundamentally expands the IDE threat model, introducing novel vulnerability classes: IDEsaster [24]. By aggregating proprietary source code, secrets, and configurations for external
transmission, LIDEs become high-value exfiltration vectors. Recent research exposes stealthy, persistent threats targeting these environments (Cuckoo Attack) [21] and exploits of overly permissive AI extensions (UntrustIDE) [20]. Complicated by the systemic technical debt inherent in ML-dependent systems [36], the LIDE architecture becomes a source for unauthorized command execution and large-scale data theft [17]. LIDEs and Developer Productivity: The integration of LLMs into IDEs has transitioned development from simple autocomplete to end-to-end assisted workflows, yielding 30–70% time savings across the software lifecycle [14, 19, 29, 38, 43]. To reliably measure these gains, execution-based frameworks now prioritize inenvironment metrics over traditional text-based benchmarks [2]. IDEs leverage LLM performance by providing repository-level static context and file references, which facilitates refactoring tasks like Extract Method and Move Method while enforcing static safety filters [6, 13, 19, 30]. However, rapid code generation creates a validation bottleneck where productivity hinges on human verification [40]. Behavioral and eye-tracking studies reveal that syntactically polished AI output often induces over-reliance, leading to overlooked logical errors and increased cognitive workloads during inspection phases [40]. Consequently, true productivity assessments must balance speed-to-completion with the mental effort required for rigorous verification and code maintainability [2, 14, 43]. Security in LLM-Generated Code: LLM-generated code frequently mirrors insecure patterns from training data, reproducing OWASP Top 10 vulnerabilities when prompted with legacy or insecure contexts [7, 9, 15, 28]. Newer models like CodeLlama and DeepSeekCoder show greater functional capability, but their security posture remains inconsistent and domain-dependent [18, 39]—particularly acute in specialized sectors, where LLM-generated PHP code often lacks proper input validation [42] and banking logic frequently fails to implement required financial security protocols [4]. These findings reveal a persistent gap where syntactically polished output masks logical flaws, increasing systemic risk to the software supply chain [1, 28]. Current assistants thus cannot be trusted for production-grade software, as they prioritize completion speed over secure logic [26], necessitating a shift where the developer moves from primary author to security auditor—a high-cognitive-effort role required to catch subtle vulnerabilities and ensure productivity gains do not compromise system integrity [4, 26, 42].
7
Threats to Validity
Construct validity may be affected by inferring security/privacy concerns from informal Reddit posts lacking configuration detail or root-cause evidence; results are thus developer-reported, not confirmed vulnerabilities. We therefore interpret our results as developer-reported issues rather than independently confirmed vulnerabilities in every case. We mitigated this via manual validation of all posts, preserved Reddit identifiers, reproduction attempts to selected posts, and a clarified security/privacy boundary from the end-user perspective. Internal validity risks LLM-filtering misclassification, especially false negatives for implicit issues; we mitigated this by freezing the filtering prompt, evaluating it on a balanced unseen validation, manually validating all LLM-positive
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
candidates, and auditing LLM-negative samples. Taxonomy validity may suffer from overlapping/multi-label categories, addressed by defining boundaries via action, asset, and mitigation implication, with multi-labeling only for explicitly distinct issues. External and temporal validity is limited by reliance on Reddit data, which may not represent enterprise use, proprietary deployments, or developers who do not publicly report issues; Counts reflect discussion patterns, not vulnerability rates or trends. Reliability may vary with evolving discussions; we report coder agreement, resolve disagreements by consensus, and share all scripts, prompts, codebooks, and artifacts. Data Availability: To ensure replication, we share all collected Reddit data. This mitigates the data availability threats that arise when/if Reddit removes/edits the posts.
8
Concluding Remarks
We present 32 security and privacy issues reported by developers in Reddit against popular LLM-native IDEs, aka LIDEs. We observe prevalent mistrust among the developers against the LIDEs, as they attempted 13 different strategies to mitigate the occurrence of such risks. We offer six recommendations to support a more secure and privacy-aware design of LIDEs. Message to LIDEs Designers: LLM outputs should undergo extensive automated verification before being recommended to developers. The LIDEs designers must treat a LIDE as a software system first, instead of developing it as simply a medium of LLM outputs. Easy access to execution logs and task planning is needed to improve transparency and traceability. Message to LIDEs Users: Developers should verify LIDEsuggested code changes before approval. They must follow established software and security engineering practices such as code review rather than “vibecoding” only. Evidence suggests that vibecoding is prone to insecure programming [10]. Message to LIDEs Researchers: The academic and industrial researchers can produce benchmarks to enable robust testing of LIDEs, by taking inspiration from LLM coding benchmarks like SWE-bench [16].
9
Data Availability Statement
The replication package with data, code, and supplementary discussion (appendix) is available at https://zenodo.org/records/21381379
References [1] Naqvi Abiha, Jain Apeksha, Goyal Avisha, and Verma Ankita. 2025. Understanding Code Quality: A Qualitative Evaluation of LLM-Generated vs. Human-Written Code. Int. J. Perform. Eng. 21 (2025), 559. [2] Anisha Agarwal, Aaron Chan, Shubham Chandel, Jinu Jang, Shaun Miller, Roshanak Zilouchian Moghaddam, Yevhen Mohylevskyy, Neel Sundaresan, and Michele Tufano. 2024. Copilot evaluation harness: Evaluating llm-guided software programming. arXiv preprint arXiv:2402.14261 (2024). [3] AI IDE List. 2025. AI IDE List. https://aiidelist.com/ide Accessed: 2025-11-02. [4] Resul Sezgin Albayrak, Meltem Kurt Pehlivanoğlu, and Nur Banu Albayrak. 2025. Evaluating Security and Quality of Banking Software Generated by Large Language Models. 2025 Innovations in Intelligent Systems and Applications Conference (ASYU) (2025), 1–7. [5] Enna Basic and Alberto Giaretta. 2024. Large language models and code security: A systematic literature review. arXiv preprint arXiv:2412.15004 (2024). [6] Abhiram Bellur, Fraol Batole, Mohammed Raihan Ullah, Malinda Dilhara, Yaroslav Zharov, Timofey Bryksin, Kai Ishikawa, Haifeng Chen, Masaharu Morimoto,
Akhond et al.
Takeo Hosomi, Tien N. Nguyen, Hridesh Rajan, Nikolaos Tsantalis, and Danny Dig. 2025. Together We are Better: LLM, IDE and Semantic Embedding to Assist Move Method Refactoring. 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME) (2025), 1–13. [7] Nicholas Carlini, Florian Tramer, Eric Wallace, Matthew Jagielski, Ariel HerbertVoss, Katherine Lee, Adam Roberts, Tom Brown, Dawn Song, Ulfar Erlingsson, et al. 2021. Extracting training data from large language models. In 30th USENIX security symposium (USENIX Security 21). 2633–2650. [8] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374 (2021). https://arxiv.org/abs/2107.03374 [9] Badhan Chandra Das, M Hadi Amini, and Yanzhao Wu. 2025. Security and privacy challenges of large language models: A survey. Comput. Surveys 57, 6 (2025), 1–39. [10] Databricks. 2024. Passing the Security Vibe Check: The Dangers of Vibe Coding. https://www.databricks.com/blog/passing-security-vibe-check-dangersvibe-coding. Accessed 2025. [11] Yujia Fu, Peng Liang, Amjed Tahir, Zengyang Li, Mojtaba Shahin, Jiaxin Yu, and Jinfu Chen. 2023. Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study. ACM Transactions on Software Engineering and Methodology 34 (2023), 1 – 34. https://api.semanticscholar.org/CorpusID: 275134491 [12] Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large language models for software engineering: A systematic literature review. ACM Transactions on Software Engineering and Methodology 33, 8 (2024), 1–79. [13] Azizkhon YUnushon Ishankhonov, Dmitrii Viktorovich Pshychenko, Evgenii Aleksandrovich Mozharovskii, and Andrei Sergeevich Aluev. 2024. The Role of LLM in Next-Generation Integrated Development Environments. Software systems and computational methods 4 (2024), 140–150. [14] Sajed Jalil. 2025. The transformative influence of llms on software development & developer productivity. In 2025 International Conference on Artificial Intelligence, Computer, Data Sciences and Applications (ACDSA). IEEE, 1–10. [15] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A survey on large language models for code generation. ACM Transactions on Software Engineering and Methodology (2024). [16] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023). [17] Ravie Lakshmanan. 2025. Researcher Uncovers 30+ Flaws in AI Coding Tools Enabling Data Theft and RCE Attacks. The Hacker News (Dec 2025). https://thehackernews.com/2025/12/researchers-uncover-30-flaws-in-ai.html. [18] Shuang Li, Yuntao Cheng, Jinfu Chen, Jifeng Xuan, Sen He, and Weiyi Shang. 2026. Performance analysis of AI-generated code: A case study of Copilot, Copilot Chat, CodeLlaMa, and DeepSeek-Coder models. Empirical Software Engineering 31 (2026). [19] Yichen Li, Yun Peng, Yintong Huo, and Michael R. Lyu. 2024. Enhancing LLMBased Coding Tools through Native Integration of IDE-Derived Static Context. 2024 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code) (2024), 70–74. [20] Elizabeth Lin, Igibek Koishybayev, Trevor Dunlap, William Enck, and Alexandros Kapravelos. 2024. UntrustIDE: Exploiting Weaknesses in VS Code Extensions. Proceedings 2024 Network and Distributed System Security Symposium (2024). [21] Xinpeng Liu et al. 2025. Cuckoo Attack: Stealthy and Persistent Attacks Against AI-Integrated Development Environments. arXiv preprint arXiv:2509.15572 (2025). [22] Daniel Loureiro, Francesco Barbieri, Leonardo Neves, Luis Espinosa Anke, and Jose Camacho-Collados. 2022. TimeLMs: Diachronic language models from Twitter. In Proceedings of the 60th annual meeting of the association for computational linguistics: System demonstrations. 251–260. [23] Yunbo Lyu, Zhou Yang, Jieke Shi, Jianming Chang, Yue Liu, and David Lo. 2025. "My productivity is boosted, but..." Demystifying Users’ Perception on AI Coding Assistants. In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE 2025). Seoul, South Korea. [24] Ari Marzouk. 2025. IDEsaster: A Novel Vulnerability Class in AI IDEs. MaccariTA blog post. https://maccarita.com/posts/idesaster/. [25] Noble Saji Mathews. 2024. Code Generation and Testing in the Era of AI-Native Software Engineering. Ph. D. Dissertation. University of Waterloo. https:// uwspace.uwaterloo.ca/items/96c98e86-e652-43d4-be27-0b21351c777d [26] Yutao Mou, Xiao Deng, Yuxiao Luo, Shikun Zhang, and Wei Ye. 2025. Can You Really Trust Code Copilot? Evaluating Large Language Models from a Code Security Perspective. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 17349–17369. [27] Hyrum Pearce, Baleegh Ahmad, Benjamin Tan, Sergei Dolgikh, Zachary Johnson, Matthew Miller, Prateek Tomar, Hassan Elahi, Adnan Habib, and Thomas Reps. 2022. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. In Proceedings of the 2022 IEEE Symposium on Security and Privacy
“Impossible to hide secret ...” : Uncovering Security and Privacy Issues in LLM-native IDEs (S&P). IEEE, 754–768. [28] Hammond A. Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2021. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. 2022 IEEE Symposium on Security and Privacy (SP) (2021), 754–768. [29] Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of ai on developer productivity: Evidence from github copilot. arXiv preprint arXiv:2302.06590 (2023). [30] Dorin Pomian, Abhiram Bellur, Malinda Dilhara, Zarina Kurbatova, Egor Bogomolov, Timofey Bryksin, and Danny Dig. 2024. Next-Generation Refactoring: Combining LLM Insights and IDE Capabilities for Extract Method. 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME) (2024), 275–287. [31] Qodo.ai. 2025. Best AI Coding Assistant Tools. https://www.qodo.ai/blog/best-aicoding-assistant-tools Accessed 2025-11. [32] Bozidar Radenkovic, Sergei Prokhorov, Milos Radenkovic, and Aleksandra Labus. 2025. Application of Large Language Models in Software Development: Review of the Current State and Development Perspectives. In 2025 6th International Workshop on Engineering Technologies and Computer Science (EnT). IEEE, 1–7. [33] Daniel Rosehill. 2025. A list of a few AI IDEs - would love additions to try! Reddit. https://www.reddit.com/r/ChatGPTCoding/comments/1imbxvq/a_list_of_ a_few_ai_ides_would_love_additions_to/ Accessed: 2025-11-02. [34] John Rush. 2025. I’ve tried all (46) AI Coding Agents & IDEs. DEV Community. https://dev.to/johnrushx/ive-tried-all-46-ai-coding-agents-ides-c2g Accessed: 2025-11-02. [35] Johnny Saldaña. 2021. The Coding Manual for Qualitative Researchers (4th ed.). SAGE Publications Ltd, London. [36] D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, and Michael Young. 2014. Machine Learning: The
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY High Interest Credit Card of Technical Debt. In SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop). [37] Agnia Sergeyuk, Sergey Titov, and Maliheh Izadi. 2024. In-IDE Human-AI Experience in the Era of Large Language Models; A Literature Review. 2024 IEEE/ACM First IDE Workshop (IDE) (2024), 95–100. [38] Faten Slama and Daniel Lemire. 2025. Enhancing Developer Productivity: Benchmarking LLM-Powered Tools like GitHub Copilot and TabNine in Real-Time Coding Environments. In 2025 IEEE 11th International Conference on Intelligent Data and Security (IDS). IEEE Computer Society, 39–45. [39] Maryam Taeb, Hongmei Chi, and Shonda Bernadin. 2024. Assessing the Effectiveness and Security Implications of AI Code Generators. Journal of The Colloquium for Information Systems Security Education (2024). [40] Ningzhi Tang, Meng Chen, Zheng Ning, Aakash Bansal, Yu Huang, Collin McMillan, and Toby Jia-Jun Li. 2024. Developer Behaviors in Validating and Repairing LLM-Generated Code Using IDE and Eye Tracking. 2024 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) (2024), 40–46. [41] Weixi Tong and Tianyi Zhang. 2024. Codejudge: Evaluating code generation with large language models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing. 20032–20051. [42] Rebeka Tóth, Tamas Bisztray, and László Erdődi. 2024. Llms in web development: Evaluating llm-generated php code unveiling vulnerabilities and limitations. In International Conference on Computer Safety, Reliability, and Security. Springer, 425–437. [43] Annemarie Wittig. 2025. The Impact of LLM-Based Coding Assistants on Developer Productivity. Master’s thesis. Leipzig University, Faculty of Mathematics and Computer Science. https://sws.informatik.uni-leipzig.de/wpcontent/uploads/2025/09/master_thesis_the_impact_of_llm_based_coding_ assistants_on_developer_productivity.pdf