How to secure a vibe-coded app before you share it
Quick answer
Before coworkers use an app you built with AI, check four things first: nobody gets past a company login, only your company’s accounts get in, no keys are in the code that runs in the browser, and the database can’t be read without going through the app. Then check who can do what inside it, and who owns it when you leave.
Most leaks from AI-built apps are not clever attacks. They are open doors: a public link, a database with its rules turned off, a key in the page. This checklist is for the person who built the app and the IT person reviewing it. Each item says what goes wrong, how to check it in plain words, and what TeamOnly handles and what is still on you.
Last updated Written by TeamOnly. We host internal apps built with AI, and each item says honestly where we help and where we don’t.
01Why this matters
What goes wrong with AI-built apps
AI tools are good at making an app work. They are less careful about who else it works for. Three findings from the last two years show the pattern.
380,000
publicly reachable assets found on Lovable, Base44, Netlify and Replit by the security company Red Access in May 2026. About 5,000 held sensitive company data, and many were indexed by Google.
170 of 1,645
Lovable apps checked in March 2025 let anyone read or change data in their Supabase database without signing in, because the database access rules were missing or wrong (CVE-2025-48757).
205,474
made-up package names suggested by 16 AI models across 576,000 code samples, in a 2025 study. Attackers can publish packages under those names and wait for someone to install them.
None of these needed a clever attacker. The doors were open. That is good news: open doors are easy to check for, and you don’t need to read code to do it.
Do them in order. The first ones keep strangers out, the later ones catch mistakes inside the company.
Nothing loads before a company login
What goes wrong
AI tools often build the sign-in screen as one page of the app. The rest of the app, and its API, still answer anyone who skips that page or calls the API directly. Red Access found company apps that gave admin access to anyone who reached the address.
Check it yourself
Open the app in a private browser window. You should see a sign-in screen and nothing else. Then ask your AI tool: “List every API route and tell me which ones work without signing in.” The answer should be none.
On TeamOnly
Handled. Every request to every app is checked before any of your code runs, including API calls, which get a 401 without a session. There is no setting to make an app public.
Only your company’s accounts get in
What goes wrong
“Sign in with Google” lets any Google account in by default, including personal Gmail. Google’s hd setting only narrows the account picker, and Google warns not to rely on it because the request can be changed. The domain has to be checked on the server.
Check it yourself
Try to sign in with a personal Gmail or Outlook account. You should be turned away. Ask your AI tool where the server checks the email domain, and whether it checks the signed token from Google or a value the browser sent.
On TeamOnly
Handled. Coworkers sign in with work Google, work Microsoft or a code sent to their work email. The domain in the verified sign-in token is checked against your company’s domains, and personal accounts are refused.
Only the right people inside the company
What goes wrong
An app with salaries, reviews or customer data gets shared with the whole company because that was the default. Or the AI builds its own allowlist in code that nobody updates.
Check it yourself
Ask: should everyone at the company see this data? If not, write down the names of the people who should, and check that someone outside that list is turned away.
On TeamOnly
Handled, you choose. Access is the whole company or a named list, set in the dashboard or with npx teamonly access only priya@acme.com. It is checked on every request, so removing someone takes effect within a minute.
Not on a public link, not in search results
What goes wrong
Some app builders publish to a public address unless you choose private. Public apps get found: Red Access reported that many of the exposed company apps were indexed by Google and other search engines.
Check it yourself
Search Google for site: followed by your app’s address. Check the project’s visibility setting on the platform you built it with. If it says public, change it before anything else.
On TeamOnly
Handled. Apps live at yourapp.yourcompany.teamonly.app behind the sign-in screen. Every response, including the sign-in screen, tells search engines not to index it, and the sign-in screen shows only the app’s name and the ways to sign in.
No keys in the code that runs in the browser
What goes wrong
AI tools put API keys in the React code or in variables starting with VITE_ or NEXT_PUBLIC_. Everything sent to the browser can be read by anyone who opens the app. Supabase says its secret key must never be in a browser, because it skips every database rule.
Check it yourself
Ask your AI tool: “Is any key, token or password in front-end code, a VITE_ variable or a committed .env file?” In the browser, open the developer tools and search the loaded files for key, secret and sk_. If a key was ever exposed, change it at the service that issued it.
On TeamOnly
Partly handled. Keys are stored with npx teamonly secrets set NAME, outside the code, and only your app’s server code can read them. The instructions TeamOnly adds tell your AI tool never to use VITE_ keys. Nothing stops you from pasting a key into the code yourself, so still check.
The database can’t be read around the app
What goes wrong
With Supabase and similar services, the browser talks to the database directly and access rules (row-level security) decide what it can see. When those rules are off or wrong, anyone with the public key can read or change whole tables. That was the Lovable finding.
Check it yourself
In Supabase, open Advisors, then Security Advisor. Any “RLS disabled in public” error means a table anyone can read. A rule existing is not enough: sign in as an ordinary coworker and try to open someone else’s record.
On TeamOnly
Handled for outsiders. Each app’s database has no address of its own on the internet. It is only reachable through your app’s server code, after sign-in. Which rows each signed-in person may see is still your app’s code to get right (see check 8).
Each app’s data kept apart
What goes wrong
Several apps share one database or one storage bucket because it was quicker. Then a key or a bug in one app opens all of them.
Check it yourself
Ask: does any other app use the same database, storage or keys as this one? If yes, the weakest app decides how safe all of them are.
On TeamOnly
Handled. Each app gets its own database, file storage and secrets on first deploy, and its session cookie is tied to its own address. Apps can’t reach each other’s data.
Who can do what, checked on the server
What goes wrong
The AI hides the Approve button from most people but leaves the approve route open to anyone signed in. Or the server trusts a role or email the browser sends. Broken access control is number one in the OWASP Top 10. Unchecked input is a cousin: a negative amount, a SQL query built from a text box.
Check it yourself
Sign in as an ordinary coworker and try what only managers should do. Ask your AI tool: “For each API route, who may call it, and where on the server is that checked? Do all database queries use placeholders?”
On TeamOnly
Partly handled. Your app gets the verified person (ctx.user) and the roles you give out in the dashboard (ctx.user.roles), and faked identity headers are removed. The instructions tell your AI tool to use query placeholders and check input on the server. Checking the role in each route is your app’s code. TeamOnly doesn’t review it.
Every package is real and needed
What goes wrong
AI tools sometimes suggest packages that don’t exist. Attackers publish packages under those names, so installing one runs a stranger’s code inside your app.
Check it yourself
Open package.json. For any name you don’t recognise, look it up on npmjs.com: a real package has a history, a linked source repository and steady downloads. Run npm audit before you deploy, and remove packages the app no longer uses.
On TeamOnly
Not handled. TeamOnly doesn’t scan packages. An app can only reach its own data and keys, which limits what a bad package can touch, but inside that app it could still read everything.
A record of who changed what
What goes wrong
Something gets approved, deleted or changed and nobody can say who did it. AI-built apps rarely keep a history unless you ask for one.
Check it yourself
Ask your AI tool to record who created and last changed each record, and when, and to keep a history table for approvals and deletions. Try it: change a record, then look for your name on it.
On TeamOnly
Partly handled. The dashboard shows every deploy of every app, with who deployed and when, and live logs. Logs are live, not stored. Audit logs of sign-ins and access changes are on the Business plan, set up with you. History inside the app (who approved an expense) is your app’s job.
An owner, a backup and a plan for leavers
What goes wrong
The builder leaves and the app keeps running on their personal account, or stops when their card is cancelled. Or a bad change wipes a table and there is no copy.
Check it yourself
Write down who owns the app and who takes over. Keep the code in a company Git repository. Ask your AI tool to add a CSV export of the main tables, and try it.
On TeamOnly
Partly handled. Apps belong to your company, and admins can hand an app to a new owner. Turning off someone’s work account stops new sign-ins. People already signed in stay in until their session ends, and admins choose how long that is, from 8 hours to 30 days. There is no backup or export button in the dashboard today, so build the export into the app.
03Print this
The one-minute check
Eleven yes-or-no questions. Any “no” is the next thing to fix.
Before I share this app
A private browser window shows a company sign-in and nothing else.
A personal Gmail or Outlook account is turned away.
Only the people who need this data can open it.
A site: search for the app’s address finds nothing.
No key, token or password is in the browser code or the repository.
The database can’t be reached without going through the app.
This app’s data and keys are not shared with any other app.
An ordinary coworker can’t do what only managers should.
Every package in package.json is real and still used.
Records show who created and changed them.
Someone else knows they own this app if I leave, and the data can be exported.
Fifteen minutes with the builder, screen shared. You are checking setup, not reading every line of code.
Where it lives and who can reach it
Get the address. Open it from a device that is not signed in, and from a personal account. Ask which platform hosts it and whose account pays for it. A personal account is the first thing to change.
What data it holds
Ask what goes in and where it comes from. Customer personal data, payment data, health data or passwords to other systems raise the bar, and may mean the app should be limited to a named list.
Where the keys are
List every outside service the app calls. Each key should be in the host’s secret settings, scoped to what the app needs, and not shared with other apps. Rotate any key that was ever in the code or in chat.
Who can do what
Have the builder sign in as an ordinary user, or ask a coworker to, and try the admin actions. Ask the builder to have their AI tool list each API route and where it checks the role. Gaps here are fixed in the app’s code.
Packages and code
Look at package.json together and run npm audit. Ask that the code lives in a company Git repository, not only on the builder’s laptop.
Owner, and the day they leave
Write the app, its owner, a backup owner, its data and its users in your app list. Agree what happens when the owner leaves. The shadow AI apps guide has a one-page policy you can copy.
They can be. The common problems are where the app lives and how it was set up: a public link, no real login, keys in the browser, database rules turned off. Each one can be checked in a few minutes. Run the checklist on this page before you send the link.
What is the biggest security risk in a vibe-coded app?
Data anyone can reach without signing in. That usually happens in one of two ways: the app is on a public link with no login in front of it, or the database answers requests directly and its access rules are off (row-level security in Supabase). Both are about setup, not about the AI writing bad code.
Is it safe to put my Supabase anon key in the browser?
The anon or publishable key is made to be in the browser, but only because row-level security limits what it can reach. If row-level security is off on a table, anyone with that key can read and change it. The secret or service_role key must never be in the browser: it skips every rule.
Does “Sign in with Google” limit an app to my company?
Not on its own. By default any Google account can sign in, including personal Gmail. Google’s hd setting only narrows the account picker, and Google says not to rely on it. The app’s server has to check the domain in the verified sign-in token on every request.
How do I check if my app is indexed by Google?
Search Google for site: followed by your app’s address, for example site:myapp.lovable.app. If pages show up, the app is public and indexed. Make the app private or move it behind a company login, then ask Google to remove the pages with the Removals tool in Search Console if you own the domain.
Should I tell my AI tool to write secure code?
Yes, and it is better to give it standing instructions than to ask once. A rules file in the project (CLAUDE.md, AGENTS.md or a Cursor rule) tells the tool where keys go, how to write database queries and where to check roles. npx teamonly init adds these for TeamOnly apps. Then still run the checks yourself: instructions reduce mistakes, they don’t remove them.
Does TeamOnly scan my app’s code for security problems?
No. TeamOnly puts a company login in front of every app, keeps each app’s data and keys apart, and keeps apps out of search engines. It does not review your code, scan your packages or check the rules inside your app. Those items on the checklist are still yours.
What should IT check before approving an AI-built app?
Where it is hosted and who can reach it, how sign-in is restricted, where the keys are, what data it holds, who owns it, and what happens when that person leaves. The “For IT” section on this page is a short review you can run in 15 minutes with the builder.
Deploy with one command and the app is behind your company login, out of search, with its own database and secrets. Try it free for 14 days with no card.