Supabase permission denied" in production

The preview environment cheats. That is the core insight that took me a full afternoon to internalize. When you run a Lovable or Bolt app locally, the Supabase client often bypasses Row Level Security entirely because your development session uses the service_role key. That key has infinite permissions. Your deployed app uses the anon key. That key has exactly zero permissions until you write RLS policies. I started tracing the actual SQL queries my app was sending. The preview showed a beautiful profile page. The deployed version showed an empty div. The difference was a single missing USING clause in a policy that should have read USING (auth.uid() = id). The AI builder generated the policy template but left the condition as a placeholder. It worked in preview because the service_role key never checks conditions. The fix forces you to understand Supabase's permission model. Every table needs policies for SELECT, INSERT, UPDATE, DELETE. Every policy needs a proper USING or WITH CHECK expression. The AI can scaffold the schema but it cannot guess your auth logic. You must write those conditions yourself. Test with the anon key locally by creating a .env variable that switches keys. If it breaks locally with the anon key, it will break in production. That saved me three redeploys.