"There's nothing worth stealing from us, it's just a small website." That's usually said in good faith, and the cost shows up months later — one day a third-party service bill is several times higher than usual, or every customer's data has been quietly gone through, and you have no idea when it happened. Attackers don't stop to judge whether you're worth targeting — they run automated scans, and if a door's unlocked, they walk in. You're not being singled out. The door was just never locked. Here are the three things we check first when we take over a product built with AI.
AI writes fast, but it won't worry about getting breached for you
AI tools are built to "produce the feature you asked for," not to "keep out people who shouldn't get in":
- Ask for a member system, and it builds a member system. You never said "one member shouldn't be able to see another member's data," so it never added that on its own.
- A human engineer writing a feature carries a mental checklist of "how could someone abuse this" — that's experience.
- AI only runs through that checklist when you explicitly ask for it — and you don't know there's a checklist to ask for.
That's why AI-built products are usually complete on the feature side and empty on the defense side. This is the same issue covered in the gap between vibe coding and real system architecture: being able to build it and being able to withstand an attack are two different skills.
Five "you'd assume" beliefs to unpack first
The real danger isn't technical detail — it's these five assumptions that sound perfectly reasonable:
| You'd assume | What's actually true | What happens |
|---|
| If it's not shown on screen, there's no access to it | The backend never checks identity a second time | Tweak the URL and you can see someone else's order |
| A key written into the code is invisible to everyone | Once code enters a repository, it's effectively public | The bill spikes, or the provider suspends the service |
| Form fields only ever get normal typed text | Someone will paste in a specially crafted string | The entire database gets read out or deleted |
| Nobody targets a small website like ours | Attacks are automated scans across the whole internet | They walk in through an unlocked door — who you are is irrelevant |
| It was checked once at launch, so it stays secure | Vulnerabilities keep being found in underlying packages | Old vulnerabilities stay open, and nobody knows |
Three landmines: permissions, keys, and input validation
- Permissions. The screen shows different buttons depending on who's logged in, but the code that actually processes the data never checks a second time whether "this person is allowed to do this." It's like an office with a badge reader on the front door, but no lock on any individual room — once someone's through the front door, they can walk anywhere.
- Keys. A key is the pass that lets your program talk to an outside service — whoever has it can act, and spend, in your name. The fastest way to build something is to write the key straight into the code, and the moment that code gets uploaded, that string is visible to anyone.
- Input validation. When the program never checks "is this a reasonable input" before sending it to the database or displaying it on a page, that string gets executed as a command instead of read as data. It's like a customer writing "open the cash register" in the notes field, and the kitchen actually doing it.
The root cause in every case is the same: the program never distinguishes "this is data" from "this is a command," and never distinguishes "not shown on screen" from "actually inaccessible."
A five-minute self-check, three questions
No technical knowledge required — use a test environment, or have whoever built it walk through this with you:
- Permissions: log in with a regular customer account, change the ID number in the URL to a different number, or type in the admin page's URL directly. If you can see something you shouldn't, this one's failed.
- Keys: open the codebase and search for "key," "secret," "password," and "token." If you find a long, random-looking string, this one's failed — and check while you're at it whether the repository is public.
- Input validation: paste text containing a single quote and angle brackets into any form field and submit it. If the page layout breaks, or a wall of English error text appears, this one's failed.
Passing all three doesn't mean you're secure, but it means the most basic doors are locked. Failing two or more means you shouldn't open it up to real customers yet. This is the expanded, security-focused version of the checklist in demo-ready isn't launch-ready.
The order to fix these in
Don't handle the three landmines all at once — follow this order:
- Rotate keys first. Treat any key that's ever entered a repository as already leaked: generate a new one, disable the old one, and move the new one out of the codebase. This is the fastest fix, and the only one of the three that might already be costing you money.
- Then fix permissions. Add an "is this person allowed" check to every place that processes data, not just what's shown on screen. This has to be reviewed feature by feature, but has the biggest impact.
- Finally, add input validation. Add checks and filtering to every form and every entry point that receives outside data. Most frameworks have this built in — the key is confirming every entry point actually uses it.
After these are fixed, security updates still need to continue, because new vulnerabilities in underlying packages keep being discovered.
How Nerdtechnic watches these three doors
- Keys get rotated and permissions get fixed in the first pass of a takeover, not after something's already gone wrong.
- Security updates at least once a quarter, with emergency updates added on top when needed, not just when there's spare time.
- An assessment within 2 business days when you report a bug, a response within 1 business day when the server or a service goes down.
Security isn't a project you finish once — it's something someone watches consistently, every month.
Locking the doors that should be locked on an AI-built product is something we handle in the first pass whenever we take over as Helper CTO — like an in-house tech lead, just not on your payroll, with the same team handling takeover, maintenance, and improvement. The first step is a 60-minute system health check: we only need to see the code, no credentials to your production environment required, and within 3–5 business days you'll get a one-page report clearly stating the status of each of the three landmines. If you just ran the three-question self-check and didn't like the answers, you can start here: Helper CTO: System Maintenance Plan.
AI Research
