The core problem: code that works but isn't secure

A production application can pass every functional test, deploy successfully to staging, and serve thousands of users before anyone notices a critical security flaw in the authentication flow. The code works. Database queries execute within acceptable limits. API responses return correctly. But the access controls designed to prevent one user from reading another user's data were never configured.

This is not a hypothetical. In January 2026, Moltbook, an AI social network built entirely using AI coding tools without any traditional code review, exposed 1.5 million API authentication tokens and 35,000 email addresses within 72 hours of launch. The vulnerability was straightforward. Any experienced engineer reviewing the code would have caught it. But no code review happened, because the entire application had been built through conversational prompts to AI assistants, deployed without the security checks that would normally accompany human-written code.

What the Moltbook breach shows us
The gap between "the code works" and "the code is secure"

The Moltbook application passed its functional tests. Users could sign up, post content, and interact with each other. The features worked exactly as intended when tested with normal usage patterns. Nobody tested what happened when someone deliberately tried to access another user's data through the API.

The breach happened not because the AI generated bad code in the conventional sense. It happened because Row Level Security (RLS) policies on the database were never configured. The AI generated the application code correctly. The configuration layer that actually restricts database access to the right users was missing entirely.

This is the pattern that makes AI-generated security failures different from traditional bugs. The feature works. The tests pass. The security property was simply never implemented, because the AI optimised for functional correctness and nobody was explicitly checking for security completeness.

TechRadiant analysis: AI coding tools do not cause security vulnerabilities in the same way a developer writes a bug. They produce code that functions correctly while leaving security requirements unimplemented, because functional requirements are visible in tests and security requirements often are not.

The Moltbook case is not an outlier. A study from Escape.tech scanned 5,600 applications built with AI coding tools and found over 2,000 vulnerabilities, more than 400 exposed API keys and credentials, and 175 instances of exposed personal data in production applications. These are not theoretical risks identified by overly sensitive scanners. They are exploitable vulnerabilities in live systems.

Why AI generates insecure code, and why it's structural, not accidental

The easy explanation is that AI coding tools are new and will improve. The accurate explanation is different. The vulnerability patterns in AI-generated code are not random errors. They are predictable, reproducible, and tied directly to how these models are built and what they optimise for.

How the training data problem creates insecure output
1
Training data source: AI coding models train on public repositories from GitHub, GitLab, and similar platforms. These repositories contain decades of code. Much of it is old. Much of it is insecure. Code marked as "example only" and code with known vulnerabilities sits alongside good code in the training set.
2
Pattern matching, not understanding: The model learns patterns. It does not understand security. When asked to write an authentication flow, it generates code that statistically resembles authentication code in its training data. If insecure patterns dominated training, insecure patterns get reproduced.
3
Optimisation for function, not safety: The model optimises for code that works correctly on normal inputs. Security requires thinking about adversarial inputs. Nobody crafting natural language prompts is running adversarial tests during the conversational development loop. Security properties that don't affect whether the feature passes a functional test simply don't get implemented.
4
Context blindness: MD5 is a broken hashing algorithm. The model doesn't know this. It knows MD5 appears frequently in hashing examples in its training corpus, so it generates MD5 when hashing is requested. Security standards evolved. The model's training data reflects the past, including the insecure past.
5
The result: Veracode tested whether AI models would choose secure or insecure implementation methods when both were available. The models chose the insecure option 45% of the time. Insecurity is not a bug in AI coding tools. It is a consequence of what they are trained on and what they optimise for.

This matters for how teams respond to it. If AI-generated insecurity were random, you could fix it by reviewing samples. If it is structural and pattern-based, you need systematic security validation built into the development workflow for every piece of AI-generated code, not sampling.

The comprehension gap
Vibe coding (accepting AI-generated code without deeply reviewing it) creates a knowledge gap between the person deploying the code and the security implications of what's deployed. When a developer writes code manually, they understand what each function does. When they accept AI-generated code at speed, they may not understand how the authentication middleware validates tokens, how data flows through the application, or whether access controls actually restrict the right queries. The vulnerability is not just in the code. It is in the gap between what was generated and what was understood by the person who shipped it.

The five vulnerability patterns appearing most often in AI-generated code

Multiple independent research programmes have documented the same failure patterns across different AI coding platforms. These are not platform-specific bugs. They are patterns that emerge from how all large language models approach code generation. Understanding each one makes it easier to know where to look and what to test.

1
Injection vulnerabilities, SQL, XSS, and command injection
86% of AI-generated code failed XSS defences in Georgetown CSET research. AI produces 2.74x more XSS vulnerabilities than human-written code.

When an AI model generates database queries, it most often uses string concatenation rather than parameterised queries. String concatenation is simpler and appears more frequently in training data. Parameterised queries require more complexity. The simpler pattern gets generated first.

The same root cause produces cross-site scripting and command injection vulnerabilities. User input gets inserted directly into HTML rendering, shell commands, or database queries without sanitisation. The code works perfectly when users input normal data. It breaks catastrophically when someone inputs malicious data.

