Is it a mistake that the anon key is in the code?

No. In Supabase the anon key is public by design. What protects it is RLS: without access policies on the table, that key is enough to read it.

How do I know if a Supabase table is exposed?

Open Table Editor. If the table does not say RLS enabled, it is open to anyone who has the project URL and the anon key.

Is AI Studio safe for storing customer data?

Only if security was requested and verified. The tool generates what you describe; what you do not pin down, it decides on its own. With sensitive data, check RLS and authentication before launching.

Security in GHL AI Studio with Supabase: The Role in the Browser Is Not Access Control

The public key is not the problem

An AI Studio app with Supabase carries the anon key inside the code that downloads to the browser. That is normal and by design in Supabase: that key is public and made to be exposed. Do not "fix" it by hiding it.

What is a problem

In a real app we reviewed, the user's role (administrator, employee) was read from localStorage, that is, from the browser itself. Anyone can open the console and type one line to become an administrator. A role that lives in the browser is not access control: it is a suggestion.

The dangerous combination has three pieces:

The anon key ships in the code (normal).
The role can be forged in the browser.
RLS off on the table.

With all three, anyone with the URL can read the whole table from the console. If that table holds customer, patient or payment data, it is not a theoretical risk: it is a leak.

The five-minute test

In the Supabase dashboard open Table Editor and look at each table. It must say RLS enabled. If it says "unrestricted", it is open.
In the browser, open the app, the developer tools and the local storage tab. If you see a key with the role ("role", "admin") that the app uses to decide what to show, the control is in the wrong place.
Check whether the app really uses Supabase Auth (email and password sign-in) or just a decorative login screen.

How to fix it

The role travels with the user, not with the browser. Store it in a users table and read it from the server.
Turn on RLS on every table and write policies tied to the signed-in user. A minimal example:

alter table pedidos enable row level security;

create policy "cada quien ve lo suyo"
on pedidos for select
using (auth.uid() = usuario_id);

Ask for security in the prompt. AI Studio makes up or neglects whatever the prompt does not pin down. Tell it explicitly: authentication with Supabase Auth, role in the database and RLS on every table.

Regulated data

If the app stores health data, the responsibility belongs to the business owner, not the tool. In the United States HIPAA applies. HighLevel says it on its own page: it is not HIPAA compliant by default. You have to buy and activate its HIPAA module (US$297 per month or US$2,970 per year, according to that page, checked on October 2, 2026), sign the BAA agreement inside the app and accept that final responsibility sits with your organization. And all of that covers HighLevel, not the external database that AI Studio connects: an app with Supabase needs its own compliance. In the Dominican Republic, health data is sensitive under Law 172-13.

An ethics rule for auditing

Do not query a third party's protected table to "prove" it is open. If the data belongs to real patients or customers, looking at it is already the harm. Confirm the risk from the structure (where the role comes from, which key it carries, which tables exist) and tell the owner. A live test is only done on a project of your own or with the owner's authorization.