AI Coding Security Checklist: What Actually Works in 2026

Forty-five percent of AI-generated code contains an OWASP Top 10 vulnerability. That’s not a projection or a vendor pitch — it’s the finding from Veracode’s 2025 GenAI Code Security Report, which tested more than 100 large language models across 80 security tasks. The number doesn’t shrink with bigger models. It doesn’t shrink with better prompts. It sits there, stubbornly, across every codebase your team ships this year.

Here’s what makes this an AI coding security problem rather than just a code quality problem: the volume of generation has inverted the review workflow. Developers ship more code, faster, with AI assistants — and Stack Overflow’s 2025 Developer Survey found that 84% of developers use or plan to use AI tools, but only 29% trust the accuracy of what those tools produce. The ratio of developers to security engineers was already lopsided. Now the amount of code per developer is climbing too. Manual review doesn’t scale to match, and the checklists most teams use were written for a world where humans wrote every line.

The security model isn’t just stretched thin. In specific, measurable ways, it’s already broken. Confirmation dialogs — the “human-in-the-loop” safety net that AI coding tools rely on — can be deceived into rubber-stamping malicious file writes. Repository instruction files that agents treat as trusted authority can be poisoned. And the gap between what the agent knows and what the user sees is widening, not closing.

This post breaks down the patterns I see across the data, the specific vulnerabilities that matter most for AI-generated code, and a practical checklist that accounts for the ways the old model fails.

The Trust Gap: Why Human Review Is Already Broken

The human-in-the-loop safety model for AI coding tools assumes that a developer reviews each proposed change and makes an informed decision. That assumption fails when the approval dialog doesn’t show the true file target. What I call the Consent Mirage pattern — agents correctly identify malicious symlinks internally yet display benign paths to users — turns approval into a formality.

Wiz researchers demonstrated this with GhostApproval, a symlink-based vulnerability affecting six AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The attack works because a symbolic link inside a repository can masquerade as an innocent file like project_settings.json while actually pointing at ~/.ssh/authorized_keys. When the developer asks the agent to “set up the workspace,” the agent follows the symlink and writes the attacker’s SSH public key to the real target.

The most striking detail: in Anthropic’s Claude Code, the agent’s internal reasoning explicitly identified the file as a zsh configuration file — yet the confirmation prompt displayed to the user simply asked to “Make this edit to project_settings.json?” The agent knew the true target. The user did not.

AWS, Cursor, and Google shipped fixes. AWS tracked it as CVE-2026-12958 with a CVSS score of 7.8. Cursor issued CVE-2026-50549 rated Critical. Anthropic rejected the report as outside their threat model, arguing that users who trust a directory and approve an edit own that decision. Augment and Windsurf acknowledged the reports but remained unpatched as of July 2026.

This isn’t a single vendor’s bug. It’s a design question the industry hasn’t settled: whether an AI coding tool should shield users from a deceptive workspace, or leave that to their judgment. Until symlink resolution is universal, you should ban agent file writes in untrusted repos.

The Vulnerability Data: What AI Gets Wrong, Repeatedly

The failure patterns in AI-generated code aren’t random. They’re consistent, predictable, and well-documented across multiple independent analyses. That consistency is actually useful — it means you can build a checklist that targets the specific things AI gets wrong rather than scanning for everything.

Carnegie Mellon research shows only 10.5% of AI-generated code passes basic security review. That’s a staggering failure rate, and it aligns with what ShipSafe’s analysis of hundreds of AI-built apps found when they cross-referenced their findings with the OWASP Top 10 and Stanford AI code security research. Their Vibe Coding Security Checklist identifies 20 critical checks across secrets, auth, injection, XSS, and configuration.

One pattern stands out: auth condition inversion. ShipSafe found that 31% of Cursor-built apps had inverted auth conditions — redirecting when a session exists rather than when it’s absent. A login guard that checks if (session) instead of if (!session) looks identical to a working one until someone changes a number in the URL and reads another customer’s data. This is exactly the kind of flaw that manual review misses because the code looks correct at a glance.

