An AI-built app can show your users' data to strangers: what to check before launch

Hello. Today's episode is for anyone who has built a website or an app with an AI agent and put it online. Or who is only about to. Since the start of November, several reports have come out, and they all say the same thing. Apps that AI builds in an evening are showing other people's data to strangers: profiles, private messages, passport numbers, passwords. And in almost none of these cases did anyone break in.

Here is what you will take away from this episode. You will understand how an app can work perfectly and still be open to anyone who walks by. Why the thought "nobody will ever find my little site" no longer protects you. Why a "Sign in" button and the green check mark of an automated scan prove nothing yet. And how someone can take your money through your keys, even if you followed every instruction. Most importantly, every point comes with ready-made instructions you can give your agent today.

One caveat, and we will not come back to it. The numbers in this story are loud, and the headlines are louder. Almost all the data comes from researchers who sell security reviews themselves, and from companies describing their own breaches. So every number here is their estimate. And where a number means something other than what it seems, I will say so right away.

Let's start with a simple question. How can a stranger read your database if they did not hack anything? To understand this, you need to picture, just once, what is inside an app. It really is not hard.

An app has two parts. The first is the page a person sees in the browser. The second is the database, the tables that hold users, orders and messages. In the usual setup, there is one more program between them, running on a server. It works like a guard at the entrance: the page asks for data, the guard checks who is asking and decides what to show them.

Now, in apps built by app builders and agents, that guard is often missing. The page in the visitor's browser talks to the database directly, on its own. To do that, it needs a key, and the key sits right in the page's code, where anyone can see it. It sounds like a hole, but it is by design. Supabase, a database that agents are very fond of, calls this key public and says plainly that it is "safe to expose online."

So where is the protection? In the database itself. It is a set of rules: who can see and change which rows of a table. Supabase calls this Row Level Security. Remember that name, it will be useful when you talk to your agent. A rule works like an invisible condition that the database adds to every request on its own. For example: show a person only the orders where they are the buyer.

And here is the key point. If there are no rules, or the rule says "allow everyone," any visitor to the site can read the table. Not a hacker, just a person with a browser. According to the Supabase documentation, such a table can be not only read but also changed. In other words, the door has a lock, it simply was never locked.

What does this look like in real life? Crissy Field, a small security firm from Hamburg, worked with the German business newspaper Handelsblatt to check sites built with Lovable. Lovable is an app builder where you describe the app in words and AI builds it. Nearly twenty-five thousand of these sites handed out database records to any visitor, without a login. On its own, that number is not yet a disaster, and the researchers stress this. A restaurant menu also lives in a database, and everyone is supposed to see it.

The trouble starts after that. The researchers sent these sites a few more requests, read-only. On more than seven thousand sites, they found tables with email addresses. Not every such table means a leak, since an address can be public or just test data.

But some findings leave no room for argument. On one forum, more than eighty thousand profiles with names and dates of birth could be read. The same forum exposed more than two hundred thousand chat messages. And one service had more than a thousand records with passport numbers open to anyone.

And here is what matters more than any number. The author of the report put it this way: "no advanced hacking techniques were used, and anyone with a moderate understanding of how the web works will be able to reproduce the results." The researchers planned to start with the basics and then move on to more sophisticated attacks. They never got to the sophisticated part, because so much was already lying on the surface. Whether anyone used this data to cause harm, they could not establish.

You might object here: that is an app builder, but my project is built by an agent in the terminal, so what does it have to do with me? It has everything to do with you, because the setup is the same. A page plus a database that the browser talks to directly also shows up in many projects built with Claude Code. And it is not only about Supabase. Firebase, another database of the same kind, is blunt about the "allow everyone" rule in its documentation: "NEVER use this ruleset in production; it allows anyone to overwrite your entire database."

So the first instruction for your agent is not about security at all. It is about understanding your own project. Say this: explain to me in simple words how my app is built. Where is the data stored, and what is the database called? Does the page in the browser go to the database directly, or through a program on a server? Where is it set up who can see what?

The answer will take half a page. But from then on, you will be applying this episode to your own project, not to other people's sites.

