How to Secure an AI-Built App Before Launch: A Checklist

Is code written by AI actually secure?

Often not, unless somebody asks it to be. Veracode's 2025 GenAI Code Security Report tested code produced by more than 100 large language models and found that 45% of code samples failed its security tests and introduced an OWASP Top 10 vulnerability. The report also found that newer and larger models were better at writing code that runs, and no better at writing code that is secure.

That matches what we see in our workshops at Bodhih. A trainer, shop owner or analyst describes an app to an AI builder, it works beautifully, and it goes live on a Sunday night. The assistant did what it was asked. Nobody asked the second question, which is who should be allowed to see and change each piece of data.

The good news is that the questions are learnable by people who don't write code, and they are the same whichever tool built the app. Tool names and menus change every month. The layers underneath have been stable for twenty years.

What should I check before I launch an app built with AI?

Work through eight layers in this order. If something goes wrong after launch, it went wrong in one of them.

Before you start, decide your stakes level honestly. A public quiz with no logins needs a light pass. An app that stores names, emails and private records needs the whole list. Anything involving payments, health, finance, ID documents or children needs the list plus a paid professional review.

How do I stop users seeing each other's data?

This is the most important check, and the one most often missed. Broken access control is the number one category in the OWASP Top 10:2025, the widely used industry list of the most serious web application risks.

The principle is simple: anything that happens in the user's browser can be seen and changed by the user. Hiding a button or leaving an admin page out of the menu does not protect anything. The real rules have to live in the database or on the server.

Many AI builders connect your app to a hosted database that the browser talks to directly. That design is fine only if access rules are switched on. Supabase's documentation, for example, tells developers to enable row level security on every table in an exposed schema, and warns that its service role key bypasses those rules and must never be exposed to the client side. Other platforms use different names, such as security rules or privacy rules, for the same idea.

You don't need to write the rules. You need to decide them. Draw a grid for each table with your roles down the side (visitor, user, staff, admin) and four actions across the top (read, create, update, delete). Fill each box with yes, no or own only, and default to no. Then ask your assistant to implement that grid in the database or server layer, and to list any table that has no rules at all.

• Create two ordinary test accounts, A and B, with fake details
• As A, create a record and copy the web address of the page that shows it
• As B, in a different browser, paste that address, then change the number or code at the end
• Paste the same address, and the link of any uploaded file, into a logged-out private window
• If B or the visitor can see A's data, the rules are missing or in the wrong place

Where should API keys and passwords live?

Services hand you two kinds of key. A public key (often called publishable or anon) is designed to sit in the browser and is safe provided your access rules are on. A secret key (service, admin or private) can read all your data or spend your money, and must only live on the server, in your platform's secrets or environment variables screen.

The classic mistake is pasting a secret key into a chat with the builder to get something working, after which it ends up in front-end code where anyone who views the page source can copy it. GitHub's documentation on secret scanning puts the risk plainly: credentials committed to repositories as hard-coded secrets become targets for unauthorised access, which is why code hosts scan for them automatically.

If a key has been anywhere it shouldn't, treat it as leaked. Create a new key, update the secrets setting, redeploy, test, and then revoke the old one. Deleting the message is not enough.

• Keep an inventory of every service and key: nickname, type, where stored, last rotated. Never the key itself
• Set a spending cap or budget alert on every paid service before launch
• Add per-user limits to costly actions such as AI calls, emails and SMS
• Turn on two-step verification for your builder, database, hosting, domain and email accounts
• Use the platform's built-in login rather than a home-made users table with a password column

How do I test an app if I can't read the code?

Test behaviour, not code. Every app has three paths. The happy path is a user doing everything right. The sad path is honest mistakes: an empty form, a wrong password, a double click, a lost connection. The mischief path is a curious user doing what the app never expected. Run the mischief path only on your own app with your own test accounts.

A short list finds a surprising number of problems: submit every form empty, paste ten thousand characters into a name field, enter a negative quantity, upload a very large file, sign up twice with the same email, log out and press Back, and type a harmless tag such as <b>test</b> into a text box to see whether it is displayed as plain characters.

If you take payments, keep card details off your app entirely by using a trusted provider's hosted checkout, set prices on the server, and run the provider's test mode end to end including a declined card.

Write the tests in a table (what I did, what should happen, what happened) so you can rerun them after every change. AI assistants sometimes fix one thing and quietly break another.

What is the right way to debug with an AI assistant?

Replace 'it's broken, please fix it' with a five-step loop: reproduce, isolate, describe, one small fix, verify. First make the bug happen twice and write the exact steps. Then narrow it down: every user or one role, every browser or one, every record or some. Copy the exact error text from the screen or the browser console.

Describe it in four lines: what I did, what I expected, what happened instead, what I've ruled out. Ask the assistant to explain the likely cause before it changes anything, and to make the smallest change that fixes only this bug. Then rerun your steps and your key tests.

If three fixes in a row fail, stop. Roll back to your last working checkpoint, restate the goal in one sentence, open a fresh conversation with a short brief, and ask for three ranked causes before any code changes. Long threads bury the details that matter.

Do I need backups if my builder saves versions?

Yes, because they protect different things. Version history, checkpoints and Git commits protect the app itself: its screens and logic. Rolling the app back to Thursday does not bring back a table that was emptied on Saturday. Only a backup of the data does that.

The UK National Cyber Security Centre lists backing up your data among the five core topics in its guide for small organisations, and its advice applies just as well to a one-person app. Find out whether your database host takes automatic backups on your plan and how far back they go, schedule your own export to a separate protected place, and restore one into a test copy to prove it works. A backup you have never restored is a hope.

• Save a named checkpoint before every change you ask the assistant to make
• Make one change per request, then test, then checkpoint again
• Keep a copy of the code outside the builder, in a private repository or an export
• Export the database weekly for an ordinary app, daily if a lost day would hurt
• Treat backups as personal data: protect them and delete old ones on a schedule

What about privacy law and personal data?

If you store information about living people, you have responsibilities, and in most countries legal ones. The details differ between the GDPR in the EU and UK, India's Digital Personal Data Protection Act and other national laws, and a law can apply because of where your users are. This is educational, not legal advice: check your local law or a qualified professional.

Six habits sit underneath almost all of these laws: have a reason for each field, collect the minimum, say what you do in a plain-language notice, delete on a schedule, let people see and remove their data, and protect it and own up if it leaks. If your app sends user content to an AI model, tell users, and check that provider's current terms on retention and training.

What do I do if something goes wrong after launch?

Decide now, while you're calm. A one-page plan with five steps is enough: contain, assess, tell, fix, learn. Contain first: rotate the key, disable the feature or take the app offline. Then work out what happened and to whom, tell affected users plainly, fix the cause in a test copy, and add a check so it can't quietly return.

Some laws set deadlines. The UK Information Commissioner's Office, for instance, says a notifiable personal data breach must be reported without undue delay and not later than 72 hours after you become aware of it. Rules vary by country, so get qualified advice quickly if personal data is involved.

Write down today who decides, where the off switch is, where the backups are and where the logs are. If you want the whole process laid out, the Ship It Safely kit from Bodhih Training includes a fillable incident one-pager, a 50-point checklist and a Launch Readiness Tracker that turns your checks into a score and a verdict.