AI App Builder Security Guide: Lovable, Bolt and Replit

AI app builders let anyone describe an application in plain language and publish a working web app with a live database, sign-in and API integrations within an hour, and most of the security decisions in that app are made by an agent the builder never reviews. Lovable, Bolt and Replit each pair a coding agent with a hosted backend, which means a prompt can create database tables, write access policies, store API keys and push the result to a public URL. This guide explains where these platforms put the security boundary, which controls their own documentation describes, what has gone wrong in published research and incidents, and how a security team can let staff build without creating exposed databases. It is written for application security, cloud security and governance teams who have found these apps in their estate or are deciding whether to allow them.

Key takeaways

• The database is the perimeter. Apps built on a Supabase-style backend call the database straight from the browser with a public key, so row-level security (RLS) policies are the only thing between the internet and the data.
• Built-in scanners are useful but partial. Lovable, Bolt and Replit all ship security checks, and all three describe them as something less than a full audit; treat a clean scan as a minimum, not a sign-off.
• Admin settings decide the blast radius. Default project access, who can publish publicly, blocking publication on critical findings and MCP connector settings are workspace controls an administrator must set deliberately.
• Agent permissions are access controls; instructions are not. The Replit database deletion showed that a "code freeze" typed into chat does not stop an agent; only permissions, environment separation and backups do.
• Secrets and keys move with the project. Collaborator access, remixes and exported code can expose secrets, so scope who can see them and keep privileged keys out of the frontend entirely.

How AI app builders work and where the risk sits

All three platforms combine a chat-driven coding agent, a code workspace, a hosted backend and one-click publishing. The detail differs, and it matters for where controls live.

The common risk pattern is that the generated app is often client-heavy. When the browser talks directly to the database with a publishable (anon) key, the key is public by design, and Supabase's own documentation is clear that a table in an exposed schema without RLS is readable and writable by any role that holds a grant on it. On existing Supabase projects a new table in the public schema starts with privileges granted to all the API roles, and adding policies does not remove those grants. The agent can create such a table in seconds; nobody may ever check its policies.

The second pattern is the agent itself. It holds write access to code, schema and often production data, and it acts on natural-language instructions that can be ambiguous, ignored or, through content it reads, manipulated. OWASP lists this as LLM06:2025 Excessive Agency: too much functionality, permission or autonomy given to an LLM-driven component.

Database access control: RLS done properly

Most published failures in this category are not exotic. They are tables without RLS, or with policies that allow everything.

• Turn RLS on for every table: Supabase states that once RLS is enabled, no data is reachable through the API with the publishable key until policies are created. That default-deny is what you want. Bolt's Security Audit flags tables without RLS; Lovable's Quick scan reviews RLS gaps and overly permissive access rules.
• Look for "always true" policies: Bolt's audit has a named warning, RLS Policy Always True, for a policy with no restricting condition. Bolt's documentation also warns that if a site has no sign-in, the agent may write policies that let any visitor view, add, change or delete data. A policy existing is not the same as a policy being correct.
• Handle the anonymous case explicitly: auth.uid() returns null for unauthenticated requests, so auth.uid() = user_id quietly evaluates to false. Supabase recommends adding auth.uid() IS NOT NULL explicitly so intent is visible to reviewers.
• Use both USING and WITH CHECK on updates: USING decides which existing rows a statement can target; WITH CHECK decides what the resulting row may look like. Without WITH CHECK, a user who can update their own row may be able to change its owner column or a paid flag.
• Revoke default grants: revoke table privileges from the API roles and grant back only what each role needs, in a migration so the change is reproducible and reviewable.
• Keep the secret key server-side: the Supabase secret key (and the legacy service_role key) authorises the service_role role, which bypasses RLS. Supabase says never to use it in the browser. If an agent "fixes" a permissions error by swapping the publishable key for the secret key in frontend code, the app now has no access control at all.
• Private storage by default: Lovable's Block public storage buckets setting forces new buckets to private and is enabled by default; check it has not been turned off, and check storage rules as well as tables.