Now the question that naturally comes up. Why does an AI that writes a working app in an evening not set up these rules by itself? The answer is simple, almost painfully simple. The agent solves the task you gave it. You asked for orders to be saved and displayed. They are saved and displayed.

But who should see which orders is not a technical question. It is your decision about your business. Can a manager see other managers' orders? Can a customer see other people's reviews with phone numbers? If you did not say, the agent has no way to know. It will pick the option where everything works. And the most reliable way to make everything work is to allow everyone.

This is not a guess. A scientific study this year examined two hundred live apps built by AI. Ninety-one percent had at least one vulnerability, and the main type of error was exactly that: broken access control. The authors see one of the causes in the agent's goal of simply making things work. Another of their conclusions is worth knowing in advance: good prompts lower the risk but do not remove it. So words are not enough, you also need testing, and we will get to that.

By the way, human programmers make mistakes in the same place. In the industry ranking of the most dangerous vulnerabilities, access errors are in first place. AI did not invent this problem. There are simply far more apps now, and they are made by people whom nobody has told about these rules.

What should you do about it? First and most important: describe the access rules to your agent in plain words, at the very start of the project. You do not need to know how they are written in the database. You need to say it in human terms: a guest sees only the storefront, a buyer sees only their own orders, an administrator sees everything. One sentence like that changes how the agent builds the database.

Second: ask the agent to work on the principle of "closed by default." Every new table starts out inaccessible to anyone, and only what you have named gets opened. And have the agent write this into the file with the project's standing instructions. Otherwise, a week from now, in a new conversation, it will not remember.

Third, a review of what is already built. The instruction goes like this: list all the tables in the database and, for each one, explain in simple words who can read it and who can change it. Separately, show me the tables that have no protection or have an "allow everyone" rule. You will get a list about a page long. In it, you will see at once which table is the storefront and which holds customers with phone numbers.

In the same review, ask the agent to look for three common mistakes, which are described in the Supabase documentation. The first one you already know: "allow everyone" on a table with personal data. The second is trickier. The rule lets in anyone who is signed in, without checking whether the row belongs to them. The third is truly sneaky. The mark that says "this person is an administrator" is stored in the part of the profile that users can edit themselves. Anyone who wants to can simply make themselves an administrator.

If your agent answered that you use Supabase, there are a few more things specific to it. A table that a person creates by hand in the service's dashboard gets protection right away. But your agent does not use the dashboard. It creates tables with commands, and on those tables the protection does not switch on by itself. So ask it to turn on Row Level Security on every table. And to set up the database so that it switches on automatically for every new table.

Supabase also has a built-in Security Advisor. It looks for tables without protection and for columns with sensitive data that are visible from outside. Your agent can run it on its own. Ask it to, and have it explain each finding in simple words: what it is, what the risk is, and how it proposes to fix it.

And a fresh trap that few people have heard about. Since October thirtieth, Supabase has changed how all projects behave: a new table is not reachable from outside until it has been explicitly granted access. It is a good change, but it has two sides. Old tables stayed as they were, so whatever was already open will not close by itself. And on new tables, the agent will now run into a "permission denied" error more often.

This is where you need to be careful. The fastest way to make that error go away is to grant access to everyone. An agent that was simply told "fix it" may well take that route, and everything will work. So give it a standing rule, also in the instructions file. An access error must never be fixed by opening access to everyone. First explain who you want to allow to do what, and wait for my answer.

Now about the database keys. There are two kinds. The public one sits in the page's code, and that is fine. The secret one bypasses all the protection rules at once, and it belongs only on the server. Ask your agent directly: do the files that a visitor's browser downloads contain a secret key, passwords or lists of users?

This is not an idle question. One of the November reports describes a contractor's staff timesheet. Its code, which every visitor receives, held eighteen employee accounts. With the passwords in plain text, administrators included. Imagine that. There is no need even to read the database, everything has already arrived in the browser.

A separate word about files. If your app stores scanned documents, contracts or photos, ask your agent what kind of storage they are kept in. In public storage, anyone who has the link to a file can open it. You need private storage. Then a person is given a temporary link that stops working soon after.

