Apiiro tracked 7,000 developers across 62,000 repositories in 2025 and found that AI coding assistants introduced over 10,000 new security findings a month, a 10x jump in just six months. Developers shipped code 4x faster. They also shipped privilege escalation paths 322% more often and leaked cloud credentials nearly twice as often as developers who wrote code by hand.
That is the deal you make every time you hit "Accept All" on an AI-written diff. You get speed. You also get a new kind of security risk that didn't exist two years ago. It ranges from hallucinated packages that attackers squat on, to MCP configurations that quietly swap in malicious payloads, to AI agents that collect permissions like a developer who never logs out.
This guide covers the specific security risks AI coding agents bring in 2026, the data behind them, and what you can really do about them without giving up the productivity gains.
Apiiro: 10,000+ new findings a month across 62,000 repos, a 10x spike in six months.
What do you need?
- Familiarity with at least one AI coding tool: Cursor, Copilot, Claude Code, Windsurf or similar.
- A working codebase. The risks in this article are concrete, not theoretical.
- Access to a SAST/DAST tool: Snyk, SonarQube, Semgrep or similar static analysis.
- A package manager: npm, pip, cargo and so on. You will want to audit your dependencies.
- 30 minutes to check your current AI coding workflow against the checklist at the end.
What do the vulnerability studies actually say?
Let's start with the numbers, because the talk about AI-generated code security ranges from "it's fine" to "we're all doomed." The truth is in the data.
Veracode: a 45% security failure rate
In 2025, Veracode tested code generated by more than 100 LLMs across Java, JavaScript, Python and C#. The result: AI-generated code introduced risky security flaws in 45% of tests. Java was the worst, with a 72% security failure rate across tasks. That isn't a rounding error. Nearly three out of four Java snippets from an LLM had a security flaw.
Apiiro: a 10x jump in vulnerabilities at scale
The Apiiro study is the most thorough look at AI-generated code in production. It covers 62,000 repositories with heavy GitHub Copilot use:
| Metric | Finding |
|---|---|
| Security findings per month | 10,000+ (a 10x rise in 6 months) |
| Privilege escalation paths | Up 322% |
| Architectural design flaws | Up 153% |
| Exposed secrets and credentials | 2x more frequent |
| PII and payment data exposure | A 3x surge |
| APIs missing auth or validation | A 10x rise |
| Syntax errors | Down |
| Logic bugs | Down |
Notice the pattern. AI tools are great at surface-level code quality, with fewer typos and fewer obvious bugs. But they are worse at the things that really get you breached: authorization logic, secret handling and design decisions.
CodeRabbit: specific vulnerability multipliers
CodeRabbit's December 2025 analysis measured how much more likely AI-generated code is to introduce specific kinds of vulnerabilities, compared with human-written code:
These are OWASP Top 10 staples, not obscure edge cases.
| Vulnerability type | AI vs. human likelihood |
|---|---|
| XSS vulnerabilities | 2.74x more likely |
| Insecure object references | 1.91x more likely |
| Improper password handling | 1.88x more likely |
| Insecure deserialization | 1.82x more likely |
These aren't obscure edge cases. XSS and insecure direct object references are OWASP Top 10 staples. Your AI coding agent is almost three times more likely to write code that is open to cross-site scripting than you are.
What are slopsquatting and hallucinated packages?
Traditional supply chain attacks rely on typosquatting: register reqeusts and hope someone misspells requests. AI coding agents brought a whole new version: slopsquatting.
How does slopsquatting work?
LLMs hallucinate. When they make up package names, they don't generate random strings. They generate plausible-sounding packages that don't exist. A 2025 study across 756,000 code samples found that nearly 20% recommended packages that don't exist. Attackers register these made-up names on PyPI, npm or crates.io and load them with malware.
58% of hallucinated names repeat across queries, so attackers can predict which ones to register.
The numbers are alarming
| Finding | Stat |
|---|---|
| LLM hallucination rate for packages | ~20% of recommendations |
| Open-source models (DeepSeek, WizardCoder) | 21.7% hallucination rate |
| Commercial models (GPT-4) | 5.2% hallucination rate |
| Hallucinations repeated across queries | 58% repeated more than once |
| Hallucinations with names close to real packages | 38% |
That 58% repetition rate is the real danger. If an LLM keeps making up the same package name, attackers can predict which fake packages to register. It is predictable, exploitable and scalable.
A real-world example
In 2024, a researcher noticed AI models repeatedly hallucinating a Python package called huggingface-cli. They registered it on PyPI as an empty package. It got 30,000+ downloads in three months, all from developers (or their AI tools) blindly installing what the model suggested.
Now imagine that package hadn't been empty.
How do you defend against slopsquatting?
- Lock your dependencies. Use
package-lock.json,Pipfile.lockorCargo.lock. Review every new dependency before it enters the lockfile. - Use dependency scanning tools. Socket, Snyk and npm audit can flag suspicious packages based on how they behave, not just on known CVEs.
- Verify before you install. Check the package registry page. Look at download counts, maintainer history and when the package was first published.
- Pin exact versions. Don't use
^or~version ranges for packages you haven't vetted thoroughly.
What are MCP and tool poisoning?
If you use Cursor, Claude Code or any agent that supports the Model Context Protocol (MCP), you have a new attack surface that didn't exist before 2025.
MCPoison: silent code execution through Cursor
In August 2025, Check Point Research disclosed MCPoison (CVE-2025-54136), a vulnerability affecting over 100,000 Cursor users. Here is how the attack worked:
- An attacker adds a harmless-looking MCP configuration (
.cursor/rules/mcp.json) to a shared repository. - A developer pulls the code and approves the MCP config in Cursor (a one-time prompt).
- The attacker replaces the MCP configuration with a malicious payload.
- Cursor runs the malicious code every time the developer opens the project, without asking for approval again.
Fixed in Cursor 1.3 (July 2025). Treat MCP configs like .env files.
The vulnerability broke Cursor's trust model. Once you approved an MCP config, Cursor assumed it would stay trustworthy forever. But the file underneath could be swapped silently at any time.
What is the wider MCP risk?
MCP is how AI coding agents connect to outside tools such as databases, APIs, file systems and cloud services. Every MCP connection is an identity with credentials and permissions. The OWASP Top 10 for Agentic Applications (released December 2025) ranks these risks specifically:
| OWASP Agentic AI rank | Risk | Relevance to coding agents |
|---|---|---|
| #1 | Agent Goal Hijacking | Poisoned inputs redirect agent behavior |
| #2 | Identity and Privilege Abuse | Agents pile up excessive permissions |
| #3 | Unexpected Code Execution (RCE) | MCPoison-style attacks |
| #6 | Tool Misuse and Exploitation | MCP tools used beyond their intended scope |
| #7 | Agentic Supply Chain Vulnerabilities | Compromised MCP servers and extensions |
| #8 | Memory and Context Poisoning | Lasting manipulation across sessions |
How do you defend against MCP attacks?
# Check for MCP configurations in any repo you clone
find . -name "mcp.json" -o -name ".mcp" -o -name "mcp.yaml" | head -20
# Review what MCP servers your IDE connects to
# In Cursor: Settings → MCP → Review active servers
# In Claude Code: Check ~/.claude/mcp_servers.json
Practical steps:
- Audit MCP configs after every
git pull. Don't assume approved configs stay safe. - Use allowlists for MCP servers. Only connect to servers you have explicitly vetted.
- Update your IDE. Cursor patched MCPoison in version 1.3 (July 2025). If you are on an older version, you are exposed.
- Treat MCP configs like
.envfiles. Review them as carefully as you would credentials.
What does your AI agent know, and share?
Every AI coding agent needs context to work. That context includes your source code, your environment variables, your database schemas and sometimes your customer data. The question is where that context goes.
What is the shadow AI problem?
A 2025 survey found that 48% of employees admitted uploading company data into public AI tools that security teams never approved. For developers, that means:
- Pasting proprietary code into ChatGPT or Claude.ai to debug it.
- Using free-tier AI coding tools that send code to third-party servers.
- Installing unvetted IDE extensions that route code through unknown APIs.
What gets leaked?
| Data type | How it leaks | Risk level |
|---|---|---|
| API keys and secrets | Included in code context sent to the AI | Critical |
| Database connection strings | In config files the agent reads | Critical |
| Customer PII | In test fixtures or seed data | Critical |
| Proprietary algorithms | Sent as context for refactoring | High |
| Internal architecture docs | Referenced in prompts | High |
.env file contents |
Included automatically by some agents | Critical |
How do you reduce data exposure?
- Use ignore files. Many AI coding tools support ignore files that keep sensitive folders out of indexing. Cursor has
.cursorignore. Check your own tool's docs for its equivalent, since the names and rules differ. In Claude Code, for example, you can block the agent from reading files through its permission settings.
# Example ignore file (Cursor calls it .cursorignore; check your tool's docs for its own name)
.env
.env.*
secrets/
*.pem
*.key
config/credentials/
test/fixtures/customer_data/
-
Know what your tool sends. Read your tool's data handling and privacy-mode settings before you use it on sensitive code. Cursor offers a Privacy Mode. Whatever you use, find out where your context goes and how long it is kept.
-
Separate test data from production data. Don't use real customer data in your test fixtures. Use synthetic data generators like Faker.
-
Check your agent's context window. Most tools let you see which files are in the current context. Review this before you ask the agent to help with sensitive code.
.gitignore.
What is the AI security mitigation checklist?
Here is the practical checklist. Print it, pin it and make it part of your code review process. Each item maps to a specific risk covered above.
Print it, pin it, and make it part of code review.
Code quality
- [ ] Run SAST on every AI-generated PR. Tools: Semgrep, SonarQube, Snyk Code.
- [ ] Never merge AI-generated code without human review. Especially for auth, crypto and data handling.
- [ ] Add security-focused unit tests. Test for SQL injection, XSS, path traversal and IDOR in AI-generated code.
- [ ] Check for hardcoded credentials. AI models love to include example API keys that look suspiciously real.
- [ ] Validate authorization logic by hand. AI-generated code is 10x more likely to skip input validation.
Supply chain
- [ ] Verify every new dependency before adding it. Check registry pages for download count, creation date and maintainer.
- [ ] Use lockfiles religiously.
package-lock.json,Pipfile.lock,Cargo.lock. - [ ] Turn on dependency scanning in CI. Socket, Snyk or npm audit on every build.
- [ ] Be skeptical of AI-suggested packages you have never heard of. If it sounds plausible but you can't find docs, it might be hallucinated.
- [ ] Pin exact versions for any dependency the AI suggested.
Agent and tool security
- [ ] Audit MCP configurations after every
git pull. Diffs should include MCP file changes. - [ ] Apply least privilege to agent permissions. Don't give your AI agent write access to production databases.
- [ ] Keep your IDE and AI extensions updated. Security patches ship regularly.
- [ ] Review agent tool connections. Know every outside service your agent can reach.
- [ ] Use allowlists for MCP servers. Block unknown servers by default.
Data protection
- [ ] Set up ignore files or deny rules before you start any session.
- [ ] Never paste secrets into AI chat interfaces. Use environment variables, not inline credentials.
- [ ] Use synthetic test data. Never let real customer PII into your AI agent's context.
- [ ] Audit what your agent sends to the API. Turn on logging if your tool supports it.
- [ ] Prefer tools with SOC 2 compliance and clear data retention policies.
What is OWASP's Agentic AI Top 10?
In December 2025, OWASP released the Top 10 for Agentic Applications, the first security framework designed specifically for AI agents. This matters because the existing OWASP Top 10 for LLMs focuses on the model itself, while the Agentic Top 10 focuses on what happens when that model has tools, permissions and autonomy.
Here is the full list, with what it means for developers using AI coding tools:
| # | Risk | What it means for you |
|---|---|---|
| 1 | Agent Goal Hijacking | A poisoned email, doc or web page can redirect your agent's behavior |
| 2 | Identity and Privilege Abuse | Your agent's API keys become attack targets |
| 3 | Unexpected Code Execution | MCPoison-style attacks that run arbitrary code |
| 4 | Insecure Inter-Agent Communication | Multi-agent systems can be manipulated at handoff points |
| 5 | Human-Agent Trust Exploitation | You trust your agent's output more than you should |
| 6 | Tool Misuse and Exploitation | Agents use connected tools beyond their intended scope |
| 7 | Agentic Supply Chain Vulnerabilities | Compromised extensions, plugins and MCP servers |
| 8 | Memory and Context Poisoning | Malicious data lasts across agent sessions |
| 9 | Cascading Failures | One agent's mistake spreads through a chain of dependent agents |
| 10 | Rogue Agents | Agents operating outside their intended limits |
The theme across all 10 risks is the same: autonomy without oversight. The more you let your AI coding agent do without checking its work, the more surface area you expose.
What is the practical takeaway?
You don't need to deal with all 10 risks today. Start with three:
The theme across all ten risks: autonomy without oversight.
- Least privilege (#2). Don't give your agent credentials it doesn't need. If it is writing frontend code, it doesn't need database admin access.
- Human review (#5). Every AI-generated change should be reviewed by a person before it reaches production. No exceptions for "small" changes.
- Supply chain hygiene (#7). Vet your MCP servers, IDE extensions and AI-suggested dependencies as carefully as you would any third-party code.
Frequently Asked Questions
What security risks do AI coding agents introduce?
Four main kinds: vulnerable generated code, supply chain attacks through hallucinated packages, MCP and tool poisoning, and data leakage. Apiiro tracked 7,000 developers across 62,000 repositories in 2025 and found that AI assistants introduced over 10,000 new security findings a month, a 10x jump in six months.
Does AI-generated code actually contain more vulnerabilities?
The data says yes. Developers using AI assistants shipped code 4x faster, but they also introduced privilege escalation paths 322% more often and leaked cloud credentials nearly twice as often as developers who wrote code by hand.
What is slopsquatting?
Slopsquatting is when attackers register package names that AI models make up. Models often invent plausible-sounding dependencies that don't exist. An attacker publishes that exact name, and the next developer who accepts the AI's import installs malware. It is a supply chain attack created entirely by the model's own invention.
What is MCP tool poisoning?
Tool poisoning is when a malicious or tampered MCP server changes its tool descriptions to trick an agent into actions nobody intended, or quietly swaps in a malicious payload. The agent trusts tool descriptions the way it trusts its own instructions, so a compromised server can redirect its behavior without touching your code.
How do I use AI coding agents without giving up the productivity gains?
Check that every package an agent suggests really exists before you install it. Scan MCP servers before you connect them. Review diffs instead of accepting everything. Give agents credentials with the least privilege they need. And use OWASP's Agentic AI Top 10 as your checklist. None of this slows you down enough to cancel the 4x speed gain.
What should you do next?
AI coding agents aren't going away. They are getting more autonomous, more integrated and more powerful, and the security landscape will keep changing. Here is where to focus next:
- Build security scanning into your CI/CD pipeline so AI-generated code gets the same scrutiny as human-written code, automatically.
- Adopt the OWASP Agentic AI Top 10 as a way to judge your AI coding tool setup, starting with least privilege and human review checkpoints.
- Explore AI-assisted code review tools that use AI to catch the security issues other AI tools introduce. It is fighting fire with fire, but on purpose. See our guide on AI Code Review Tools.
- Stay current on MCP security as the protocol matures and more tools adopt it. The attack surface is growing, and so are the defenses.
- Re-evaluate your tool choices now and then. Security posture varies a lot between AI coding tools, and updates ship often. Our AI Coding Agents Compared guide has the latest.
Want to understand how these AI coding tools work before you worry about their security risks? Start with our AI Coding Agents Compared guide for a practical breakdown of Cursor, Copilot, Claude Code and Windsurf, then come back here to lock them down. For the bigger picture on how AI is changing software engineering roles, read The Rise of the AI Engineer.