All notes

The holes AI code ships with

AI writes code that works in the demo and leaves the same handful of security holes behind. Here are the five I look for first, in plain English, and why the AI leaves them.

By HutchUpdated 4 minute read

AI-written code has a tell. It works on the first try, in the demo, for the one person using it. And it tends to leave the same handful of holes behind.

I use AI to write code every day, so this is not a scare piece. It is a list of where I look first, and why.

Why the holes are always the same

An AI model builds what you asked for. You asked for a sign-up page, a dashboard and a way to take payments. You did not ask for "and make sure a stranger can't read the customer table," because you assumed that came with it.

It doesn't. Security is mostly about what should not happen, and nobody writes prompts about what should not happen.

Then the AI tells you it is done, and it sounds sure. Veracode, a security company, tested AI models on coding tasks and reported in 2026 that 44% of the tasks came back with a security flaw. They sell security tools and these were lab tasks, so take the exact number with salt. The direction is the point.

1. The door with no lock

Every app has rules about who can read which data. Or it is supposed to. The first hole I look for in an AI-built app is that the rules were never written. The data sits in a database that will answer anybody who asks politely.

You can't see this by using the app. The screens only show you your own data, so everything looks fine. The hole is behind the screens.

A researcher checked 1,645 apps built with one popular AI app builder and found 170 of them exposing personal data and keys. He works for a competitor of that tool, which is worth knowing. It is still about one in ten.

2. Keys in the wrong place

An app holds secret keys for its database, its payment processor and its email service. Whoever has the key can do whatever the app can do.

AI models have a bad habit of putting those keys wherever makes the code work fastest. Sometimes that is in a file that gets published. Sometimes it is in the part of the app that runs in the customer's browser, where anyone can read it.

In January 2026, researchers at Wiz found an app whose founder said he had not written a line of it himself. Its database was open to the internet, and 1.5 million API keys were exposed.

3. Rules that live only on the screen

Say your app hides the "delete" button from regular users. Good. Now, does the part of the app that actually does the deleting also check who is asking?

Often it doesn't. The AI built the rule into what you can see and stopped there. Anybody who skips the screen and talks to the app directly can press a button that was never shown to them.

This is the security version of a bank that locks the lobby and leaves the vault open out back.

4. Other people's code, including code that doesn't exist

Nobody writes an app from nothing. Every project pulls in packages, which are chunks of code other people wrote. That is fine, and it is also how you inherit other people's mistakes.

AI adds a twist. Researchers presenting at USENIX Security in 2025 found that models recommend packages that do not exist, at least 5.2% of the time for the commercial models they tested and 21.7% for the open-source ones. If somebody registers one of those made-up names and fills it with something nasty, your app installs it by name.

5. Only the happy path was built

The happy path is what happens when everybody behaves. The customer types a real email, clicks once, and waits.

Real users, and real attackers, do none of that. They click forty times. They paste a novel into the phone number field. They try a thousand passwords in a minute.

The protections against that are dull, and AI skips them unless told. A security firm called Tenzai had five different coding agents build fifteen apps and went looking. They counted 69 vulnerabilities, and not one of the fifteen apps had a standard protection against forged requests. Tenzai sells security too. The finding is still easy to believe if you have read much AI code.

The one that hides the others

There is a sixth thing, and it is the reason the first five survive.

The checks can be wrong too. Software has automatic tests that are supposed to prove it works. AI writes those as well, and it writes them to agree with the code it just wrote. Anthropic reported that one of its own models would sometimes change the tests so the code appeared to pass.

So "all tests pass" tells you less than it sounds like. I got that message once, used the real thing like a customer anyway, and found about fourteen more bugs.

What to do about it

Three things, in order.

  1. Stop asking the AI if it is secure. It will say yes. Ask it to show you the rules, the keys and the packages, and look at them.
  2. Run the basic checks yourself. I wrote them up in Your AI says it's secure: how to check. They take an afternoon and need no engineering background.
  3. Get a person to read it before real customers do. Every hole above is easy to see for somebody who knows where to look, and nearly invisible to somebody who doesn't.

If you are letting AI agents take actions inside your business, not only write code, there is a separate safety checklist for that.

None of this means AI code is bad code. It means AI code is unreviewed code until somebody reviews it. If you would like that somebody to be me, book the free half hour.

HutchJeremy Hutchcraft, Brick City AI Engineer. Ocala, FL.

Keep reading

  • Why AI-built MVPs stall

    The first 80% of an AI-built product shows up in a weekend. Then every fix breaks something else. Here is why that happens and how to get moving again.

  • What you pay a senior builder for

    AI made the typing cheap. Here is what is left on the bill when you hire a senior person to build your product, and how to tell one from somebody with a chat window.

All notes

Not sure if your AI is full of it?

Book the free half hour

Send me your repo, or your napkin sketch. I'll tell you straight whether you need me.