And the last check in this part, the most honest one. Ask your agent to visit your published site the way a stranger would. Without signing in, using only the public key that is already in the page's code anyway. Have it try to read every table and show you what came back: are there names, emails, phone numbers, orders. Read-only, and only your own site. In essence, this is what the researchers in Hamburg did. The difference is that now you will be the first to see the result.

Let's move on to the second lesson. Many people reason like this: all right, something of mine may be open, but who will find my site among millions? The address is long, it is not published anywhere, and three people know it. Unfortunately, that reasoning no longer works. Let's look at apps from the Grok app builder.

Grok has a tool called Grok Build, where apps are also built by describing them in words. Researchers from the company Claroc found tens of thousands of these apps online and opened the first page of each one. More than thirty-five thousand opened without any login. Most of them are harmless: games, simple pages, calculators, which do not need a login anyway. But several hundred held personal data. The authors estimate their number at between six hundred fifty and eight hundred apps.

And what apps they were. A staff list for a hospital group, more than three and a half thousand people, and the list could be searched. A briefing on a single intensive care patient, with lab results and the status of the ventilator. A fire department's shift board with names and badge numbers. These people are easy to understand. They built themselves a handy work tool, put real data into it and sent the link to their colleagues.

So how were these apps found, if only colleagues had seen the link? Every published app has its own site name. When a colleague opens the link for the first time, their computer asks the internet's directory service where the site with that name lives. It is like calling directory assistance: to be connected, you have to say the name out loud. Special services collect the records of these questions, and you can search them by a name pattern.

It turns out that a link stops being a secret the moment someone first follows it. Grok suggests four random words as the name, and no one could guess that. But the researchers note: "Nobody would guess one, and nobody needs to, because the dataset lists them." For the same reason, it is not worth hiding tables behind unusual names. The database itself may hint at the correct name in an error message.

The second half of this story is a setting that was chosen for you. When the researchers published their own app, they were offered three access options: Anyone with the link, Invited users, and Only you. The first one was already selected. A person clicks "Publish," changes nothing, and the app is open to the whole internet. And it does not have to be this way. In ChatGPT, you can also publish an app you have built, and there the default was "Only me."

And one more mechanism worth keeping in mind. The team in Hamburg described it precisely. App builders create apps from the same templates. So, as they put it, "An approach that works against one app may then work against others with little extra effort." And there are thousands of others. You do not need to be an interesting target. It is enough to look like everyone else.

What does this mean for you? First: before every release, find out who will be able to open the app. If your agent publishes it, ask it directly: who will see this app through the link, and what exactly will they see without signing in? If you publish through an app builder, this setting is on the publishing screen, and you will have to look at it yourself. Everything internal should be only for you or for invited people. Treat the option "Anyone with the link" as publishing to the entire internet.

Then do one simple thing with your own hands. Open the app in an incognito window, without signing in. A stranger should see a sign-in page or an error, not your data. You do not need to understand anything technical here, you only need to look at the screen.

Second: do not put real data into trial apps. It is understandable to want to test an idea on a real export of your customers. But a trial app is published the same way as a real one, and it is watched far less carefully. Ask your agent to generate a hundred made-up customers with realistic names and phone numbers. That is enough to test an idea.

Third: go through everything you have already published. After a year of working with agents, a person can easily collect a dozen forgotten projects. Ask your agent to help you make a list: what was published from your folders and where it lives now. For each item, there are only two choices. If I need it, I check it. If I do not, I take it down. On Grok, according to Claroc, an app that has been taken down stops opening immediately.

And fourth, about links to chats. When you share a conversation with an AI model, that link works differently, and it does not end up in those records. But search engines can find the page. In August of last year, more than three hundred seventy thousand Grok conversations that people had shared by link turned up in Google search. So it is sensible to treat a shared chat link as public. And not to leave anything in such a chat that you are not ready to show everyone.

The third lesson is the most deceptive, because it is about a false sense of safety. The app has a "Sign in" button. The automated scan showed a green check mark. So everything is fine? Unfortunately, no.