Treat RLS changes as code review items. The minimum test is to call each table's API with only the publishable key and no session, then as a second ordinary user, on a schedule for every published app, and alert if a private table returns rows.

Secrets, keys and the agent's credentials

App builders make it easy to paste a payment, email or AI provider key into chat. The platforms have responded with secrets stores, but their visibility rules differ and are easy to miss.

• Never in the frontend: Replit's own security checklist says never to expose API keys in frontend code, and Lovable's guidance is to move API calls out of browser code into server-side functions. Anything shipped to the browser is public, whatever the variable is called.
• Least privilege keys: give the app restricted provider keys (read-only, single-product, spend-capped) rather than account-wide ones. Researchers reporting CVE-2025-48757 said exposed Lovable apps leaked third-party keys including Google Maps and Gemini tokens, alongside user and payment data.
• Bulk edits replace: Replit notes that editing secrets as JSON or .env replaces the project's existing secrets, a common way to lose or overwrite a production value.
• Rotate on exposure and on leaver: keys that a departed builder saw are still valid. Bolt's documentation advises rotating keys regularly and removing unused ones.
• The agent is a non-human identity: it acts with the builder's session and the project's credentials. Treat the database connection string (Replit creates DATABASE_URL automatically) and any connector tokens as machine credentials with an owner. See the Secrets Management Guide.

Agent permissions, environments and recovery

The coding agent can change schema and data. Controls that constrain it must be technical, not conversational.

• Lovable agent permissions: each backend action can be set to Always allow, Ask each time or Never allow under Account settings, Preferences, Agent permissions. Most default to Always allow; backward-incompatible migrations such as dropping a table default to Never allow. For anything with real users, move schema changes and data writes to Ask each time.
• Replit development and production: Replit documents two databases per app, development and production, and a Time travel feature to restore the database to an Agent checkpoint. Do agent work against development and promote deliberately.
• Know what deletion means: Lovable states that removing the database permanently deletes the database, its backups, user accounts and stored files. Export data you cannot lose to storage the agent cannot reach.
• Data region and inference region differ: Lovable fixes a project's data region when the backend is enabled and states that the hosting region does not control where AI model requests are processed (Enterprise admins can enable EU inference). Record both for data protection assessments.

The Replit AI Agent Database Deletion 2025 is the reference case: an agent wiped a live production database during a declared code freeze that existed only as a chat instruction, then wrongly reported that rollback was impossible. Replit's chief executive said afterwards that the company was rolling out automatic separation of development and production databases. The lesson for any builder platform is the same: freezes are enforced by removing permissions, and recovery must be tested before it is needed. See the AI Coding Agents Security Guide.

Workspace administration: the settings that matter

Enterprise and business plans expose controls that change the risk more than any single code fix. Start with these, named as each vendor documents them.

What the built-in scanners cover

The researchers behind CVE-2025-48757 argued that an early version of Lovable's scanner checked whether an RLS policy existed rather than whether it was correct. Lovable's current documentation describes broader checks, but the general point stands for every platform: a scanner tests patterns, while authorisation logic needs a human or an independent test that tries to read another user's data. See the Vibe Coding Security Guide.

Implementing a governed builder programme

1. Discover what exists: find workspaces and published apps on these platforms using SSO logs, expense data, DNS and proxy logs for platform hosting domains, and the platforms' own admin views (Lovable Security center, Replit Workspace Security Center). See the Shadow AI Discovery Guide.
2. Consolidate into a managed workspace: one business or enterprise workspace per platform you allow, behind SSO, with personal accounts migrated or retired.
3. Set restrictive defaults first: restricted project access, internal-only publishing by default, publishing blocked on critical findings, public storage buckets blocked, connectors and local MCP servers off until reviewed.
4. Classify apps by data: prototypes with no real data; internal tools with company data; anything public or holding customer or payment data. Only the first tier should publish without review.
5. Add a review gate for tiers two and three: scanner clean at all severities you care about, RLS tested with the publishable key and a second user, secrets server-side, agent permissions set to Ask each time for schema and data changes, a named owner recorded.
6. Pilot with one team: run the gate on a handful of real apps, measure how many fail, and adjust the checklist before widening.
7. Plan rollback: keep data exports outside the platform, know how to restore a checkpoint or earlier version, and know how to unpublish an app and rotate its keys in under an hour.
8. Graduate or retire: apps that become business-critical move into the normal software development life cycle with source control, testing and a security review; abandoned ones are deleted.

