Developers using AI-powered coding assistants face widespread security and privacy failures, with more than two in five security complaints involving unauthorized file operations, according to a new study from researchers at York University and the University of Calgary. The paper, titled "'Impossible to hide secret …': Uncovering Security and Privacy Issues in LLM-native IDEs" and accepted at the 41st IEEE/ACM International Conference on Automated Software Engineering, examined more than 6,000 Reddit comments to map the risks developers encounter when using tools like Claude Code, Cursor, and GitHub Copilot. The researchers conclude that makers of these AI development environments haven't built security and privacy protections into their products from the start, forcing developers to defend themselves with makeshift workarounds.
The study analyzed 446 posts drawn from 1.1 million Reddit submissions and identified a taxonomy of recurring problems. Unauthorized file operations accounted for 43.1 percent of security-related posts, with 28.3 percent describing AI tools deleting project directories or files without user approval, 8.8 percent reporting file modifications without explicit consent, and 5.7 percent noting access to content outside the active workspace. Operational safety issues—including impacts on live production services—represented 23.9 percent of security complaints, with reported incidents ranging from Replit removing a production database to Cursor deploying code despite instructions not to. Unsafe code generation made up 18.2 percent of concerns, including nine VirusTotal detections for Cursor-generated software and reports of hallucination-driven code changes after extended dialogue sessions. Privacy problems appeared in 194 posts, led by lack of transparency at 45.9 percent, unauthorized data access at 23.7 percent, and privacy leakage violations at 15.5 percent. One context integrity failure involved a Claude Desktop user receiving messages from another user's session.
According to Gias Uddin, associate professor at York University and co-author of the research, many reported issues stem from how these tools are designed and what access they're granted, not simply from the underlying models themselves. "Security and privacy mechanisms should be built into the design before a tool is given broad access to a developer's files, data, or systems," Uddin told The Register. The authors state that their 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." The paper also documents 13 mitigation strategies developers have adopted to manage risks, grouped into five approaches: configuration management at 33 percent, code governance at 31 percent, data protection and privacy control at 13 percent, isolation at 13 percent, and external guidance at 9 percent.
The researchers argue that these tools evolve rapidly under pressure to add new capabilities, which pushes security and privacy considerations down the priority list. Users can't be expected to understand which permissions pose risks, which files need protection, or whether a tool is acting improperly, Uddin explained, making it critical for tool makers to embed security into the products with safer defaults and safeguards that don't assume users are security experts. The authors offer six recommendations: requiring proper security and privacy controls from makers of AI development environments, enforcing guardrails at an architectural level, adding a verification layer to validate generated code against security and privacy standards, establishing formal protocols for assessing third-party tool trustworthiness, integrating sensitive file protection, and making strict security the default setting.
The report recommends that safer options become the starting point rather than something developers must configure themselves, with practical measures including limiting access to sensitive files by default, requiring clear approval before consequential actions, isolating projects and conversations, and making it easier to see and review what the tool is doing. "Developers should not have to discover after something goes wrong that a tool had more access or freedom than they expected," Uddin said. The authors note that developers already use many of these safeguards in ad hoc ways and believe several should be built into the tools and enabled by default. The velocity of adoption will likely continue outpacing the maturity of trust frameworks, creating a widening gap between what these assistants can do and what organizations can safely allow. Enterprises will face mounting pressure to choose between productivity gains and the governance overhead required to prevent the kind of incidents already surfacing in developer communities.