AI CODING TOOL SECURITY

“Is AI-generated code secure?” has the same shape as “is the platform safe?” — the interesting answer is never yes or no. Models write code that compiles, runs, and looks right, and fails in a small set of recurring, recognizable ways: validation that exists on the client but not the server, endpoints that authenticate but never authorize, secrets inlined because a nearby example inlined them, dependencies that don’t exist upstream. This section is the research-and-workflow layer of the site: the vulnerability taxonomies, the per-tool pattern deep-dives, and the practices that keep the patterns out of production. For “is X safe?” platform reviews, hardening guides, and checklists, follow the links out to /safety/, /guides/, and /checklists/ — those pages cover the tools; these pages cover the code.

The articles group into four buckets because the questions do: what goes wrong, where your tool specifically goes wrong, how to work so it doesn’t ship, and how to verify.

Understanding the risks

The shared failure mode: AI models reproduce the most common pattern in their training data, and the most common pattern in fifteen years of public code is not the secure one. Every taxonomy below is a different cut through the same underlying behavior — plausible code that skips the check a human expert would insist on.

• Vibe Coding Vulnerabilities — the recurring patterns that ship in nearly every AI-built app; start here for the full taxonomy.
• AI Code Vulnerabilities — the same ground organized by vulnerability class: injection, auth, secrets, error handling.
• AI-Generated Code Risks — the risk analysis by threat category, for when you need to explain the exposure rather than the bug.
• OWASP Top 10 for AI Code — how the classic OWASP categories map onto AI-generated code, and where the mapping breaks.
• Low-Code Security Vulnerabilities — the same failure modes when the “code” is a visual builder’s output you never read at all.

Per-tool risk profiles

The shared failure mode: every tool ships the same bug classes, but the interaction model decides which ones and how fast. Inline-completion tools fail through hundreds of small suggestions accepted at tab-key speed; agent-style tools fail through multi-file diffs where the dangerous line hides in a file you didn’t open. Read the profile for the tool your team actually uses.

• Cursor Security Risks — the 12 patterns Cursor-generated code ships with, ranked by severity, with a fix prompt for each.
• Copilot Security Risks — what the research actually found (and what the misquoted “40%” really means), plus Copilot’s five recurring patterns.
• Cursor Enterprise Security — Business-plan controls: admin policy, SSO, and the review gates enterprise teams should require.

For platform-level reviews of these and every other tool — the IDE, not the code it writes — see the safety review hub, including Cursor, GitHub Copilot, Claude Code, and Devin.

Practices and review

The shared failure mode: teams treat AI output like their own code, when it needs to be treated like a fast, confident contractor’s code — reviewed on the assumption that it optimized for “works” over “safe.” These pages are the workflow layer: what to put in front of the model, and what to check behind it.

• Secure AI Coding Practices — six concrete habits with copy-paste blocks: instruction-file rules, the re-review prompt, validation-first scaffolding, dependency vetting, secrets discipline, and the scan loop.
• AI Code Review Guide — the human review framework tuned for AI-specific failure modes rather than style nits.
• AI Code Quality Assessment — judging AI output beyond “it runs”: structure, duplication, and the maintenance debt that becomes security debt.

Testing and tools

The shared failure mode: everything above lowers the defect rate; none of it reaches zero. The classes AI tools ship most — missing RLS, BOLA, permissive CORS, leaked keys — are visible from outside the deployed app, which is why dynamic scanning is the backstop rather than an optional extra.

• AI Security Testing Tools — the tool landscape for testing AI-generated code, and where each category fits.
• SAST Tools for AI Code — static analysis gates that belong in CI.
• Between SAST and Pentest — where deployed-app scanning sits in the testing spectrum.
• Free scanners: the Vibe Code Scanner for the full dynamic pass, Token Leak Checker for keys in your bundle, Supabase RLS Checker and Firebase Scanner for database rules, and the Package Hallucination Scanner for AI-invented dependencies.

Where to start

1. Shipping AI-generated code today? Run the Vibe Code Scanner against the deployed app first — findings beat theory, and every finding maps back to a pattern page here.
2. Evaluating or standardizing on a tool? Read its risk profile above, then the matching safety review for the platform-level questions.
3. Setting up team workflow? Secure AI Coding Practices for the generation side, the AI Code Review Guide for the merge gate.
4. Building the mental model? Vibe Coding Vulnerabilities end to end, then OWASP Top 10 for AI Code to connect it to the framework your security team already speaks.

The through-line of every page in this section: AI coding tools are not unsafe, but they are predictably unsafe — and predictable failure modes are the kind you can gate, review, and scan for.