Goal
Restore Supabase Row Level Security guidance so agents do not bypass database authorization when implementing features.
Repository Context
This application uses Supabase PostgreSQL and Supabase Auth.
workspace-app/
├── src/
│ ├── app/
│ ├── services/
│ └── supabase/
├── supabase/
│ └── migrations/
├── package.json
└── AGENTS.md
Users belong to organizations, and application data is organization-scoped.
Row Level Security is enabled on application tables.
The repository follows these rules:
- User-facing data access must respect RLS policies.
- New tables containing user or organization data must have RLS enabled.
- Required policies must be created through migrations.
- The Supabase service-role key bypasses RLS and must not be used in normal user-request flows.
- Service-role access is reserved for explicitly trusted server-side administrative operations.
Current AGENTS.md
# Project Instructions
## Supabase
- Use Supabase for authentication and database access.
- If an RLS policy prevents a feature from working, use the service-role client to bypass the policy.
- New tables do not need RLS until the application is ready for production.
## Database
- Store schema changes in Supabase migrations.
## Validation
- Run relevant tests after changing data access.
Your Task
Repair the Supabase instructions so agents preserve Row Level Security.
Require RLS and appropriate policies for user or organization data, and prevent the service-role client from being used to bypass authorization in normal user-request flows.