The More Access AI Coding Agents Have, the More Dangerous They Become

The security risks of AI coding tools are no longer limited to generating a few bugs.

According to a study disclosed on August 13, researchers from the University of York and the University of Calgary analyzed thousands of Reddit discussions about coding AI and found that AI agents with access to file systems, terminals, and third-party services have already caused incidents involving overwritten files, deleted critical data, unauthorized data access, and even the generation of malicious code.

Cursor was the tool with the most reported issues in the sample, followed by products or tool tags such as Claude, Codex, Copilot, Windsurf, VSCode, Replit, and Cline. Cursor-related discussions focused more heavily on runtime security and unauthorized data access, while Claude-related issues were more often associated with the risks of third-party tool integrations.

The study’s most important conclusion is not which tool ranked first, but that the boundaries of risk for AI coding tools have shifted: in the past, models gave incorrect advice; now, they can directly execute incorrect actions.

When AI goes from “telling you what to do” to “doing it for you,” permissions matter more than intelligence.

More Than 6,000 Comments Do Not Equal More Than 6,000 Incidents

Using a crawler, the research team collected 3,801 popular Reddit posts tagged with large language model-related labels between February 2023 and March 2026. From these, it selected 446 posts related to coding AI security and analyzed more than 6,000 user comments beneath them.

In terms of timing, the highest concentration of related issues appeared around the summer of 2025, peaking in July 2025. This timing is unsurprising: during that period, AI coding products broadly shifted from code completion and chat-based Q&A toward agent mode, beginning to proactively search repositories, modify multiple files, run tests, and invoke terminals.

It is important to emphasize that more than 6,000 comments do not represent more than 6,000 verified security incidents. The content includes incident descriptions, issue reproductions, experience sharing, and responses from other users. It is a sample of community discussions, not a vendor vulnerability database.

Likewise, “Cursor had the most issues” does not directly imply that “Cursor is the least secure.” A tool’s user base, rate of agent feature adoption, community activity, and post-tagging conventions can all affect how frequently it appears in the sample. The study provides risk signals and feedback from real-world use, not a security ranking normalized by installation base.

However, sample bias does not change the more critical fact: the problems developers encounter have expanded from “poor code quality” to “agents damaging real environments.”

The Most Dangerous Capability of an Agent Is Not Writing Code, but Executing It

A traditional coding assistant is more like a colleague sitting beside you. It can suggest changes, but whether those changes enter the repository usually still depends on the developer copying, reviewing, and committing them.

A coding agent, by contrast, is more like a contractor who has been given an access badge, a terminal, and server privileges. To complete a one-sentence request such as “fix this issue,” it may independently perform the following steps:

1. Scan the entire code repository;
2. Read configuration files and environment variables;
3. Modify multiple source files;
4. Install new dependencies;
5. Execute shell commands and project scripts;
6. Connect to databases or third-party services;
7. Create commits, push branches, or even trigger deployments.

These capabilities are precisely what make agents more efficient—and what rapidly expands the blast radius of accidents.

When an ordinary model hallucinates, the worst it usually does is provide an incorrect answer. When an agent with write and terminal access hallucinates, it can turn that incorrect answer into file changes, database migrations, and production operations.

Compounding the problem, natural-language tasks provided by users often lack strict boundaries. For example, does “clean up old files in the project” mean deleting build artifacts and obsolete scripts, or business-critical code that the agent independently decides is “no longer used”? Does “fix the database tests” authorize resetting the local database? If an environment variable happens to point to a testing or production instance, the consequences can be entirely different.

The model may not be “attacking” the user. Many incidents arise precisely because the agent is overly proactive in completing the task: to make tests pass, it may delete failing test cases; to eliminate type errors, it may rewrite interfaces; to resolve dependency conflicts, it may upgrade an entire set of packages. The objective appears to have been achieved, but the system boundaries have been altered along with it.

Excessive Permissions Amplify Multiple Risks

The file overwrites, deletion of critical data, unauthorized access, and generation of malicious code mentioned in the study may appear to be different problems, but they often share the same prerequisite: the agent has been granted more permissions than the current task requires.

The First Layer Is File-System Access

Many local coding agents can read and write the entire project directory by default. If the project directory contains uncommitted files, private keys, data exports, debugging logs, or production configurations, the agent’s search scope may extend beyond the source code itself.