The same Claroc researchers ran a simple experiment. They asked Grok to build a customer list for a team of four. Grok, on its own and without being asked, added sign-in with a Google account. It looks like care for security. But the code worked like this: first it added whoever signed in to the team, and then it checked whether they were on the team. The check, of course, always passed.

Then they signed in with someone else's Google account, one that nobody had invited. This stranger saw every customer, changed one record and deleted another. That is the core of it. Signing in answers the question "who are you." Data protection answers the question "are you allowed." These are two different checks, and AI confidently does the first while forgetting the second.

Another of their test apps had no login at all. They opened it in an incognito window and added a row to the database. The next visitor saw that row. So a stranger can not only read your data but also damage it. They proved this on two of their own apps, and did not touch anyone else's.

Now about the green check marks. Automated security checks exist in both app builders and agents. Claude Code, for example, has a command for a security review and a plugin that reviews the code after each step. These are useful tools. But they have two limits, and it is better to know about them.

The first limit is written right in the Claude Code documentation: "the review reads the source code in your checkout, not a running site or deployed service," and "the review model can miss issues." Rules that are set directly in the database may never appear in the code at all. There will be nothing to check, and the check mark will stay green.

The second limit applies to all scanners. It is easy to notice that a rule is missing. It is much harder to notice a rule that exists but lets in the wrong people. When Lovable got its first scanner last year, the researcher who had found the problem described it this way: it "checks for the existence of any RLS policy, not its correctness." How accurate today's scanners are has not been independently tested in any public source.

There is also a human side. Why do people not fix even what the scanner has found? Lovable's head of security, Igor Andriushchenko, answered this when developers were discussing the Hamburg report. In his words, "for many users it's the fear that the fix will break production." And that fear is not unfounded. In his words, "some folks find it easier to build with no RLS and then add them later. But for a complex app, it's a hard task, things break."

Notice this mechanism, because it applies to any tool. Protection that is put off until later turns into a repair job that everyone is afraid of. The app works, users have arrived, and touching it is scary. And so it stays open for months.

And the last point in this part: who is responsible if the data leaks? Lovable's website says, "No, you don't need to know how to code." Yet its terms of use say that "AI Output may contain errors," and "You are solely responsible for reviewing, validating, and using any AI Output." One could argue for a long time about whether that is fair.

But something else is more useful. Ask your agent to read the terms of the services your project runs on and summarize one passage for you: who is responsible for users' data. Most likely, the answer will not surprise you. You are.

What to do. The main tool here is called the two-account test, and it is simpler than it sounds. You create two test users, the first and the second. The first one creates an order or a note. Then the second one tries to see it, change it and delete it. If any of that works, the protection is not working, no matter what the scanner shows.

Doing this by hand is tedious, so give it to your agent. Say this: write an automated test that creates two users and checks that the second cannot read, change or delete the first one's data. Add a third participant who has not signed in at all, and who must not see anything personal. Run this test before every release. If the test fails, the release does not go out.

If the app is internal, for a team, add one more check. Sign in with an outside account that nobody invited. Did it let you in? Then the app needs a list of approved people. Ask your agent to build exactly that, a list, and not just a sign-in button.

Second rule: protection goes in before the first real data, not after. This is the advice of Lovable's head of security himself, who recommends "building with all security features on from the beginning, never trying to slap it on top after the fact," and here it is hard to argue with him. While the database is empty and there are no users, there is nothing to break. The agent will calmly set everything up, and the two-account test will confirm it.

And what if the app is already running and you have only just realized that it is open? Then it needs fixing, but carefully, so that the very fear we talked about does not come true. Ask your agent to make a copy of the database first. Then close one table at a time, and after each one run the tests and check the main functions. That way, if something breaks, the breakage will be small and easy to understand. Fixing everything in one go on a Friday evening is a bad idea.

Third. Use automated checks, but treat them as one layer among several. When you run one, ask your agent to explain each finding and tell you what will happen if it is not fixed. Do not close the window with the warnings, even if there are many of them. But do not take the green check mark as proof either. The proof is the two-account test and a check of the live site through a stranger's eyes.

