saranskumar Goal
Design RLS policies that make data access safe, explainable, and testable.
When to Use
- Tables are known and access rules must be enforced.
- A Supabase feature involves user-owned or workspace-owned data.
- Existing policies are confusing or unsafe.
Instructions
- Identify the actor, table, action, and ownership rule.
- Map policies for
select,insert,update, anddeleteseparately. - Prefer membership and ownership checks over ad hoc role strings.
- Call out service-role-only paths and backend bypass rules.
- Use
references/rls-patterns.mdfor common patterns andexamples/for shape.
Constraints
- Never rely on the frontend as the only access control layer.
- Do not write one giant permissive policy for all cases.
- Keep policy assumptions explicit and tied to schema.
Output Format
- Access model summary
- Policy matrix
- SQL policy drafts
- Edge cases and tests
Examples
- "Design RLS for workspace members and admins."
- "Review these Supabase policies for unsafe access."