Is Code Built by AI Actually Secure? A Builder's FAQ

I get some version of this question in almost every onboarding call, usually phrased carefully, like the person asking half-expects to be talked out of worrying. They shouldn't be talked out of it. Security is one of the few areas where a healthy amount of paranoia is correctly calibrated, whether a human or a model wrote the code. Below are the questions I actually get, answered as directly as I can manage.

Is code written by AI less secure than code written by a human?

On average, and left unchecked, yes — mildly. A Stanford study from a few years back (Perry et al., often cited as the first real look at this) found developers using an AI coding assistant produced less secure code than a control group, and — this is the part that should worry you more — rated their own code as more secure than it was. Confidence went up while quality went down. Veracode's more recent GenAI code security scans put a rough number on it too: somewhere around 4 in 10 AI-generated code samples they tested introduced at least one exploitable flaw, usually something mundane like a missing input check or a weak default. None of this means AI-written code is inherently doomed. It means unreviewed AI-written code carries the same risk as unreviewed human code, and the "unreviewed" part is where the danger actually lives. A model that writes fast and never gets checked will ship the same mistakes a junior dev makes on a Friday afternoon — just faster, and more of them.

What happens to my API keys and secrets?

This is the one I actually lose sleep over, because it's the mistake that's invisible until it isn't. The failure mode isn't dramatic — nobody's server gets breached in a movie-hacker way. It's a key that gets pasted into a chat, echoed back into a generated file, committed, and quietly sitting in plaintext in a repo six months later when someone runs a secret scanner against it out of curiosity. On this platform, secrets never live in generated source at all — they're injected at runtime from an encrypted store, scoped to your tenant, and the build agents are instructed to reference them by name, never by value. But if you're building elsewhere, or pasting credentials directly into a chat window with any tool, assume that text is now part of a training-adjacent log somewhere unless the provider explicitly says otherwise. Rotate anything you've ever typed into a chat box, on principle, the same day you finish testing.

Can someone hack my site through a prompt, like a prompt injection attack?

Two different things get conflated here, and the distinction matters. Prompt injection against the builder — someone tricking the AI that's building your app into doing something you didn't ask for — is a real, studied risk, and it's why build agents run with scoped tool permissions rather than blanket shell access, and why anything touching your filesystem or deploy pipeline goes through an explicit action log you can audit afterward. Prompt injection against your shipped app is a separate concern that only applies if your app itself embeds an LLM at runtime — a support chatbot, an AI search feature, that kind of thing. If it does, treat any text a user can type as untrusted input to that model, same as you'd treat it as untrusted input to a SQL query. The rule is old, the new part is just which system is parsing the string.

Does the builder check its own code for vulnerabilities before shipping it?

Automated checks catch the boring, high-frequency stuff reliably: hardcoded secrets, missing auth on an endpoint that clearly needs it, SQL built by string concatenation instead of parameters, dependencies with a known CVE. What they don't catch well is business-logic flaws — the kind where every individual line of code is fine and the vulnerability is in the gap between two features nobody thought to check together. A discount code that stacks infinitely with a referral bonus. A password reset flow that leaks whether an email exists in the system. Those require someone who understands what the app is for, not just what the code does, and no scanner — AI or otherwise — reliably finds them yet. Automated review is a floor, not a ceiling.

What about the third-party packages it installs — is that a supply-chain risk?

Yes, and it's honestly a bigger real-world risk than the AI-authored code itself. Most apps are 80-95% dependencies by line count; the code a builder writes is a thin layer on top of npm, PyPI, or whatever ecosystem the stack uses. A malicious or hijacked package can compromise you regardless of who or what wrote the glue code around it — see the event-stream and colors.js incidents for how that plays out in the wild. The mitigations are boring and effective: pin versions rather than tracking latest, prefer packages with real maintenance history over ones published last week, and run a dependency audit (`npm audit`, `pip-audit`, whatever fits your stack) as a standing habit, not a one-time step before launch.

Who's liable if there's a breach?

You are — legally, almost always, if it's your app and your customers' data. This surprises people who assume "the AI wrote it" shifts responsibility somewhere. It doesn't, any more than hiring a contractor shifts liability for a building code violation off the property owner. Platforms carry responsibility for the infrastructure they control: how secrets are stored, how tenant data is isolated, whether the hosting layer itself is patched. But the application logic you specified, the data you chose to collect, and the terms you offered your users are yours. If you're handling anything sensitive — payment details, health information, anything under GDPR or CCPA — read the actual data processing agreement of whatever platform you're on instead of assuming "AI-built" implies some extra layer of legal cover. It doesn't.

A founder told me once, mostly joking, that she trusted the AI's code more than her own because "at least it doesn't get tired at 2am." Maybe. But tired humans usually know they're tired. An AI has no idea it just made a mistake, and it will tell you the code is done with exactly the same confident tone whether it's flawless or riddled with holes. Confidence is not a security signal, from either source.

Should I pay for a real security audit before launching?

If you're taking payments, storing anything a regulator would call PII, or building for a business customer who'll ask for a SOC 2 report anyway — yes, and don't let the cost talk you out of it. A focused audit on a small app runs a few hundred to low thousands of dollars depending on scope, which is cheap relative to a breach notification letter. If you're building a hobby project, an internal tool, or something with no real user data at stake, a paid audit is overkill; run the free and cheap layer instead — dependency scanning, a manual click-through of every auth boundary (can user A see user B's stuff by changing a URL?), and a second pair of human eyes on anything that touches money or passwords.

What's the most common security mistake people make, and when does it happen?

Not at launch — three months after, when the app is working and nobody's looking at it anymore. It's an admin route left unguarded because it was only ever tested by the person who built it, logged in as themselves. It's a debug endpoint that returns full stack traces in production. It's a default password on a database that was supposed to be "just for testing" and never got rotated. None of these are exotic. They're the security equivalent of leaving a spare key under the doormat because you were in a hurry the one time and then forgot it was there. The fix isn't a better tool, it's a five-minute habit: once a month, look at your app the way an attacker would for five minutes before you look at it the way a proud builder would.