And fourth, when you cannot do without a human. If your app stores documents, medical information or payment data, it is worth ordering an outside access review before launch. And repeating it after major changes. That is what the researchers in Hamburg advise. Yes, they sell such reviews themselves, and that should be kept in mind. But the same thing is written in Lovable's own documentation.

The fourth lesson is about your money. Until now, we have been talking about users' data. Now about what hits your own card directly. These are the keys to paid services.

First, let's figure out whether this applies to you. Your subscription to Claude Code or Codex is not a key, you simply sign in to your account. A key appears when your app itself calls a paid service. For example, your site has a chat assistant that sends visitors' questions to an AI model. The service needs to know whom to charge, and for that your app has a key, a long string of characters. Whoever holds the key spends from your account.

If you do not know whether you have such keys, ask your agent. The question is simple: which paid services do my projects call, and where are the keys for them stored? Keys are usually kept in the settings of the hosting service, the service where your app lives on the internet. Every guide recommends this, and the advice is correct. But this autumn it turned out that even correct storage is sometimes not enough.

In October, the hosting service Railway was breached. According to the company's own report, the attacker went through customers' saved settings and picked them out by name. In other words, they were deliberately fishing for keys to AI models and cloud services. Then other people's requests started running on those keys. Railway estimates this spending at about seven hundred forty thousand dollars across all affected customers. Who will pay a customer back depends on whose key it was: every provider has its own rules, and where a provider does not refund, Railway promises to pay itself.

Why would anyone want other people's keys to AI models? To sell access. That is exactly how another company, Fireworks, explains the breach it suffered. Fireworks is a cloud where people run open models. It links the attack to a group that makes money by reselling stolen access to models. Keys to AI have become a commodity, and people hunt for them on purpose.

And here is a detail that is very much about you and me. Through Fireworks, the well-known note-taking service Notion was affected: transcripts of users' conversations with its AI assistant ended up with the attackers. While dealing with this, Notion found keys in the messages that people had pasted into the chat themselves. The company directly advised customers to replace everything they had pasted there. People write keys and passwords into conversations with an AI model, and then those conversations live a life of their own at an intermediary they have never even heard of.

Now the instructions. First, a spending cap. Almost every provider lets you set a monthly spending limit in your account. Ask your agent to find in your provider's documentation where this is set, and to walk you through it step by step. While it is at it, have it suggest a reasonable amount based on your usual spending. This limit will not prevent a key from being stolen. It will limit the bill you receive afterward.

Second, a separate key for each project and for each provider. When one key is used everywhere, a leak means redoing everything. When the keys are separate, you turn off one, and the rest keeps working. That is what the code editor Cursor did. It gave Fireworks a separate key, and after the breach that key was simply turned off.

Third, an inventory. Ask your agent to make a list of all the keys across all your projects. Where each one is stored, which service it belongs to, and what money can be spent with it. And for each one, a short instruction on how to replace it. Important: the list should contain the names of the keys, not the keys themselves. A list like this will save you on the day an email arrives saying "we have had an incident."

Fourth, a habit. Do not paste keys and passwords into chats with AI. A key belongs in your project's settings, not in a conversation. If you have already pasted one, consider that key exposed and replace it.

Fifth. If your code is stored on GitHub, ask your agent whether push protection for secrets is turned on there. It stops a push if a key has ended up in the code. For public projects on personal accounts it is on by default, but for private ones it is worth checking. And if you work in Claude Code, its security review plugin can be given your own rules. For example, to raise an alarm when it sees a string that looks like a key.

And sixth, the simplest one. If you hear news of a breach at your hosting service or model provider, change your keys that same day, without waiting for a personal email. That is exactly what Railway advised its customers: replace everything sensitive that was stored before the day of the breach. With the list from the third point, this will take an hour, not a week.

That leaves the fifth lesson, and it continues the fourth. Your users' data passes through a chain of companies, most of which you did not choose and do not know by name. Notion's customers did not choose Fireworks. They were simply talking to the assistant in their notes.

