You asked your AI whether the app is secure. It said yes. It probably listed the reasons, with little green check marks.
That answer is worth nothing. Not because the AI is lying, but because it would say the same thing either way. One study found that people who wrote code with an AI assistant produced less secure code and were more confident it was secure. That is the trap in one sentence.
So don't ask. Check. Here are seven things you can do this afternoon without being an engineer. Use test accounts and made-up data for all of them.
1. Knock on the door without a key
Open a private browser window, so you are not logged in. Now try to visit pages that should need a login. Paste in the address of your dashboard, a customer page, an admin screen.
If any of them load, you have a problem that no feature will fix.
A good half of an app is invisible. The screen you see talks to an address behind the scenes that hands over the data. Your AI can tell you what those addresses are. Ask it for the list, then try one from the outside:
curl -i https://yourapp.example/api/customers
That command asks for the customer list without logging in. You want to see a refusal, usually the number 401 or 403 near the top. If you see names and email addresses, stop reading this and go fix that.
2. Make two accounts and try to snoop
Create two test accounts, A and B. Log in as A and open something that belongs to A: an order, a profile, an invoice. Look at the address bar. There is often a number or a code in it.
Change that number to one that belongs to B.
If A can now see B's stuff, every customer can see every other customer's stuff. It is an easy hole to ship without noticing, because the app "works" perfectly in a demo with one user.
3. Look for keys left in the open
Apps use secret keys to talk to payment processors, databases and email services. A secret key in the wrong place is a house key taped to the front door.
If you have the code on your computer, run this from inside the project folder:
git grep -nE "sk_live|service_role|SECRET|PRIVATE_KEY|password\s*="
It searches every file for the usual shapes of a secret. Getting some lines back is not automatically bad. Getting back a long random-looking string sitting right there in a file is. Secrets belong in the hosting provider's settings, not in the code.
This is not rare. In January 2026, security researchers at Wiz found an AI-built app whose founder said he wrote none of the code. Its database was open to the internet and exposed 1.5 million API keys.
4. Ask to see the rules, not to hear about them
Somewhere in your app there are rules that decide who can read which data. Ask your AI to show you the actual rules for each kind of record, and to tell you which records have none.
"Show me" is the important part. "Yes, access rules are in place" is an assurance. A list you can read is evidence. If the answer for your customer table is that anyone can read it, you just found the hole from check 2 without lifting a finger.
When a researcher looked at 1,645 apps built with one popular AI app builder, 170 of them were exposing personal data and keys. He works for a competing company, so read it with that in mind. The counting is still the counting.
5. Check the parts you didn't write
Your app is built on top of a lot of code written by strangers. That is normal. It also means you inherit their security holes. This lists the known ones:
npm audit
If your app isn't built with JavaScript, ask your AI for the matching command. A few low-severity warnings are a normal Tuesday. Anything marked high or critical needs an answer.
While you are there, ask the AI one more question: is every package in this project real, and did you choose it on purpose? AI models sometimes invent package names that don't exist. Anyone can register one of those names and put something nasty behind it.
6. Find out what the AI itself can break
If you build with an agent, ask what it has access to. Can it reach the live database? Can it delete things? Is there a backup, and has anyone ever tried restoring from it?
In 2025 a coding agent deleted a company's live database during a period when it had been told to change nothing. The data was recovered. A backup nobody has tested is a hope, not a backup.
7. Check whose name is on everything
Log in to the place your code lives, the place your app is hosted, and the place your domain is registered. Are those accounts yours? Under your email, with your card?
If the answer is "my developer set that up," or "it's in the AI tool's account," you don't fully own your product yet. That is a security problem and a business problem in one.
What this does not cover
This is a smoke test. It finds the fire that is already burning. It will not find the subtle things: a payment flow that can be tricked, a password reset that leaks who your customers are, the checks that only happen on the screen and not behind it.
Passing all seven means you have cleared the lowest bar. Failing even one means the app is not ready for real customers, however good it looks.
For a wider view of what tends to go wrong, read The holes AI code ships with.
And if you would rather have a person do the reading, that is what my second opinion is for: I go through the app, write down what I find, and tell you what I would fix first. Or book the free half hour and tell me what you have.
HutchJeremy Hutchcraft, Brick City AI Engineer. Ocala, FL.