Shipping AI-built apps to production: what the public evidence says and how to check yours

What the research shows

Exposed databases at scale

In September 2026, UpGuard published research on applications built on Supabase, a hosted Postgres service widely used with AI coding tools. Starting from about 300,000 domains with indicators of Supabase usage, UpGuard found 16,326 databases exposing publicly readable tables; over half showed indicators of personal data (PII) based on their table schemas. A smaller share included passwords or authentication tokens. (UpGuard, "Everything Everywhere: Systemic Data Exposure in Supabase Apps" ↗)

Two details matter when reading that figure. First, UpGuard classified databases by their table schemas rather than reading every row, and it notes that its results skew toward personal data partly because it queried for a "users" table. Second, "readable" here means the database returned data, or named an accessible table, when queried from outside with the application's public configuration. The causes UpGuard describes are configuration problems: row-level security (RLS) that is missing or does not restrict access, and public keys used as if they were secret.

Supabase's position, as given to TechCrunch by its chief information security officer, is that projects are secure by default and that security is shared: "We provide secure defaults and tooling, and customers control how their own projects are configured." (TechCrunch, 25 September 2026 ↗)

Supabase's own documentation states the rule plainly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." It also notes that on projects that still grant the anonymous and authenticated roles access by default, adding policies does not remove those grants; they have to be revoked. (Supabase docs, Row Level Security ↗)

Security of generated code

Veracode's 2025 GenAI Code Security Report (July 2025) tested more than 100 large language models on 80 coding tasks in Java, Python, C# and JavaScript. In 45% of cases, the generated code introduced an OWASP Top 10 vulnerability. (Veracode report, PDF ↗; Veracode blog, 30 July 2025 ↗)

The measurement is narrow by design: four vulnerability classes (SQL injection, cross-site scripting, weak cryptography and log injection), tested with static analysis. It does not cover access rules in a database, which is where the exposures above originate. Veracode's Fall 2026 update (29 October 2026), which tested 18 newer models on the same four vulnerability classes, reports the first meaningful movement in the series: the share of tasks producing vulnerable code fell from roughly 44% in its previous quarterly snapshot to about 38%, with the gain concentrated mainly in cross-site scripting. (Veracode, Fall 2026 update ↗) The direction is encouraging; roughly 4 in 10 tasks still produced vulnerable code, so generated code still needs to be checked.

Documented incidents

These are summarised from vendor statements and reporting. They describe different kinds of failure, and they should not be read as one story.

Lovable: database access rules (2025). CVE-2025-48757, published on 29 May 2025, describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that allowed unauthenticated attackers to read or write arbitrary tables of generated sites. The record carries a CVSS 3.1 score of 9.3 (critical), assigned by MITRE as the CVE numbering authority. Lovable disputes the CVE, on the grounds that each customer is responsible for protecting their application's data. (NVD ↗) The researcher, Matt Palmer, reported that a scan of 1,645 Lovable projects found 170 with inadequate RLS settings. (Palmer, statement on CVE-2025-48757 ↗) Semafor noted that Palmer worked at Replit, a competitor. (Semafor, 29 May 2025 ↗)

In a separate case reported in February 2026, a researcher said an app hosted on Lovable exposed 18,697 user records. Lovable told The Register that its pre-publish security scan had recommended fixes the owner did not apply, and that the project included code not generated by Lovable and a database not hosted by Lovable. (The Register, 27 February 2026 ↗)

Base44: platform authentication (2025). Wiz Research found that private applications on Base44, owned by Wix, could be accessed by registering through undocumented endpoints using only a non-secret app ID, bypassing authentication controls including single sign-on. Wiz reported it on 9 July 2025; Wix fixed it within 24 hours, and Wiz published on 29 July 2025. Wix said it found no evidence of exploitation. This was a vulnerability, not a confirmed breach. (Wiz Research ↗)

Replit: production data and agent permissions (2025). In July 2025, Replit's AI agent deleted the production database of an app being built by SaaStr founder Jason Lemkin, during an explicit code freeze. The data was later restored through rollback. Replit's CEO described it as "Unacceptable and should never be possible," and the company announced separate development and production databases for Replit apps. (The Register, 21 July 2025 ↗; The Register, 22 July 2025 ↗; Replit blog, 21 July 2025 ↗) No outside attacker was involved. It is an operational failure: the tool that changed the code could also change live data.

What these have in common

None of these turn on an obscure attack. They are about who can read or write which data, which credentials are exposed, whether development can touch production, and whether recovery works. Those are properties of the whole system, and an application can work correctly for its users while getting all of them wrong. That is why they tend to surface after launch rather than in a demo.

How to check yours

The following is the order we use. A team can work through most of it without outside help.

1. List every table and who can reach it. For each table in an exposed schema, record whether RLS is enabled, which policies exist, and which grants the anonymous and authenticated roles hold. A policy that only checks "signed in" is not tenant isolation. Test from outside: use the public key from your own client bundle, sign in as a user of one tenant, and try to read another tenant's rows.

2. Find the keys. Search the repository history and the built client bundle for service keys and third-party secrets. Anything with elevated privileges belongs on the server only. Rotate anything that has ever been committed.

3. Check each server-side operation for authorization. For every API route and serverless function, confirm that it checks who is calling and what they may do, and that the check is not inverted. Generated access logic can look plausible and still allow the wrong caller.

4. Separate development from production. Confirm that development tools, preview deployments and AI agents cannot write to production data, and that production credentials are not in development environments.

5. Restore a backup. A backup that has never been restored is an assumption. Restore to a separate environment, time it, and write down the steps.

6. Map personal information. List where personal data is stored, which services process it, where they are located, and who can access it. In Québec, this is also the starting point for the privacy impact assessment that the private-sector privacy act, as amended by Law 25, requires for projects to acquire, develop or overhaul an information system involving personal information. (LégisQuébec, P-39.1, s. 3.3 ↗) The legal assessment is for your privacy officer and advisors; the map is the technical input.

7. Review AI features separately. Record what data is sent to model providers, which actions a model can trigger, and what validates its output before it reaches a user or a database.

8. Write the closure test before the fix. For each problem you find, write the check that will show it is fixed, then fix it, then run the check. Put the checks that can be automated into CI so a later change does not reopen the problem.

How Lavinium approaches it

Our production-readiness audit follows the same steps with more depth, and adds three things:

• Evidence tied to the code. Each finding is reproduced in a non-production environment and traced to a file and line, a query or a policy.
• A classification and a plan. Each finding either blocks launch, blocks a feature, or is debt to track. The remediation plan is phased, and each step has a closure test written before any fix exists.
• Separation between the audit and the fix. Findings and closure tests are delivered before any remediation is proposed. You can remediate with any team. The retest runs the original closure tests; when we carried out the fix, it is performed by an engineer who did not write it, and the report says so.

The audit is not a penetration test or legal advice, and it does not state that a system meets a law or a customer's requirements. It gives your team and your advisors the technical facts to decide.

If a launch with real data or a customer security review is coming, the audit is built for that point.