Sometimes the chain is longer. The very key that Cursor gave to Fireworks fell into the attackers' hands. With the stolen access, they reached the extension catalog that Cursor runs for its editor. On October twenty-ninth, tampered versions of the Claude Code extension sat there for about eleven hours. By Cursor's estimate, no more than five thousand people could have received them. The company says it contacted each of them directly.

Does this affect you? Judging by Cursor's description, it concerns people who installed or updated that extension on that day, specifically from Cursor's catalog. If you work with Claude Code in the terminal and do not use the Cursor editor, this story did not touch you. But the lesson from it applies to everyone. A person simply updated an extension and was harmed because of a company they may never have heard of.

Your own project works the same way, only on a smaller scale. Your app sends an AI model whatever the user has written. Between you and the model there may be an intermediary service. All of it lives on a hosting service. Somewhere nearby there is a visitor counter and an email newsletter. Every link in the chain is a place where data can linger and from which it can leak.

Hence three instructions. First: ask your agent to make a map. Have it go through the code and list every outside service the app sends anything to. And for each one, have it say exactly which user data goes there. The list is usually longer than you expect. If your users live in the European Union, the law also requires you to keep this kind of record.

Second: send less. Look at the map and ask your agent about each link: can this task be done without sending a passport, a phone number or a full customer record there? Very often the AI model is fine with text that has no names in it. What you did not send cannot leak from an intermediary.

The third concerns your own tools. Ask your agent to show you which extensions and plugins are installed in your editor and in the agent itself. Most likely, you will not remember half of them. Keep what you actually use, and have it remove the rest. And if news of an incident comes in, follow the provider's instructions in full. Cursor gave a separate warning: "Uninstalling the extension alone may not be enough."

And the last practical point: what to do if a leak has already happened to you. The order is this. First, close the door: turn on the protection or take the app down. Then change all the keys that could have been visible. After that, work with your agent to find out which tables were open and whose data was in them.

Next comes the unpleasant but necessary part. The author of the Hamburg report describes it this way: the site owner has to "investigate how many of their customers are affected, notify them of the leak, and report it to the relevant authorities." If your users include residents of the European Union, the law gives you seventy-two hours to notify the supervisory authority. Other countries, Russia among them, have their own laws and their own deadlines. It is worth learning them in advance, not on the day of a leak, and this too can be handed to your agent.

And now a cheat sheet. Seven phrases you can say to your agent today, word for word. One: explain in simple words how my project is built, where the data is stored, and whether the page goes to the database directly. Two: list all the tables and tell me, for each one, who can read it and who can change it. Three: visit my published site as a stranger, without signing in, and show me what data it gives out.

Four: write a two-account test and run it before every release. Five: write down a rule for yourself that an access error must never be fixed by opening access to everyone. Six: make a list of all the keys in my projects, without the keys themselves, and write down how to replace each one. Seven: list the outside services the app sends user data to. All of it together will take one evening.

And the summary, very briefly. Working does not yet mean closed, until you yourself have told your agent who should see what. A long address, a sign-in button and a green check mark prove nothing. Only a check through a stranger's eyes proves anything. And keys are money, so each project gets its own key and its own spending cap.

And a few words from me personally. The story of keys found in other people's chats affected me more than anything else. Conversations with agents are, in essence, everything behind the scenes of a project: the code, the files, the keys, the plans. I believe such things are better kept in tools that do not send them anywhere. That is exactly why I first built Arsminal for myself.

In Arsminal, conversations, files and keys are stored only on your computer and your phone, and nowhere else. The connection between the computer and the phone is encrypted end to end. The encryption is post-quantum, following a standard that the American institute NIST approved in twenty twenty-four. The point is that what is intercepted today should not be decrypted even by the quantum computers of the future. The relay server passes along only encrypted noise, which it cannot read, and it records nothing. And voice commands are recognized right on the computer, so the recording never leaves it.

That is all for today. You have been listening to Evgenii Arsentev, creator of Arsminal, a terminal for managing AI agents where your whole agent team works in one window, like chats in a messenger. Founder of ArsentevAI, Dad4Kids and ReelsZavod. Try Arsminal for free at arsminal.com. Thanks for listening.