The genai-app-security-checklist repository documents 258 vulnerabilities across 17 categories for AI-assisted apps, each with a severity rating and detection method. It includes a category for AI-specific vulnerabilities — 33 items covering LLM integration issues like user input concatenated directly into system prompts and vector databases with no tenant isolation. These are patterns that don’t appear in older security references because the attack surface didn’t exist before.

Here’s a comparison of the major checklists and audit resources available:

Resource	Scope	Key Finding	Target Audience
Sherlock Forensics AI Code Audit	9 security categories	Targets AI-specific patterns automated scanners miss	Teams needing professional audit
ShipSafe Vibe Coding Checklist	20 checks across 5 areas	31% of Cursor apps have inverted auth conditions	Founders shipping AI-built MVPs
genai-app-security-checklist	258 vulnerabilities, 17 categories	33 AI-specific LLM integration vulnerabilities	Engineers running structured scans
Tossitt Agent Security Checklist	10 tool-neutral controls	Focuses on scope, permissions, verification	Indie devs and small teams

The data converges on a clear picture: AI tools reproduce insecure patterns from their training data, optimize for plausible working code rather than a threat model, and skip security checks that don’t produce visible errors. A missing authorization check looks identical to a working one until someone exploits it.

Secrets, Supply Chain, and the Agent Context Problem

Secrets leakage in AI-assisted development isn’t just a code quality issue — it’s an agent context problem. When you feed rich repo context to an agent for usefulness, you also expose it to secrets, untrusted instruction injection, and credentials that shouldn’t leave your machine.

GitGuardian’s 2026 report found 28.65 million new secrets leaked on GitHub in 2025 — a 34% increase year over year. The critical detail: commits involving AI coding assistants leak secrets at more than double the baseline rate. Agents read your files, your environment, your git history, and your package scripts. If any of those contain credentials, the agent may include them in prompts, diffs, or commit messages that leave your machine.

The tool-neutral agent security checklist from Tossitt addresses this directly with a simple principle: remove API keys, tokens, private customer data, and production credentials from prompts and visible files before the agent starts. That’s step two on their ten-item list, right after creating a clean branch. The ordering matters — if you wait until after the agent has read your repo, the secrets are already in the model’s context window.

The supply chain angle is equally concerning. AI assistants hallucinate package names, and attackers register those names with malware. The Sherlock Forensics checklist flags this as a Critical severity item: verify every import exists on its registry, check for typosquatting (importing lodahs instead of lodash), and map the transitive dependency tree. AI tools don’t consider indirect dependencies at all, which means a single hallucinated package can pull in an entire chain of malicious code.

The tradeoff is real. Rich repo context makes agents more useful — they can understand your architecture, follow your patterns, and make changes that fit. That same context is the attack surface. The more you feed the agent, the more you expose. There’s no clean separation between “useful context” and “sensitive data” when the agent reads everything in the workspace.

Agent-Level Attacks: Beyond Code Vulnerabilities

AI coding security isn’t just about the code the agent writes. It’s about what the agent reads, who it trusts, and how untrusted input can hijack its behavior. The attack surface extends well beyond the repository.

A prompt injection attack dubbed GitLost demonstrated that an unauthenticated attacker could trick GitHub’s preview Agentic Workflows into retrieving content from private repositories and publishing it publicly via a crafted GitHub issue. The AI agent interpreted the issue as instructions rather than untrusted content, accessed a private repository, and posted its contents in a publicly visible comment. No stolen credentials. No malware. No software vulnerability in the traditional sense. Just plain English commands hidden in an issue body.

This is the broader architectural challenge: any text an agent ingests — issue text, documentation, web pages, package scripts, comments — becomes a candidate instruction. The agent trust boundary silently expands to include every byte of untrusted content it reads. You should assume untrusted text can influence the model unless the tool has strong boundaries and you keep your task instructions explicit.

