db-impersonate

Sets PostgreSQL session JWT claims to emulate an authenticated user for RLS policy testing.

3|Updated Feb 7, 2026
One-click install
npx skills add https://github.com/gabrielnsmnto/kord-aios --skill db-impersonate-gabrielnsmnto
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: db-impersonate
Source: https://github.com/gabrielnsmnto/kord-aios/tree/main/src/features/builtin-skills/kord-aios/database/db-impersonate
Command: npx skills add https://github.com/gabrielnsmnto/kord-aios --skill db-impersonate-gabrielnsmnto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Testing Row Level Security policies requires seeing the database exactly as a specific authenticated user does, which is difficult without logging in as that user. This Skill sets session-local JWT claims in PostgreSQL so you can run queries under any user's identity and verify RLS isolation directly. ## Core Features & Use Cases - Session Claim Injection: Sets request.jwt.claims, request.jwt.claim.sub, and role via set_config so auth.uid() returns the impersonated user. - Positive and Negative RLS Tests: Provides query patterns to confirm users can access their own data and cannot access other users' data. - Multi-Tenant and Debugging Workflows: Supports org_id claims for org-based isolation and troubleshooting steps for NULL auth.uid(), missing policies, and service-role bypass issues. - Use Case: After creating a new RLS policy on a fragments table, impersonate user A to confirm they see only their rows, then impersonate user B to verify tenant isolation before deploying the migration. ## Quick Start Ask the agent to impersonate a specific user ID so you can run test queries against your Supabase database and verify the RLS policies behave correctly.

Frequently Asked Questions about db-impersonate

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test RLS policies as a specific user in Supabase?▼

Set the session JWT claims with set_config for request.jwt.claims and role, then run queries in the same psql session. auth.uid() will return the impersonated user ID so RLS policies evaluate as that user.

How to impersonate a user in PostgreSQL for testing?▼

Use SELECT set_config('request.jwt.claims', jsonb_build_object('sub', user_id, 'role', 'authenticated')::text, true) inside a psql session. The setting is session-local and resets when the connection closes or RESET ALL runs.

Why does auth.uid() return NULL when testing RLS?▼

auth.uid() returns NULL when the JWT claims were not set correctly in the session. Verify the claim format with current_setting('request.jwt.claims', true) and confirm the role is set to authenticated.

Can I test RLS policies with the Supabase service role key?▼

No, the service role bypasses RLS entirely and sees all data. You must connect with the authenticated role and set session claims to test how policies affect real users.

Is it safe to use session claim impersonation in production?▼

No, manually setting JWT claims is strictly a testing and debugging technique. Production applications must use Supabase Auth with real JWT tokens from authenticated user sessions.