You trust your AI coding assistant. It writes clean functions, handles edge cases, drops helpful comments. The code compiles, the tests pass, the pull request — a proposal to merge new code into the main project — gets a thumbs up. Three months later, a security tester finds a hole in a function your agent wrote at 2 AM. Nobody questioned it because it "looked fine."

This is not a thought experiment. This is Tuesday.

The gap between confidence and competence

AI-generated code now accounts for roughly 46% of new code at many companies. You cannot avoid it. But somewhere between "the AI wrote it" and "we shipped it," a dangerous assumption crept in: that the machine knows what it is doing. It does not. It is a very fast typist with no concept of attackers.

You need a field manual. Here is yours.

One in four snippets has a hole in it

In February 2026, security research group AppSecSanta tested six major LLMs — large language models, the brains behind ChatGPT, Claude, Gemini and friends — across 89 security-focused coding prompts. Python and JavaScript. Real-world tasks mapped to the OWASP Top 10 — a widely accepted list of the most critical web application security risks.

The result: 25.1% of generated code contained confirmed vulnerabilities. One in four snippets. Your AI writes bugs at industrial scale, and it does it with the calm confidence of someone who has never been hacked.

Vulnerability rates by model:

Model Vuln rate
GPT-5.2 19.1% (best)
Gemini 2.5 Pro 22.4%
Grok 4 23.7%
Claude Opus 4.6 29.2%
DeepSeek V3 29.2%
Llama 4 Maverick 29.2%

That 10-point spread means your model choice matters. But even the best model ships a vulnerability in nearly one out of five outputs. Choosing GPT-5.2 over Llama 4 helps. It does not save you.

Where models fail most:

  • SSRF (Server-Side Request Forgery — when your server gets tricked into calling internal URLs on behalf of an attacker): 32 findings. The single biggest category.
  • Injection (SQL injection, command injection — when user input sneaks into database queries or system commands): 30 findings, 33.1% of all issues.
  • Security misconfiguration: 25 findings — hardcoded secrets, debug mode left on in production.
  • Broken access control (letting users do things they should not be allowed to do): present across every model tested.

A separate Help Net Security study from March 2026 tested Claude Code, OpenAI Codex, and Google Gemini in agent mode — not just autocomplete, but fully autonomous coding. The agents produced 143 security issues across 38 scans covering 30 pull requests. 87% of those PRs contained at least one vulnerability. Broken access control appeared in every single agent's output. Every. Single. One.

Why the machine writes insecure code

The models are not malicious. They are probability machines trained on GitHub, and GitHub is full of insecure code. Stack Overflow answers from 2015 that hardcode JWT secrets (JWT — JSON Web Token, a digital pass that proves you are logged in). Tutorial code that skips input validation because "this is just a demo." Production code from companies that never ran a security audit.

Three patterns keep showing up:

1. Missing server-side validation. AI agents accept client-side values — scores, balances, user roles — without verifying them on the server. The model learned from thousands of tutorials that "left validation as an exercise for the reader." The reader never did the exercise. Neither did the AI.

2. Insecure defaults. JWT tokens without expiration dates. OAuth implementations (OAuth — a protocol that lets you "Sign in with Google" instead of creating yet another password) missing the state parameter that prevents hijacking. Refresh tokens that cannot be revoked. The models generate code that works but picks the lazy default, not the secure one.

3. SSRF everywhere. When a model writes code that fetches a URL, it almost never checks where that URL points. No allowlists, no blocking of internal IP addresses, no restrictions on the protocol. It just calls requests.get(user_input) and ships it. An attacker feeds it http://169.254.169.254/ and suddenly has your cloud credentials.

Your five-layer defense stack

Stop waiting for models to get smarter about security. Build a pipeline — an automated sequence of checks — that catches problems regardless of who or what wrote the code.

Layer 1: Security-focused prompting

The simplest fix costs nothing. A Veracode study found that adding a generic security reminder to your prompt improved the rate of secure code from 56% to 66% for Claude Opus 4.6. Ten percent improvement from one sentence. Not magic. But free.

Add this to your system prompt, your Cursor rules, or your CLAUDE.md:

When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.

For AI coding agents like Claude Code, Codex, or Copilot in agent mode, drop these instructions into your project's configuration files. The agent reads them on every task.

