Database safety is not only about the database.
It is about every route, server action, policy and query that decides which data a user can see or change.
AI-built apps often start with broad queries because broad queries make the UI render quickly. That is fine in a prototype. It is not fine once real accounts, payments, prompts, support tickets or customer data exist.
The launch question
Before launch, every data access path should answer:
- who is the current user?
- which account, tenant or project are they acting in?
- what rows are they allowed to read?
- what rows are they allowed to change?
- what fields does the UI actually need?
- what should never leave the server?
If the answer is "the route trusts an ID from the browser", stop and review it.
Search for broad queries
Start with:
rg "findMany|findUnique|include:|select\\("
rg "where:|userId|accountId|tenantId|organizationId"
Then ask your agent:
Review every database query in this app.
For each route or server action:
- identify the current user
- identify the account or tenant boundary
- explain how ownership is checked
- flag broad includes or missing selects
- flag private fields returned to the browser
- propose the smallest safe query shape
Prefer explicit boundaries
Risky:
Read record by id from the URL, then return it.
Safer:
Read record by id and owner/account/tenant id for the authenticated user.
Return only the fields needed by the UI.
The difference looks small in code. It is the difference between "a user sees their own data" and "a user can guess another ID".
Watch generated admin code
AI agents are especially likely to generate admin-style code for convenience:
- list all users
- include every relation
- return full rows
- add "temporary" debug endpoints
- skip pagination
- skip role checks
If a route is truly admin-only, prove it in the route. Do not rely on the UI hiding the link.
Use this prompt:
Find every admin or internal data route.
For each one, verify:
- it requires authentication
- it requires an admin or owner role
- it cannot be called by a normal logged-in user
- it returns only the data needed for the admin screen
- it is not linked or indexed publicly
Pair this with API response review
Database safety and API response safety are the same workflow from two angles.
Read next:
- Stop over-sharing data from API routes
- Supabase RLS basics
- Authenticated routes and admin boundaries
What PageLens AI can help with
PageLens AI reviews the public and authenticated production surface. It can flag suspicious route exposure, weak authenticated flows, privacy gaps and trust issues.
It cannot prove every database invariant from outside the app.
Use PageLens AI for the external evidence. Use code search, tests and database policy review for the internal data boundary.