Is AI-Generated Code Secure? A 2026 Reality Check

Anton · CTO & Co-Founder, OneChair

The question comes up in every serious evaluation: if an AI model is writing code, does it reproduce the insecure patterns it was trained on? Does it know when not to use MD5 for password hashing? Does it understand the difference between authentication and authorization? Does it know that secrets belong in environment variables, not in a configuration file committed to source control?

The honest answer: AI-generated code can introduce real vulnerabilities. The risk is not theoretical. But the risk is also not unique to AI-generated code — human-written code introduces the same vulnerability classes, often at comparable rates. What matters is not who wrote the code but what process reviewed it before it shipped. This is not a defense of careless AI development. It is a case for pipeline discipline regardless of how the code was produced.

The Risk Is Real

AI models are trained on large corpora of public code — including code written before modern security practices were standard. Insecure patterns exist in that training data: string-concatenated SQL queries, MD5 for passwords, missing authorization checks, secrets committed to source control alongside the application. A model generating code today may reproduce patterns that were normalized in codebases written a decade ago, simply because those patterns appeared frequently in what it was trained on.

The risk does not stop at dated practices. Models also generate code that is syntactically correct and functionally adequate for the common case — but incomplete for the adversarial case. An authentication endpoint that handles successful logins correctly but does not implement account lockout after repeated failures is not a prototype that needs polishing; it is a production vulnerability that enables brute-force attacks.

The risk compounds significantly when speed is prioritized over process. "Vibe coding" — prompting a model to write a full application and deploying it without structured review — has produced applications with critical vulnerabilities in the real world. Not because AI is inherently insecure, but because the review discipline was skipped. The same outcome would follow from skipping review on human-written code, just with different vulnerability patterns in the mix.

Common Vulnerability Patterns in AI-Generated Code

SQL and command injection

Models may generate string-concatenated database queries instead of parameterized queries, particularly in contexts where the training data normalized that pattern. A concatenated query that includes user-supplied input is a SQL injection vulnerability — one of the most established and damaging attack classes. Parameterized queries prevent it entirely, but the agent has to know to use them and be configured to enforce it. Without that enforcement, the pattern can slip through.

Broken authentication

An agent asked to implement a login endpoint will produce one that checks credentials. An agent asked to implement a secure login endpoint needs to be told what that means: secure session management with appropriate token expiry, refresh token rotation, account lockout after failed attempts, protection against timing attacks on credential comparison. The model implements what is in the specification. If the specification omits these controls, the output omits them too.

Authorization gaps

Authentication and authorization are different, and confusing them is one of the most common vulnerability patterns regardless of how code is produced. Authentication verifies who you are. Authorization verifies what you are allowed to do. An agent that implements JWT verification on an endpoint has not necessarily added role-based access controls that restrict which authenticated users can perform which actions. Missing authorization checks are consistently among the top findings in security audits of AI-assisted applications — not because agents cannot implement them, but because they are often absent from the specification and therefore absent from the output.

Insecure defaults

Applications generated without explicit security configuration often launch with insecure defaults: debug endpoints enabled in the production build, verbose error responses that expose stack traces or database schema information to end users, missing security headers that protect against cross-site scripting and clickjacking, directory listing enabled on static file servers. These are not subtle vulnerabilities — they are the first things a security auditor checks, and they are consistently present in applications that were not explicitly configured with security in mind.

Vulnerable dependencies

An agent may import a well-known library at a version that has known CVEs, because the training data referenced that version frequently in working code examples. Dependency vulnerability is not specific to AI-generated code — it is a common finding across all codebases that do not run automated dependency scanning. The fix is structural: automated dependency scanning that compares the project's dependency tree against vulnerability databases, run on every commit, with blocking enforcement when critical vulnerabilities are found.

Hardcoded secrets

If the specification does not explicitly require secrets to be externalized to environment variables or a secrets manager, an agent may write API keys, database credentials, or encryption keys directly into configuration files. This is one of the more serious patterns because committed secrets affect every environment the code is deployed to, and secrets committed to version control history are effectively compromised even after they are removed from the current codebase.

Why "Vibe-Coded" Apps Fail Security Audits

"Vibe coding" refers to the practice of generating a working application through a series of conversational prompts without a structured review process. The output may be functional — it handles the intended use cases under normal conditions. But it is not production-ready, and it fails security audits for predictable reasons.

The most common findings from security audits on vibe-coded applications are not exotic vulnerabilities. They are the first five things any auditor checks: no input validation on API endpoints, authorization enforced on the frontend but not on the backend, passwords stored with insufficient hashing, no rate limiting on authentication endpoints, and verbose error responses that expose internal implementation details.

