Three things jumped out at me from UpGuard’s latest research into data exposure in Supabase apps:
1. AI is building backends that the people running them may not fully understand.
UpGuard looked at roughly 300,000 domains showing signs of Supabase usage and found 16,326 databases exposing readable tables. More than half had database schemas indicating that some PII could potentially be present.
And this wasn’t just a consumer-app problem. UpGuard found that whether an app was B2B or B2C made no meaningful difference in the kinds of data likely to be exposed. Their conclusion: in many cases, AI built the application, the application worked, but the person running it didn’t understand the database configuration behind it. That’s the part I think everyone building with AI should pay attention to.
2. An app working doesn’t mean its access controls are working.
Supabase commonly uses its Data API alongside database-level controls like grants and Row Level Security (RLS). UpGuard notes that while RLS is enabled by default when a table is created through Supabase’s Table Editor, it is not automatically enabled when tables are created programmatically—the way AI coding agents often work.
This same class of RLS misconfiguration was documented in CVE-2025-48757, involving Lovable-built applications using Supabase. Researchers found 170 of 1,645 analyzed projects with inadequate RLS configurations.
To Supabase’s credit, they have been changing their defaults. New projects are moving toward requiring an explicit grant before a new table becomes reachable through the Data API.
But the broader lesson remains: AI can build something that functions correctly while an authorization rule is still missing or incorrect.
3. Trust needs to be understandable before you ship, not discovered afterward.
This is where Xano takes a different approach.
In Xano’s standard application model, access to database data is exposed through APIs. Authentication, ownership checks, queries, and other authorization logic can live directly inside those API workflows, where another person can inspect what has actually been built.
Xano apps can still be misconfigured; we’re transparent about that. Auto-generated endpoints, for example, need to be reviewed and secured before production. But Xano gives teams a clear inventory of those endpoints, the ability to disable external access or require authentication, and middleware that can apply shared security checks and suspicious-pattern logging across an API group.
And when AI builds the backend, the result doesn’t have to remain a black box.
Xano Agent creates standard Xano resources that can be reviewed visually or as code. Changes can be inspected as a diff, tested in an isolated environment, and verified before they reach production.
That’s the bigger conversation I think we should be having as AI changes how software gets built:
It’s no longer a question of whether AI can build; it's whether a human can understand what AI built, see every path to the data, and verify that those paths are secure.
That’s what secure AI-assisted development should look like.