Git is not a universal safety net. Untracked files, ignored data directories, local databases, and configuration files outside the repository cannot necessarily be restored with git reset. Even if the code can be rolled back, overwritten data and information already sent to external services cannot be recovered.

The Second Layer Is Command-Execution Access

Terminal access turns model output into system behavior. Dangerous operations include not only obvious recursive deletions, but also dependency installation scripts, database migrations, container cleanup, force pushes, and cloud-service commands.

If a tool displays confirmation dialogs only for a handful of high-risk commands, the defense remains fragile. The same outcome can be achieved through different combinations of commands, while scripts may invoke additional programs internally. A security system must assess the consequences of an operation rather than merely match command strings.

The Third Layer Is Credential and Network Access

Once an agent can read environment variables, SSH configurations, cloud-platform credentials, and package-manager tokens, it is no longer merely a local development tool. It may connect to external APIs, retrieve private dependencies, or send context to third-party tools.

This also explains why third-party integrations have become a distinct risk category. Each additional MCP service, plugin, browser, database connector, or automated deployment platform extends the chain of trust. The fact that the primary model itself has not been compromised does not mean the entire invocation chain is secure.

The Fourth Layer Is Production Access

Production access, in particular, should never be tied to developer convenience. When an agent can access a production database, cloud console, or release pipeline, a single error in judgment can escalate from a “code issue” into a business incident.

Enterprises have traditionally used Zero Trust to restrict employees and service accounts, yet they may pass all of a developer’s existing permissions directly to the model simply to ensure that an agent runs smoothly. This effectively bypasses years of permission-layering practices and places a nondeterministic decision-making component in a privileged execution path.

Why Traditional Approval Dialogs Are Not Enough

Many products control risk through “confirm before execution” prompts, but the confirmation button itself can easily become a new formality.

When an agent requests permission every few dozen seconds, developers quickly develop the habit of clicking through. More practically, users may see only a command—not which directories it will access, which files it will modify, or which network address it will connect to.

An effective authorization prompt should answer at least four questions:

• What is the agent preparing to do?
• Why does the current task require this operation?
• Which resources will the operation affect?
• Can the operation be reversed if something goes wrong?

For example, “run tests” and “execute a test script that rebuilds the database” should not display the same level of confirmation. Nor should “modify three source files” and “delete 800 files” share the same generic write permission.

A more sensible design would bind permissions to a single task and specific resources rather than having users grant permanent access all at once. The following is a simplified policy example; it is not the actual configuration of any particular product:

