Is My Data Safe in an AI Builder? What to Check First
The important part of the answer is architectural rather than reassuring: in Zugo your application data does not live in the builder at all. It lives in your own Supabase project and your own Stripe account, under your name, on your plan. What is not automatic is the access rules, and testing those is your job.
Most articles on this question answer a different one, which is whether the company behind the tool is trustworthy. That is worth asking, but it is unanswerable from the outside. Where the data physically sits and who can reach it are checkable, so this post covers those.
Which data are we actually talking about?
Three separate kinds, and conflating them is why the question feels murky.
There is the material you type into the builder: prompts, project descriptions, the build history. There is your application's own data: the rows your app stores, the accounts your users create, the files they upload. And there is your customers' payment data, which is a category with its own rules and its own regulator.
Each one lives somewhere different and each one has a different failure mode. A worry about prompt confidentiality is not the same worry as a customer reading another customer's orders, and the second is far more likely to actually happen to you.
Where does each kind of data live?
In accounts you already control, for everything that matters.
| Data | Where it lives | Whose account |
|---|---|---|
| Database rows your app stores | Supabase | Yours |
| User accounts and sign-in | Supabase | Yours |
| Files your users upload | Supabase storage | Yours |
| Payments, cards, subscriptions | Stripe | Yours |
| Transactional email delivery | Resend | Yours |
| Source code, once exported | GitHub | Yours |
| Traffic measurement | Google Analytics | Yours |
| Prompts and build history | Zugo workspace | Your Zugo account |
| The published page itself | <slug>.zugo.run, or your domain |
Served by Zugo, owned by you |
Read that column of "yours" carefully, because it is the substance of the answer. If a builder holds your database, leaving costs you the data. If the database was always in your own Supabase project, the builder is a tool that wrote code against it, and the code exports to GitHub whenever you want.
The one row that surprises people is payment data. Card numbers never touch your application, because Stripe handles them, which is exactly the arrangement a competent developer would have built anyway.
What does a generated app do for security, and what does it not?
It generates the code, including the parts that filter data by the signed-in user when you ask for that. What it does not do is decide your permission model, and it cannot know that you meant something different from what you wrote.
Every build is booted in a sandbox before it reaches you, and a build that fails to load is reported as a failure rather than handed over. That is a render check. It lowers the risk of receiving a blank page and tells you nothing whatsoever about who can read what.
The distinction is worth stating bluntly, because "verified" reads like "safe" and it is not. A sign-in page that lets everybody through loads perfectly and passes the check. Security is a property of the rules, and rules are tested by trying to break them.
How do you test that the rules actually hold?
With a second account, by hand, before anyone else touches the app. This takes about fifteen minutes and it is the highest-value thing you can do after a build that involves accounts.
| Test | How to run it | What a failure looks like |
|---|---|---|
| Cross-account read | Create a record as user A, then sign in as user B and try to open it directly by its address | User B sees user A's record |
| Signed-out access | Sign out, then open a page that should be private | The page renders instead of redirecting |
| Duplicate sign-up | Register twice with the same email | A second account is created |
| Password reset | Request a reset and wait for the email | Nothing arrives, because Resend is not connected |
| Admin boundary | Sign in as an ordinary user and try an admin address | The admin view opens |
The first row is the one that matters most. If user B can reach user A's record by typing its address, the rule was applied in the page rather than enforced in the database, and that is the correction to ask for in your next edit.
Fixing it costs an edit at 3 credits, which is a trivial price for the problem it prevents. The broader setup for accounts is covered in can AI build user login.
What should you never put in a prompt?
Live secrets. API keys, passwords, tokens and database credentials belong in the connector setup, which is designed to hold them, rather than pasted into a description of what you want built.
The same restraint applies to real customer records. If you want the build to show a table of orders, describe the shape of an order and let the generator invent example rows. Real names, real addresses and real card details do not make the output better and they widen the circle of places your customers' data has been.
This is ordinary hygiene rather than a Zugo-specific rule, and it is the same advice you would get about any chat interface, any support ticket, and any screenshot pasted into a group thread.
What are your obligations rather than the tool's?
The ones that were never software, and they do not transfer to a builder.
A privacy policy that matches reality. If your app collects email addresses, say so, say why, and say how someone gets them deleted. Generating the page does not generate the policy.
Deletion and export requests. Depending on where your users live, they may have a right to their data or to its removal. Because the data is in your Supabase project, you can honour those requests. Because it is your Supabase project, nobody else will.
Who has access. Connector credentials are keys to real systems. Treat a Supabase service key the way you treat the key to the office.
Review before money or personal data. Generated access rules deserve a reading by someone who thinks adversarially. Zugo does not replace a development team on a complex product, and access control is where that limit bites hardest.
What are the honest limits of this answer?
Three, and they are the ones a marketing page would leave out.
No builder can promise your app is secure. It can generate reasonable code, boot it, and report a failure as a failure. Whether the rules you described are the rules you needed is a judgement no automated check makes.
Very specific access rules take several passes. Organisations with teams, nested roles and per-record sharing are built up through successive edits rather than one prompt. That is the intended workflow, and it means the security model exists only after the passes you actually ran.
Third-party services have their own terms. Supabase, Stripe, Resend and Google each have their own data handling, and their documentation is the authority on it, not a blog post written by someone else.
The practical move is to keep the data in accounts you own, export the code so a reviewer can read it, and run the two-account test before you invite anybody. Exporting is covered in can I export the code, the connector setup is in the Supabase guide, and when you are ready to try the sequence, describe your permission rules in one paragraph at Zugo and test them before you launch.