The admin key is not a fix for a policy error
When a policy blocks a query, the fastest thing that makes the error go away is the service-role key, which bypasses every policy. The model reaches for it. Now the browser, or an edge function that trusts the browser, owns the database. One app in the research ran 41 days like that.
Where it bit
Research only. The detection is trivial, which is what makes it a good receipt: fetch the bundle, find a JWT, decode it, read the role claim.
The practice
Service-role key in server env only. Every server route verifies the caller's JWT before it does anything as admin. A CI grep of the built bundle for any JWT whose payload decodes to service_role.
Check it
grep -rhoE "eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+" .next/ dist/ | sort -u | while read t; do echo "$t" | cut -d. -f2 | base64 -d 2>/dev/null | grep -o '"role":"[a-z_]*"'; done
Get this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.