Is the app your agent built safe to put in front of customers?
The app works. Somebody has asked whether it is safe, and the answer is that you do not know, because nothing you have done so far would have told you.
Seven failures repeat from one agent-built project to the next, and each has a command that settles it in about a minute. You can run every one of them yourself, tonight, before you pay anybody to look.
The short answer
Usually not yet, and the reasons repeat from one build to the next. The key that calls your paid API ships inside the app where anybody can read it. The database returns rows belonging to other customers because its access rules were never switched on. The check deciding who counts as an administrator runs in the browser, where it can be skipped. None of that is visible on the screen you were shown, and none of it fails while you are the only account.
The seven that keep coming back.
- 01
The key shipped with the app
A key compiled into an iOS binary, or written into a web bundle, can be read by anybody who downloads either of them. It got there because that is what made it work on your machine, and the app runs no differently once it is exposed. Somebody else’s traffic on your bill is usually how you find out.
Move every call needing a secret behind an endpoint of your own, then rotate the ones already out. Repository history counts too. A key you deleted in a later commit is still sitting in every clone anyone took.
- 02
The database hands over other people’s rows
Row-level security decides which rows a signed-in person can see. If it is off, or on with no policy written, the table returns all of it to anyone holding the public key, which is everybody who loaded your site.
Nothing you tested would have caught it, because you were the only account and every row was yours.
- 03
The check that matters runs in the browser
Hiding a button is not access control. The endpoint behind it still answers, and a person who opens the network tab can send the same request without ever seeing the button. Every rule about who may do what has to be enforced where the data lives.
Agent-built apps get this wrong in a particular way. Asked for an admin screen, they build the screen.
- 04
Nothing expensive has a limit on it
A signup form with no rate limit sends thousands of emails and takes your sending domain down with it. An endpoint that calls a model on every request is a bill a stranger can run up on your card in an afternoon. Put a limit per address and per account on anything that costs money or sends mail.
- 05
Passwords and personal data in the logs
Logging whole request bodies is the quickest way to see what is happening while you build, and it writes passwords, session tokens and card details into a log that other tools then copy somewhere else. Log the fields you need, by name, and redact the rest before it leaves the process.
- 06
Packages nobody chose
An agent adds dependencies to make something work. Some are abandoned, some do far more than the one job they were added for, and some have published holes with published fixes. An audit command only knows about the holes somebody has already reported, so read a clean run as a floor and not a ceiling.
- 07
No record of what happened, and nothing to go back to
Backups that have never been restored are not backups yet. An app with no audit trail cannot tell you who changed what, or what a record looked like the day before the complaint arrived.
The seven checks, in order.
Nothing here needs a specialist or a licence. Work down the list on the build you have, and stop at the first bad answer, because it will be the one that matters.
- 01
Secrets in the repository, including history
Search every commit, not only the files as they stand today.
git log -p --all | grep -niE "sk-|sk_live|service_role|api[_-]?key|secret|password"Bad answerAny hit at all, including a key you removed in a later commit, because it is still sitting in every clone.
- 02
Secrets in the shipped web bundle
Load the live site, open the Sources panel, and search the built JavaScript for each of these.
sk- sk_live service_role eyJBad answerAnything other than the publishable key you meant to be public.
- 03
Secrets in the iOS binary
Unzip the .ipa and read the strings out of the binary inside it.
unzip -q App.ipa && strings Payload/*.app/* 2>/dev/null | grep -iE "sk-|api[_-]?key"Bad answerA key that calls anything you pay for.
- 04
One customer reading another
Make two accounts. Signed in as the second, ask the API for a record belonging to the first, by its id.
Bad answerAnything comes back other than an error.
- 05
Access control that exists only on screen
As an ordinary account, send the request your admin screen sends, with the same body.
Bad answerIt works.
- 06
Known holes in dependencies
Ask the package manager what it already knows about, ignoring anything that never ships.
npm audit --omit=devBad answerAnything high or critical that already has a fix available.
- 07
A restore comes back whole
Restore last night’s backup into an empty database and sign in against it.
Bad answerThere is no backup, or it comes back missing the data.
When this sheet is the wrong one
This is the floor, not the job, if your app holds health records, card numbers you store rather than hand to a processor, or anything a regulator has an opinion about. That work needs somebody who does security full time, and we would send you to one.
Asked most often.
- Is code written by an AI agent less secure than code written by a person?
- Line by line it is usually reasonable. What is missing is everything nobody asked for, because you described the app working rather than the app being attacked. Nobody asks an agent for rate limits, or for a record of who changed what.
- Will a security scanner find these?
- A scanner finds known-vulnerable dependencies and some hardcoded secrets, which covers two of the seven above. It cannot tell you that one customer can read another’s records, because only you know which rows are supposed to belong to whom.
- Nothing has launched yet. Does any of it matter now?
- It is cheaper now. Each of these changes how the app works, and after launch the same change has to be made without losing what customers have already put into it.
- Is it safe to give an agent access to production?
- Give it the same access you would give a contractor on their first morning, which is a copy of the data and no keys to anything that charges you. An agent cannot tell a test database from a live one unless the credentials it holds make that impossible.