Is your AI app builder safe? The platform and your app are two questions

When somebody asks whether an AI app builder is safe, they are usually asking two questions at once. One is about the company that runs the builder: its servers, its certificates, its sandbox. The other is about the app it generated for you, which is a separate thing with a separate answer, and no certificate on the first one covers the second.

The first question mostly has a good answer now. The second one is where your users' data lives, so most of this page is about that.

What does the platform's own security cover?

The serious builders publish a real list. Some hold a SOC 2 Type 2 report, encrypt data at rest and in transit, run builds in an isolated sandbox, and pay outside assessors to test the platform every year. Hosted builders also serve your app over HTTPS, patch the servers under it, and keep API keys pasted into chat in a secrets store instead of your frontend code. Some now give each app a separate development and production database, so the agent building your app cannot touch live data.

Look at what every item on that list has in common. Each one describes the builder's infrastructure, and not one of them describes your code. Every platform works this way. AWS is about as certified as a company gets, and it will still let you leave an S3 bucket public.

Platform flaws do happen, and outside researchers have found serious ones in hosted builders. When they do, they tend to teach the same three lessons:

• Shared infrastructure means a shared blast radius. On a hosted builder your sign-in is one implementation used by every customer, so a defect in it is not your bug and is still your problem. For most people that is still the right trade, because the auth you would write yourself has bugs too.
• Public identifiers are inputs, not secrets. An id in a URL, a tenant slug or a project key can be read by anyone. If your app treats one as something an attacker cannot see, it is doing security work nobody decided it should do.
• Premium checks in the browser are suggestions. The button is hidden, but the request behind it still works.

What does a built-in security scan check?

Most builders ship one now, and several are free. The checks vary by platform, but the common set looks like this: tables with no access rules or rules that let everyone through, dependencies with known vulnerabilities, API keys and passwords in code or sent to browsers, backend functions or endpoints anyone can call without signing in, and user input reaching a query, a command or an AI prompt. The more thorough ones also look for paid features that can be reached without paying and prices a user can change.

Run it before every launch. It is usually free, it knows the platform better than any outside tool, and several will apply a fix for you.

Two details decide how much it protects you. It only runs when you run it. Some scans run on every publish, some only when you press a button, and some warn without blocking the publish, so read your own settings before assuming anything ran. It reads code, not intent. A scanner can see that a rule exists, and it can spot a missing ownership check in a pattern it recognises. It cannot know that a manager should see their team's records but not another team's, because nobody ever wrote that down.

Why do AI builders leave these holes?

Because the request never mentioned them. "Let users save their favourites" is a complete instruction to a language model and an incomplete one to a security engineer. The model writes a working feature, and whether user A can read user B's favourites is a question the prompt never raised.

The same goes for "fix this error". That is how a permission gets widened from this user to anyone and then stays that way, because the error went away and nothing suggested the fix had cost anything. Builders that put security patterns into generation help, and guardrails at generation time are better than a scan afterwards. A generator can follow a pattern, though. It cannot know that in your app a team_id means shared access and a user_id means private, and the difference between those two is the whole security model of your app.

What is still mine to test?

Anything that depends on what your app is supposed to allow. Each check takes a few minutes, and none of them produce an error when they fail, which is why they survive to production.

Who can see whose data. Make a second account, then open a URL or call an endpoint that belongs to the first one, for example by changing /orders/1041 to /orders/1042. Do the same with the API calls in the network tab, because a page can redirect while the request underneath it still answers. This is the flaw that shows up most in generated apps of every kind, and it looks perfect while you only ever test as yourself. Can another user see my data? covers it in full.

Keys in the browser. On the deployed app, open developer tools and search every loaded file for sk-, secret and token. A Supabase publishable key is meant to be there and a secret key never is. Variables named with NEXT_PUBLIC_ or VITE_ are compiled into your JavaScript, and a builder that deploys from the browser makes that easy to miss. Which keys may ship to a browser explains the difference.

Your database rules, tested as users. A built-in scan flags tables with no row-level security. A rule that exists but is too generous is harder to see, and on Supabase, switching row-level security on does not revoke the privileges the table was created with. How to test Supabase grants and policies has a check you can run as a signed-out visitor and two users.

Your paywall. As a free user, call a premium feature directly from the network tab. If it answers, the paywall is a hidden button and nothing more.

Input handling. Type <script>alert(1)</script> into a comment or profile field and view it as the other account. An alert box means anything that field can hold runs in your users' browsers.

What you connected and what you collect. Every integration you wired up carries its own credential, and its scope is usually wider than the feature needs. A form built in an afternoon also collects whatever fields the model suggested, and if those include phone numbers or addresses, you have obligations no security scan covers.

How do I keep the agent away from production?

An agent with write access to production will eventually use it. An instruction not to, written in plain language in a prompt, is a preference and not a permission, because it loses to whatever the model decides the task needs. If your builder separates development and production data for its built-in database, use that, and apply the same three rules to anything else the app talks to, such as an external Postgres, a Supabase project or a payment provider:

1. Give the agent its own data. A separate database or project with its own credentials, not a different table or prefix.
2. Keep production credentials out of the agent's environment. If they are not there, no prompt drift can reach them, and this is the one control that holds when the model ignores you.
3. Check anything destructive yourself. Open the table and count. An agent's report that a migration worked is a claim, and it can be wrong and confident at once.

A backup you have never restored is a belief rather than a backup. Restore one into a scratch project once, so the day you need it is not the day you learn how.

When is the built-in scan enough?

For a small app with one kind of user and no payments, a clean built-in scan plus the two-account test is a reasonable bar before launch. Run the scan again after any change to sign-in, payments or database tables, because that is when access rules drift.

Expect to want more when real money or other people's personal data is involved, when the app has several roles such as admin, staff and customer, or when parts of it live outside the builder. Those are the cases where a second, independent read of the code earns its cost, and where a person who knows what each role should see is worth more than any scanner.

Where does an outside scan fit?

Many builders can sync your app to a GitHub repository, and once the code is there any repository scanner can read it. Sentrint is one: it scans that repository on its own, explains each finding in plain English, and writes a fix prompt you can paste back into your builder's chat. It is a code scan, not a pentest. It does not log in to your running app, it cannot see settings that live only inside the builder, and it would not catch a flaw in the platform itself.

Treat it as a second opinion next to the built-in scan, not a replacement for it or for the two-account test. The pre-launch checklist has every check above in the order an attacker would find them. You can read a full sample report to see what a scan returns, and the first scan is free with no card.