The frontend-only authorization pattern deserves particular attention because it is so consistently missed. A UI that hides certain controls from users without the appropriate role looks secure to a user testing through the browser. It is not secure to an attacker who calls the API endpoints directly. If the backend does not enforce authorization on every request — which requires deliberate specification and deliberate testing — a sufficiently motivated attacker bypasses the frontend entirely.

The pattern is consistent across vibe-coded applications: functionality that works correctly for the happy path, with security controls that exist visually or in the spec but were not translated into backend enforcement. These are not expensive vulnerabilities to prevent. They require explicit specification of security requirements and a review process that verifies those requirements are actually implemented. Without the process, they slip through regardless of how the code was produced.

The question should never be "does AI write insecure code?" — the question should be "does our process catch insecure code before it ships?" Every production codebase, regardless of how it was authored, needs a security pipeline. AI-generated code is not an exception to that rule.

Anton Dzhanayev, OneChair

The Pipeline That Catches Vulnerabilities Before Production

Static application security testing (SAST) on every commit

Automated tools scan source code for known vulnerability patterns — injection risks, insecure function calls, hardcoded secrets, dangerous default configurations. SAST runs on every commit and is required to pass before code lands in the main branch. This is not a post-build security review; it is a continuous check embedded in the build process. Issues are surfaced when they are introduced, not weeks later when they have propagated through the codebase.

Automated dependency scanning

Tools compare the project's dependency tree against continuously updated databases of known CVEs. The output identifies vulnerable packages at the exact version in use and specifies what version addresses the vulnerability. This runs automatically on every dependency change and produces blocking findings for critical vulnerabilities. The fix is typically a version bump — trivial when caught immediately, potentially complex when discovered after a package has been in production for months.

Security review agents

Specialized review agents apply a security checklist to every code module before it reaches the human review queue. They check authorization coverage on every protected endpoint, input validation completeness on every user-facing entry point, error handling verbosity (is this returning a stack trace?), and secrets externalization. This is not a replacement for human security review — it is a first filter that ensures the human reviewer is not catching the same basic mistakes repeatedly and can focus attention on the judgment-requiring findings.

Mandatory human security review

A senior engineer reviews the security posture of the application as a whole. This is where the judgment-requiring decisions are made: whether the threat model for this application requires controls beyond the baseline, whether the authorization model fully covers the edge cases that the specification did not enumerate, whether the third-party integration surface introduces risk that the individual endpoint reviews did not surface. Automated tools are excellent at finding known patterns. Human review is necessary for finding the interactions between components that create vulnerabilities neither component would produce in isolation.

Penetration testing on sensitive projects

For applications handling sensitive personal data, financial transactions, healthcare records, or other high-value targets, a security engineer attempts to breach the application before it ships. This is an adversarial discipline that finds the vulnerabilities that automated tools reliably miss — not because the tools are wrong, but because the attack surface includes the creative combinations of inputs and sequences of requests that only adversarial human thinking reliably explores. Penetration testing is not appropriate for every project; it is appropriate for projects where a breach has significant consequences.

Frequently Asked Questions

How do I assess the security posture of software I've already commissioned?

A structured software audit covers the codebase, dependency tree, authentication model, and authorization implementation. It produces a prioritized list of findings with remediation guidance. This is the right starting point if you have concerns about existing software, whether AI-generated or not. See the Software Audit service page for what that engagement covers and how long it takes.

Is AI-generated code inherently more vulnerable than human-written code?

Not inherently. The relevant variable is the review process, not the authorship. Human code without structured security review fails audits regularly — with the same vulnerability classes, at comparable rates. What AI generation changes is the speed and consistency of production, which amplifies both the upside (more code written faster) and the downside (more opportunity for unreviewed vulnerabilities to accumulate). The right response is a stronger process, not avoiding AI generation.

What should I ask a development partner about security before signing a contract?

Ask specifically: What SAST tools are used and when do they run — on every commit, or only before delivery? Is dependency scanning automated and blocking? Is there a human security review before delivery, and who performs it? On projects with sensitive data, is penetration testing included or available? A team with a real security process can answer these questions specifically. Vague answers to specific questions are a signal worth taking seriously.

Does GDPR or HIPAA compliance change the security requirements?

Yes. Regulatory compliance adds specific controls beyond baseline security — data residency requirements, breach notification timelines, audit logging for data access, formal access control documentation, data minimization policies. These requirements need to be in the project specification before the build begins, not discovered after delivery. Compliance is a specification problem first and a security implementation problem second. If your project has regulatory requirements, they should be on the table in the first scoping conversation.

If you are evaluating software that may have been built without adequate security review, the Software Audit is the right starting point — it gives you a prioritized picture of risk before you make decisions about remediation or replacement. For a broader discussion of what separates disciplined AI-assisted development from unsupervised code generation, see Vibe Coding vs. Professional Development.