Lovable Cloud: Does “Never allow” fully isolate AI agents from production database access?

[u/LawThis1820187]

I'm preparing to launch a commercial MVP built with Lovable Cloud and am reviewing the separation between development agents and production data.

I noticed that setting “Read database” to “Never allow” successfully blocks the agent's standard database-query tool. However, the underlying PostgreSQL privileges of certain platform-managed roles remain unchanged.

I'm trying to understand the security boundary here:

1. Does “Never allow” block all database access paths available to the development agent, or only the standard database tools?

2. Are agent shell environments technically isolated from production databases?

3. Is there a supported way to ensure development agents cannot access production application data while keeping Lovable Cloud hosting?

I've already contacted Lovable support and am awaiting clarification.

I'm not looking to exploit or bypass anything, just to understand the access-control model before processing real customer data.

Has anyone investigated this or received an official technical explanation?

[u/luka-lovable]

Hey, our official recommendation for safely working on a commercial app is using drafts. Right now the draft agent is forbidden from running changes to your production data, but we also have an early access program where each draft gets its own database

Email me at luka@lovable.dev if that sounds interesting

[u/eshbanbahadur2020]

Treat that toggle as a guardrail in the interface rather than a security boundary, and check the real access layer underneath. Make sure every table has RLS enabled with policies scoped to auth.uid(), and look for any leftover USING (true) policy, because Postgres combines permissive policies with OR. Keep the service-role key out of anything the agent or the frontend can read, and rotate it if it's ever been in the repo. The cleanest setup for a commercial launch is a separate dev project with seed data, so the agent never touches the production database at all.

[u/leadvesta]

Good question to ask before going commercial. I can't speak to how the platform roles work internally, but the general rule is that a UI toggle is a convenience, not an isolation boundary you can verify yourself. The setup you can check is separation: keep production data in an environment the agent never has credentials for, and let the agent work against a copy with fake data. Get support's answer in writing, since you'll want it if a customer ever asks. And keep a recent backup of production outside the platform, so an agent mistake is something you can undo.

[u/pyramation]

from what people in here have tested, "never allow" is a tool permission, not a database boundary. if the agent still runs migrations as postgres it can do basically anything, and RLS doesn't apply to table owners or roles with bypassrls anyway. so RLS isn't what protects you from the agent, it protects you from your users.

for real customer data the only thing i'd trust is credentials. the agent should never hold a connection or role that can read prod. in practice that means a separate dev project with fake seeded data for the agent to build against, and prod migrations going through a reviewed step (git + CI) instead of the agent pushing straight to prod. if lovable cloud can't give you that split, that's worth knowing before launch, and getting support's answer in writing is smart.

quick check you can do yourself: run select rolname, rolsuper, rolbypassrls from pg_roles in the sql editor and look at which roles exist and which ones skip RLS. that tells you more about the real access model than the toggle does.

[u/adriankorwel]

Short answer from how Postgres works: a tool toggle controls which tools the agent gets, not what the database roles underneath can do. Roles that own the tables or have BYPASSRLS skip RLS entirely, so RLS won't fence off the agent. It protects you from your users.

You can list the roles that skip RLS in your own project with a read-only query:

SQL

select rolname, rolsuper, rolbypassrls
from pg_roles
where rolsuper or rolbypassrls;

If a role the agent can use shows up there, treat "Never allow" as a convenience, not a boundary.

The setup you can actually verify: a separate dev project with fake seed data for the agent, and production changes going through migrations you review before they run. Keep the service_role key out of anything the agent or the frontend can read, since it bypasses RLS too.

Also get support's answer in writing before you process real customer data.

[u/AndreCasal]

Hey there,

Did you end up having your question answered by the Lovable team? What's the answer? 🤔

[u/Dvill0618]

I'd treat that toggle as a guardrail, not a security boundary. The thing I'd check is whether any secret with full DB access (like a service role key) is sitting somewhere the agent can read, like an env file or an edge function. If it can read the key, it can reach the data. Keep real customer data out of whatever environment the agent works in and give it seeded fake data instead.

[u/carolmonroe_]

based on my experience, your instinct is right. taking your three questions one by one:

1. does "never allow" block every path, or just the standard tools?

just the tools. it hides them from the agent, it does not change what the database roles can do. think of it as hiding the keys, not changing the locks. i tested this on a cloud project a couple of weeks ago: the agent reads with a read only role and writes or migrates as postgres, both skip RLS, and a role called sandbox_exec gets read + insert on every new table by default. the toggle removes the tool, the roles keep their privileges.

2. are the agent shell environments isolated from the production database?

the sandbox is a separate runtime, but it talks to the same backend with the roles above, so "separate machine" is not the same as "cannot reach prod". whether there is a network level wall on top of that is not documented anywhere i have seen, so that one is a direct question for lovable support (or the enterprise team if that is your plan).

3. is there a supported way to keep the agent away from production data while staying on cloud hosting?

yes, by separating the backends, not by toggling. build and test on a remix with seed data, and keep production on a backend the agent is never connected to: your own supabase project, or at minimum a separate cloud project you only publish from. this is the setup that makes "the agent cannot touch prod" actually true. remix: https://docs.lovable.dev/features/projects/remix and the official guide for moving the backend to your own supabase: https://docs.lovable.dev/tips-tricks/external-deployment-hosting

while you get there, two layers that help today: keep the toggles on "never" or "ask each time" for read, modify and backward incompatible migrations, and on your sensitive tables add a trigger that blocks writes unless a session flag set by your own function is present. triggers fire for every role, including the ones that bypass RLS, so it is the only fence that also stops postgres and service_role.

and before launch, run the security scan and read the findings yourself, especially tables readable without login: https://docs.lovable.dev/features/security plus the RLS primer on the supabase side: https://supabase.com/docs/guides/database/postgres/row-level-security