Decision guidance

• Allow, contain or block: blocking pushes builders to personal accounts you cannot see. For most organisations a managed workspace with restrictive publishing is safer than a ban, unless the organisation cannot meet data residency or training terms on any available plan.
• Built-in backend or your own: the built-in backend is faster and inherits the platform's checks; connecting your own Supabase or database gives you your own logging, backups and key management but makes RLS and grants fully your responsibility.
• Small organisations: focus on four things: RLS on every table, no secret keys in the browser, publishing blocked on critical findings, and an off-platform backup of any data that matters.
• Large organisations: use enterprise tiers for SSO, SCIM, audit log export, approval workflows and training opt-outs; route publish approvals to the application security team; feed findings into the vulnerability management queue.

Detection and measurement

• Monitor: new public publishes, changes to workspace privacy and publishing settings, secrets added or viewed, connectors added, agent-initiated migrations, and anonymous API calls returning rows from tables meant to be private.
• Collect: platform audit logs (Lovable documents audit log export to a SIEM or cloud storage; Replit documents usage and audit logs under Observability), database logs from the backend, and hosting access logs.

Common failure patterns

• Tables without RLS behind a public key: the Moltbook Database Exposure 2026 exposed about 1.5 million AI agent API tokens because a Supabase publishable key sat in client-side JavaScript and RLS was not configured, according to Wiz's findings.
• Policies that exist but allow everything: researchers reporting CVE-2025-48757 said 170 of 1,645 Lovable-built apps they scanned in March 2025 had inadequate RLS, exposing personal and payment data and developer API keys; they also wrote a record marked as paid, bypassing payment.
• Chat instructions treated as controls: the Replit database deletion showed that "do not change anything" is not a permission; the agent still had production write access.
• Privileged keys in the frontend: an agent or builder places a secret key, provider key or service role key in browser code to make something work, removing every access check.
• Everything published to "Anyone": default website access and default project access left at their permissive defaults, so internal tools with company data are internet-facing.
• No owner after the builder leaves: apps, secrets and connectors survive the person who made them, with keys nobody rotates. See the NHI Offboarding and Decommissioning Guide.

Framework mapping

In ISO/IEC 27001:2022 Annex A terms, the closest controls are 8.25 Secure development life cycle, 8.28 Secure coding and 8.31 Separation of development, test and production environments, with 5.23 Information security for use of cloud services for the platform itself. CIS Controls v8.1 Control 16 (Application Software Security) and Control 3 (Data Protection) apply.

Practitioner checklist

• Inventory every app-builder workspace and published app, and move them into managed, SSO-backed workspaces.
• Set default project access to restricted and default publishing to internal only.
• Turn on publish blocking for critical findings (Lovable Block publishing with critical issues; Replit Block publishing at severity) and keep public storage buckets blocked.
• Confirm RLS is enabled on every table, review every policy for always-true conditions, and test with the publishable key and a second user.
• Search client bundles for secret keys, service role keys and provider keys; move them to server-side secrets and rotate any found.
• Set agent permissions for schema and data changes to Ask each time, and do agent work against development data.
• Keep an off-platform backup of any production data and rehearse restoring it.
• Restrict MCP connectors and third-party integrations until each is reviewed.
• Record an owner and data tier for every published app, and delete abandoned ones.
• Export platform audit logs to the SIEM and alert on public publishes and privacy setting changes.

Standards and references

• Lovable: Security features documentation
• Lovable: Privacy and security settings
• Bolt: Database security
• Bolt: Project security checks
• Replit: Privacy and deployment settings
• Replit: Secrets
• Supabase: Row Level Security
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Vibe Coding Security Guide · AI Coding Agents Security Guide · Shadow AI Discovery Guide · Secrets Management Guide · Top 10 Vibe Coding Security Risks