The AGENTS.md poisoning problem is another facet of this. AI coding agents treat repository instruction files as trusted authority, creating an attack surface that traditional security controls including IAM, EDR, and static scanning cannot detect. Agents execute malicious instructions using their own legitimate credentials with no alert triggers.

Meanwhile, the governance gap is widening. Traditional security teams can’t detect this adoption pattern, let alone control it.

A Practical AI Coding Security Checklist

Here’s where the data leads. A checklist is the floor, not the ceiling — but the floor has to account for the ways AI-specific failures bypass traditional controls. The following items combine the strongest elements from the research into a single operational checklist.

Pre-Task Agent Controls

Before the agent touches your code:

1. Create a clean branch or throwaway worktree — isolate agent changes from your working tree so you can review and discard cleanly.
2. Remove secrets from context — strip API keys, tokens, and production credentials from prompts and visible files before the agent starts. This is step two, not step ten.
3. Define file scope — specify allowed files and forbidden areas before the agent begins. Don’t let it roam freely across your repo.
4. Use least-permissive mode — constrain shell commands and file edits to the minimum permissions the task requires.
5. Ask for a plan — have the agent explain what it intends to change before it changes anything important.

Post-Generation Review

After the agent produces code:

6. Run tests, type checks, and linters — a minimal smoke test catches obvious breakage before you review the diff.
7. Review the diff yourself — especially dependency, auth, payment, database, and deployment changes. These are the areas where AI mistakes travel farthest.
8. Check for auth condition inversion — manually verify that auth guards reject when there is NO session, not when there IS one. This affects nearly a third of AI-built apps.
9. Verify dependency names — check every import against its registry for typosquatting and hallucinated packages. Map the transitive dependency tree.
10. Run secret scanning — use tools like TruffleHog or gitleaks on the diff, not just the full repo. Check git history for committed-then-removed secrets.

Pipeline and Governance Controls

For teams scaling beyond a single developer:

11. Enforce automated remediation in the PR pipeline — context-aware scanning that reasons about code paths, not just pattern matching. Legacy SAST misses business logic and authorization flaws that AI code introduces systematically.
12. No agent deploys without a human gate — never let an agent deploy production changes or rotate credentials autonomously. The human gate only works if the approval dialog shows the true file target.
13. Ban agent file writes in untrusted repos — until symlink resolution is universal across all tools, agents should not write to repos you don’t control. GhostApproval is unpatched in two major tools as of July 2026.
14. Keep a record — log what was changed and why. You need an audit path for agent runs, admin actions, and incidents.
15. Assign governance owners — per the enterprise security checklist from Learn Cursor, four controls decide whether security can sign off: Identity (IT owns SSO/SCIM), Policy (Engineering leadership owns allowed repos and review rules), Security (Security team owns data flow and secrets boundary), and Adoption (DevEx owns pilot metrics and training).

The Cost of Getting This Wrong

The hidden cost stack of AI coding governance extends beyond security tooling. Every vulnerability that reaches production costs more to fix than it would have cost to catch — and AI-generated vulnerabilities are denser, more systematic, and harder to detect than human-introduced ones.

The tradeoffs are stark. Code generation speed from AI assistants directly competes with security review throughput. Agent autonomy to edit across files and run commands competes with sandboxed containment and accurate consent prompts. Rich repo context fed to agents for usefulness competes with exposure to secrets and untrusted instruction injection. You can’t optimize all sides simultaneously — you have to pick which side you’re willing to underweight.

Here’s my recommendation: if 45% of AI-generated code contains OWASP vulnerabilities and agent-level flaws like GhostApproval defeat human approval, your PR pipeline needs context-aware automated remediation — not just scanning, but fixing. And if you’re using Augment or Windsurf with untrusted repositories, stop until they ship a symlink resolution patch. The checklist above is the minimum. The question is whether your team treats it as a floor or a ceiling — and whether your security review capacity can keep up with the generation volume you’re already shipping.