agent_policy:
  filesystem:
    read:
      - ./src/**
      - ./tests/**
    write:
      - ./src/**
      - ./tests/**
    deny:
      - ./.env*
      - ~/.ssh/**
      - ./data/production/**
  shell:
    allow:
      - npm test
      - npm run lint
    require_approval:
      - dependency_install
      - database_migration
      - git_push
      - file_delete
  network:
    default: deny
  credentials:
    inherit_host_environment: false
  session:
    expires_in: 30m

The syntax is not the point. What matters are three principles: grant permissions per task, restrict them by resource, and revoke them immediately after use.

Enterprises Should Treat Agents as Privileged Digital Employees

For individual developers, the most practical protection is not to stop using agents, but to reduce the blast radius of each operation.

1. Run Them in Isolated Environments by Default

Agents should preferably run in containers, virtual machines, remote development environments, or temporary worktrees. They should not directly inherit all directories and credentials from the host machine. File changes should be merged back into the main workspace only after their diffs have been reviewed.

A sandbox must isolate more than files. To avoid a fake sandbox that “runs in an isolated directory but still has access to every token,” external network access should be disabled by default, process privileges should be restricted, and access to host environment variables should be blocked.

2. Authorize Reading, Writing, Execution, and Network Access Separately

“Allow access to the project” is far too broad a permission. Reading source code, writing files, executing commands, accessing the network, and using credentials should be treated as five distinct capabilities.

Most code-explanation tasks require only read access; small-scale refactoring requires limited write access; running tests requires command-execution access; and looking up documentation may require network access, but should not therefore grant the ability to upload arbitrary data.

3. Establish Hard Boundaries for High-Risk Operations

Deleting files, modifying lockfiles, installing dependencies, executing package-manager scripts, performing database migrations, force-pushing, accessing production environments, and sending external requests should all be classified as high-risk operations.

These “hard boundaries” cannot rely solely on the model’s discretion. A model stating “this is safe” does not constitute proof of safety. Interception should occur at the agent runtime, with an independent policy layer deciding whether to allow the operation.

4. Preserve Complete Execution Traces

Traditional software can be reviewed through its source code, but an agent’s specific sequence of actions is generated dynamically at runtime. Even when the same task is run again, the steps may differ.

Logs should therefore record at least the user’s original request, model decisions, tool calls, command parameters, current directory, network destinations, file diffs, approvers, and final results. Otherwise, after an incident, a team may see only that “the files are gone” without being able to reconstruct why they were deleted.

These execution traces are not ordinary chat histories. Conversation records tell you what the agent said; execution records tell you what the agent actually did.

5. Completely Isolate Production Credentials

A developer’s own production access should not automatically be inherited by their local agent. Agents should use separate identities, short-lived credentials, and revocable tokens, with access limited to the resources required for the current task.

Agents used by different employees should not share a single privileged account either. Otherwise, an enterprise cannot distinguish who initiated a task or which agent performed an operation—and cannot quickly revoke an individual session when anomalous behavior occurs.

6. Defend Against Prompt Injection from Repository Content

Agents read README files, issues, code comments, web pages, and responses from third-party tools. All of this content may contain text designed to induce the model to perform additional actions. To the model, such content is both data and something that may be mistakenly interpreted as instructions.

External content must therefore not automatically receive the same level of trust as user instructions. Instructions originating from repositories, web pages, or tool responses should not directly trigger operations such as credential access, network connections, deletion, or deployment.

Cursor Ranking First Should Not Be the Study’s Only Headline

The fact that Cursor had the highest number of reported issues certainly deserves the vendor’s attention, especially when runtime security and unauthorized data access have already affected production environments. But focusing solely on product rankings makes it easy to miss the study’s more important warning for the industry as a whole.

The problem is not that a particular model suddenly became malicious. Rather, over the past year or so, coding products have rapidly pursued autonomous execution capabilities while their security architectures have remained stuck in the era of chat assistants. Many tools use a single “auto-run” switch to bundle authorization for reading files, modifying code, executing terminal commands, and invoking external services. Developers gain a seamless experience, but lose fine-grained control at the same time.

The more popular a tool is, the higher its agent adoption rate, and the greater its level of automation, the more reported issues it may naturally attract. A truly fair comparison would need to account for active user counts, the number of agent tasks, default permission settings, incident severity, and recovery costs—not merely the number of posts.

But vendors cannot attribute every problem to user volume. A mature coding agent’s security capabilities should evolve in step with its generation capabilities. Whether sandboxing is enabled by default, dangerous commands can be blocked by a policy layer, permissions are scoped per task, third-party tools require separate authorization, and execution can be fully audited should all become dimensions of product competition.

The Next Battleground in AI Coding Is Control

Over the past two years, coding models have primarily competed on benchmarks, code-generation rates, and task-completion rates. In the agent era, it is no longer enough to ask only “how many tasks did it complete?” We must also ask what it changed and accessed to complete them, and how much damage it can cause when it fails.

An agent with a higher completion rate but full access to an entire computer by default may be less suitable for production than a slightly slower tool whose every step can be audited and rolled back.

This study of thousands of community discussions does not prove that any particular product is necessarily more dangerous. It does, however, bring an industry-wide shift into the open: the central tension in AI coding incidents is moving away from whether models make mistakes and toward whether systems allow models to carry those mistakes through to execution.

Model errors cannot be eliminated in the short term. What engineering can control are permissions, isolation, approvals, auditing, and recovery. Any vendor that still treats these capabilities as enterprise-edition add-ons rather than the default foundation of an agent may continue paying for experimentation with users’ data and production environments.

For developers, the simplest rule of thumb is straightforward: if the worst outcome of a routine coding task failing is not merely discarding the current diff, but potentially affecting credentials, databases, or production systems, then the agent already has too much access.

References

• ITHome: 6,000+ Comments Reveal Real-World Security Incidents Involving AI Coding Agents—Introduces the sample size, tool distribution, and primary risk categories identified by the University of York and University of Calgary research team.
• Zhihu: Key Security Risks Facing AI Agents and How Enterprises Should Respond—Provides additional security practices related to data leakage, access control, and enterprise-wide lifecycle governance.