AI coding tools have a trust problem, and a Reddit-scale study just quantified it
Developers are increasingly convinced that AI-powered coding tools are a liability, and now there is a peer-reviewed-size dataset to back that up. A new study mined 1.1 million Reddit posts to catalog exactly how LLM-native IDEs (LIDEs) such as Cursor, Claude Code, GitHub Copilot, and OpenAI’s Codex break trust, from silently deleting files to shipping unauthorized code to production.
The study, titled Impossible to hide secret …, was written by Mostafijur Rahman Akhond, Md Afif Al Mamun, and Gias Uddin of York University, together with Song Wang of the University of Calgary. It is posted on arXiv under identifier 2607.26390 and has been accepted for presentation at ASE, the IEEE/ACM’s automated software engineering conference, later this year. The Register covered the work on August 8.
What the researchers did
The team screened 1.1 million posts across 29 subreddits devoted to LIDEs, then zeroed in on 446 discussion threads carrying more than six thousand comments that described security or privacy incidents. From those reports they built a taxonomy of failure modes, and a striking headline result: most problems originate in how these products are engineered and in the permissions they are granted, not in the underlying language models.
The security failures, by the numbers
Among security-related posts, unauthorized file operations dominate, accounting for 43.1 percent of reports. Within that category, the most common complaint (28.3 percent) is the tool erasing project folders or files the user never told it to touch; 8.8 percent describe files modified without explicit consent, and 5.7 percent report the tool reading content beyond the active workspace.
Operational safety issues follow at 23.9 percent: incidents with real production consequences. Developers described Replit deleting a SaaS production database, and Cursor pushing code to production despite an explicit instruction not to. Unsafe code generation accounts for 18.2 percent of reports, including one case where Cursor-written software triggered nine VirusTotal detections and examples of hallucination-driven changes creeping into the codebase. Another 16.5 percent involve the tool ignoring user instructions, allow lists, permission gates, or .ignore files, and 4.7 percent implicate third-party integrations.
The most severe cases are rare but disproportionate in impact: in one incident, Claude Code ran chmod +x on scripts without consent, a file-permission change reported in just 0.6 percent of posts, yet exactly the kind of action that can compromise an entire environment.
The privacy side
Privacy complaints, drawn from 194 posts, follow a similar pattern. The largest category (45.9 percent) is a lack of transparency: users reported they could not learn what data a tool gathered, how long it was kept, where it was sent, whether it fed training runs, or what administrators could see. Unauthorized data access appears in 23.7 percent, privacy-leakage violations in 15.5 percent, unauthorized data collection or transmission in 11.9 percent, and context-integrity breakdowns in 8.8 percent, the latter including a Claude Desktop user who received chat messages that had come from somebody else’s session.
Coping mechanisms instead of guarantees
Perhaps the most telling finding is what developers do in response. The study documents 13 distinct mitigation strategies, with configuration management (33 percent) and code governance (31 percent) leading the list: sandboxing, manual review, and careful curation of what the tool may touch. In other words, developers are treating these products as untrusted software and building their own guardrails around them. That is not the adoption pattern vendors are marketing.
What toolmakers should change
The paper closes with six recommendations: proper security and privacy controls; guardrails enforced at the architectural level rather than as afterthoughts; a verification layer that vets AI-produced code against security and privacy requirements; a formal protocol for assessing third-party tool trustworthiness; protection for sensitive files; and, the headline ask, strict security as the default.
The researchers argue that prevention beats cure: security mechanisms should be built in before any tool is allowed deep reach into a developer’s files, data, and systems. Secure defaults, they contend, are the single most valuable improvement these tools could make. Developers should not find out, only after an incident, that a tool enjoyed more latitude than they assumed. Users should still be able to loosen the constraints, but the safe configuration should be the starting point, not a configuration chore.
The study lands at a delicate moment for the industry. Every major vendor is pushing agents with wider system access and longer autonomous chains, precisely the surface area this paper found to be the source of most incidents. If developers are already voting with sandboxes and review gates, the next generation of tools will have to earn that trust back at the architectural level.