Why traditional testing misses it: functional tests use valid input. The login with real credentials works. Nobody tests what happens when a SQL injection string is submitted in the username field. Adversarial testing is required, not functional testing.
2
Weak cryptography from outdated training patterns
Security-focused prompts produce the highest rate of cryptographic errors, explicitly asking for security doesn't prevent the model from generating weak crypto.

AI models suggest MD5 and SHA1 for hashing because those algorithms appeared frequently in older training data when they were industry standard. The model has no awareness that security standards moved on. Hardcoded encryption keys appear for the same reason, example code in training data often includes placeholder keys that look identical to real ones.

Particularly troubling: research specifically examining cryptographic implementations in AI-generated code found that the more explicitly a developer prompts for "secure" cryptography, the higher the rate of cryptographic errors. The model pattern-matches to the word "secure" in its training data, which may include examples of security-related code that are themselves insecure.

Why it matters: weak cryptography can be fine in testing and catastrophic in production. A password hashing implementation using MD5 will process passwords correctly and pass all functional tests. When a database is breached, those passwords are trivially reversible.
3
Secrets and credentials exposed in code
The Escape.tech scan of 5,600 AI-built applications found 400+ exposed API keys, credentials, and tokens in production systems.

AI models reproduce patterns from their training data. When asked to generate API integration code, the model has seen thousands of examples that include key formats, and it generates similar patterns. It doesn't distinguish between a placeholder key and a real one. Configuration files get created with example database passwords that look identical to production credentials. Environment variable definitions include sample secrets that get committed and pushed.

The problem compounds with vibe coding specifically. When a developer accepts generated code quickly without deep review, a hardcoded API key in a configuration file is easy to miss. Once committed to a repository, secrets are difficult to fully remove even after discovery because they remain in git history.

A hardcoded secret found after a repository is made public, or discovered in a breach, can provide immediate access to any service that key controls. Secret scanning needs to run on every commit, not just on code review.
4
Incomplete authentication and missing access controls
A study of 15 applications across five major AI coding platforms found zero of the 15 implemented CSRF protection, and zero set security headers.

Building secure authentication requires understanding threat models, session management, token rotation, privilege separation, and password storage practices. These are not implicit in the prompt "add user login." The AI generates code that demonstrates login behaviour. Users can log in and sessions persist. That's what the functional test checks.

What doesn't get checked: whether CSRF attacks from external origins are blocked. Whether session tokens are properly validated. Whether role-based access controls prevent users from accessing other users' data. The Moltbook breach is this exact pattern at scale: authentication functioned correctly, but the access control layer was missing.

Authentication and authorisation are where AI-generated code most consistently underdelivers. The "it works when I test it" result from a login test is not evidence of secure authentication. Adversarial testing of authentication logic is essential, not optional.
5
Vulnerable dependencies inserted automatically
AI coding assistants frequently insert import statements and recommend packages trained on older data that includes libraries with known CVEs.

When an AI generates code for a feature, it often automatically adds import statements and recommends external libraries. The developer may not notice. These additions bring transitive dependencies, packages that the added library depends on, none of which the developer explicitly chose. One of those transitive dependencies might have a known critical vulnerability.

The model doesn't check CVE databases. It generates code based on what statistically matches its training data. If older versions of packages appear frequently in the training corpus, older (and potentially vulnerable) versions get recommended. The developer never sees the dependency tree that the AI just added to their project.

Automated dependency scanning needs to run on every build, not just when a developer manually adds a package. AI-inserted dependencies are exactly as risky as any other dependency and require the same scrutiny.

Why your existing security tools miss these

Most security tooling was built for human-authored code and human-speed development. AI-generated code moves faster and has different failure patterns. The gap between "our security tools say we're fine" and "we're actually fine" is where most AI-generated vulnerabilities live.

SAST
Static Application Security Testing
Scans code after it's written. Assumes code goes through review gates before deployment. Vibe coding eliminates those gates entirely, the conversational AI loop moves faster than weekly SAST scans can execute. By the time a flag appears, the code often already runs in production.
Gap: can't detect configuration vulnerabilities. A missing Row Level Security policy is not visible in application code.
DAST
Dynamic Application Security Testing
Tests the running application. Useful but designed for structured QA phases that vibe coding bypasses. Often run too infrequently to keep pace with AI-speed development. Also misses vulnerabilities in code paths that aren't exercised by the test script.
Gap: doesn't test adversarially by default. A DAST scan using normal inputs will pass the same login that a SQL injection attack would break.
SCA
Software Composition Analysis
Tracks known vulnerabilities in declared dependencies. Works when developers explicitly add packages. When an AI inserts dependencies directly into import statements, those packages may not appear in dependency manifests until build time. By then they're already integrated throughout the code.
Gap: misses AI-inserted transitive dependencies that never appear in the manifest until the build resolves them.
Traditional code review
Manual review processes
A senior developer reviewing code can spot insecure patterns. But AI coding tools can generate thousands of lines of code in a day. A reviewer that can handle 300 lines per week becomes the bottleneck when AI generates 3,000 lines per day. Volume alone makes manual review impractical as the primary security gate.
Gap: human review at AI generation speed is structurally impossible without dramatically different processes.
The configuration vulnerability that static analysis can't catch
In the Moltbook case, the vulnerability was a missing database access policy, not vulnerable application code. A static analysis scanner examining the application code would see a Supabase client initialised with a public API key. For Supabase applications, that is entirely normal and expected. The scanner has no mechanism to verify whether the database access controls that make that key safe were actually configured. Catching this requires behavioral testing: actually attempt to read another user's data through the API and verify the system blocks it. Static tools analyze code in isolation. They cannot verify what the running system actually does.
Building with AI coding tools?