Layer 2: SAST in your editor

SAST — Static Application Security Testing — scans your code for vulnerabilities without running it, like a spell-checker but for security holes. The key finding from AppSecSanta: only one SAST tool caught 78% of AI-generated vulnerabilities. Running multiple scanners dramatically improves coverage.

Recommended setup:

  • Semgrep — free, fast, 3,000+ rules. Runs in VS Code, JetBrains, and CI. Catches injection, SSRF, hardcoded secrets.
  • Bandit (Python) — catches common Python security issues. Zero configuration needed.
  • ESLint security plugins (JavaScript) — eslint-plugin-security and eslint-plugin-no-unsanitized.

Install Semgrep as a pre-commit hook — a script that runs automatically before every commit, blocking bad code from entering the repository:

pip install semgrep
semgrep --config auto --error .

Now every commit gets scanned. AI writes the code, Semgrep slaps it before you push.

Layer 3: CI pipeline scanning

Your pre-commit hook catches the obvious stuff. Your CI pipeline — the automated build-and-test system that runs when you push code — should run deeper analysis:

# GitHub Actions example
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Focus your rules on the categories AI fails at most: SSRF (CWE-918), injection (CWE-89, CWE-78), unsafe deserialization (CWE-502 — when malicious data gets unpacked into executable objects), and path traversal (CWE-22 — when an attacker uses ../../ to escape a directory and read files they should not see).

Layer 4: Human review with a security lens

Code review for AI-generated code is different from normal review. You are not hunting for logic errors — the AI handles those reasonably well. You are hunting for:

  • Endpoints without auth checks. The AI writes the route handler but forgets the middleware — the gatekeeper code that checks "are you allowed to be here?"
  • User input flowing to dangerous places. Database queries, file operations, HTTP requests, shell commands. If user input touches any of these without sanitization, you have a problem.
  • Missing rate limiting. AI never adds rate limiting unless you explicitly ask. Every public endpoint needs it, or someone will hammer it with 10,000 requests per second.
  • Secrets in code. The model sometimes generates placeholder API keys that look real enough to ship. Then they end up on GitHub. Then they end up in someone else's hands.

Train your team to ask one question for every AI-generated function: "What happens if the input is hostile?"

Layer 5: The OpenSSF rules file

The OpenSSF — Open Source Security Foundation — published a standardized Security-Focused Guide for AI Code Assistant Instructions. It is a rules file you drop into your project root. Every AI coding tool that supports project-level instructions reads it automatically.

The file covers input validation, output encoding, authentication, session management, cryptography, error handling, and logging. Instead of writing your own security rules from scratch, use theirs — maintained by security professionals, updated regularly, and free.

What this costs you

Time. Every layer adds friction. Pre-commit hooks add 5–15 seconds per commit. CI scans add minutes to your pipeline. Human review requires humans who know what SSRF looks like. The OpenSSF file requires reading it once and understanding what it does.

False positives will annoy you. Semgrep will flag code that is actually fine. You will spend time investigating non-issues. This is the tax you pay for catching the real ones.

And none of this is foolproof. The AppSecSanta study found that 22% of vulnerabilities slipped past all the SAST tools they tested. Some holes require dynamic testing — actually running the code and attacking it — to find. Static analysis is necessary but not sufficient.

What to do Monday morning

You do not need to implement all five layers by next week. Start with two:

  1. Add security instructions to your AI config. Copy the prompt block from Layer 1. Paste it into your project. Five minutes.
  2. Install Semgrep as a pre-commit hook. Two commands. Done before your coffee gets cold.

That alone puts you ahead of most teams shipping AI-generated code today. Add CI scanning when you have a sprint with breathing room. Add the OpenSSF file when someone on your team reads it and understands it. Train reviewers over time.

The new normal

The vulnerability rate in AI-generated code dropped from roughly 40% in 2024 to 25% in 2026. Progress, sure. At this pace, we hit "acceptable" somewhere around 2030. You cannot wait four years.

Treat AI-generated code like output from a junior developer who types at 500 words per minute, radiates confidence, and has never heard of OWASP. Review it. Scan it. Test it. Then ship it.

The AI writes code at 10x speed. Your security tooling needs to match. The tools exist. The only missing piece is the habit of using them.