See what an anonymous visitor and a random signed-in user can read and write right now, get fixes, and keep new tables protected automatically.
#Exposure check
Studio → Exposure check runs two things:
- A policy linter: tables with Row Level Security off, policies whose condition is always true for everyone, writable-by-anyone policies, views that run with their owner's rights, materialized views readable through the API,
SECURITY DEFINERfunctions callable through the API, public buckets. Each finding has a severity and, where possible, the SQL that fixes it. - A live test per table that acts as an anonymous visitor (your anon key) and as a random signed-in user, and shows how many rows each can read, update and delete and whether they can insert. It runs inside transactions that are always rolled back, with triggers off, so nothing changes (inserts may advance sequences).
GET /platform/v1/projects/<ref>/security/exposure?fresh=1The MCP tool check_exposure returns the same report, so an AI assistant can check its own work after creating tables or policies.
#RLS Guard
Turns Row Level Security on for every new table in public, however it is created: SQL editor, migrations, an ORM or an AI tool. On by default for new projects; turn it on for existing ones in Studio → Exposure check. A new table then returns no rows through the API until you add policies.
#Block exposing migrations
With this on, the migrations API (and stitchdb db push) refuses a migration that leaves a new critical exposure, for example a table with RLS off. Enable RLS and add policies in the same migration. You can also pass ?enforce=block on a single request.
PATCH /platform/v1/projects/<ref>/security/settings
{ "rls_guard": true, "enforce": "block" }