Find DevSecOps agencies verified on AI code security practices

TechRadiant verifies DevSecOps consultants on documented security outcomes. Find a team who has built security validation into AI-assisted development workflows.

Browse verified DevSecOps agencies → Share your security brief

What your team needs to do differently

The right response to AI-generated code security risks is not to stop using AI coding tools. Teams that have done that have simply lost the productivity advantage without addressing the underlying problem. The right response is to add security validation that matches the new development model, automated, continuous, and integrated into the workflow rather than bolted on at the end.

1
Add secret scanning to every commit, not just code review
AI-generated code produces exposed secrets at a documented rate. The only way to catch this consistently is automated scanning on every commit before it enters the main branch. Tools like Gitleaks and Trufflehog run as Git hooks or CI pipeline steps and block commits containing credentials before they can be pushed. This is the single highest-return security addition for any team using AI coding tools.
Tools: Gitleaks, Trufflehog (both open-source). GitHub and GitLab have built-in secret scanning that can be enabled in repository settings.
2
Run dependency scanning on every build, not just when you add packages
AI coding tools add dependencies without explicit developer action. SCA tools configured to run only when a developer manually adds a package will miss everything the AI inserts. Configure dependency scanning to run on every build, checking the full resolved dependency tree including transitive dependencies, and blocking builds that introduce known critical vulnerabilities.
Tools: Snyk, Dependabot, Trivy, all can run on every build and most have CI/CD integrations that take a few minutes to set up.
3
Build adversarial tests for authentication and access control
Functional tests verify that legitimate users can do what they're supposed to do. Security tests verify that users can't do what they're not supposed to do. For every authentication or access control feature, write at least one test that authenticates as user A and attempts to read or modify user B's data. Write tests that attempt operations without authentication. Write tests that submit malformed or malicious input. These tests would have caught the Moltbook vulnerability before launch.
This doesn't require a security specialist. It requires someone asking "what should this system refuse to do?" and writing tests for each answer.
4
Include security requirements explicitly in AI prompts
AI models do not implicitly apply security best practices. You need to explicitly request them. When prompting for a database query, specify that it should use parameterised statements. When prompting for an authentication flow, specify CSRF protection, secure session handling, and input validation. When prompting for API endpoints, specify rate limiting and input sanitisation. This does not guarantee secure output, but it meaningfully shifts the probability distribution toward better patterns.
Create a standard security requirements prompt template for your team. Append it to every feature prompt. Treat it like a code style guide, standard and expected.
5
Treat AI-generated code as untrusted until reviewed
The comprehension gap is real. When a developer accepts a large block of AI-generated code quickly, they may not understand its security implications. Establish a team norm: AI-generated code that handles authentication, database access, external API calls, or file uploads requires a security-focused review before merging, even if functional tests pass. The review doesn't need to be exhaustive. It needs to ask: is this missing any obvious security requirements?
This is a cultural practice, not a technical tool. A senior engineer spending 30 minutes reviewing AI-generated auth code before it ships is the highest-leverage manual security action available.
The mindset shift that makes this manageable
AI coding tools are accelerating development at a rate security teams cannot match with more headcount. The only sustainable response is automation: automated secret scanning, automated dependency checks, automated adversarial tests. Manual security gates slow teams down and create the pressure to skip them. Automated security gates that run in the CI pipeline and take seconds are the ones that actually run consistently. The goal is not to add friction to development. It is to shift security checks from "after the fact" to "baked in" so that the speed of AI-assisted development doesn't create a gap that attackers exploit.

Treating AI-generated code as if it came from a security-aware senior engineer is the root mistake. It didn't. It came from a statistical pattern matcher trained on decades of public repositories, much of it insecure, all of it optimised for functional correctness rather than security completeness. That doesn't make AI coding tools dangerous, it makes them powerful tools that require specific security practices that most teams have not yet built. For DevSecOps consultants who have built those practices into AI-assisted development workflows, TechRadiant's verified DevSecOps agency index covers teams evaluated on documented security outcomes.