Skip to main content
Glama
README.md
# Airlock RLS MCP — Supabase leak checks inside your AI coding agent

> Let Cursor, Claude Code, or any MCP client **check a Supabase app for leaks while it builds it.** It catches the most common vibe-coding footgun: a `service_role` key shipped to the browser, and Row Level Security that's off or wide open.

The engine is [Airlock RLS](https://github.com/mateuszingano/airlock-rls) (`npm i airlock-rls`), the CI gate for Supabase RLS. This package is a thin MCP wrapper around it.

## Two tools

**`scan_site_for_exposed_key`** — give it a deployed URL. It reads the page and its JS bundles for an exposed Supabase `service_role` key (a `service_role` JWT or an `sb_secret_...` key). No database, no credentials, just the public URL. A hit means anyone who reads it bypasses **every** RLS policy. It never prints the full key.

**`audit_supabase_rls`** — give it a Postgres connection string. It fails on RLS-off tables, permissive (always-true) policies, and anon/authenticated tenant leaks. It reads **only** catalog metadata (`pg_tables`, `pg_policies`, grants), never your row data, so a read-only role is enough.

## Add it to your MCP client

```json
{
  "mcpServers": {
    "airlock": {
      "command": "npx",
      "args": ["-y", "airlock-rls-mcp"]
    }
  }
}
```

That's the same block for Cursor (`~/.cursor/mcp.json`), Claude Desktop (`claude_desktop_config.json`) and other MCP clients. With Claude Code:

```bash
claude mcp add airlock -- npx -y airlock-rls-mcp
```

Then ask the agent things like *"scan https://myapp.com for an exposed Supabase key"* or *"audit the RLS on this database"* and it calls the tools.

## Requirements

Node.js 18 or newer.

## Develop

```bash
npm install
npm run smoke   # starts the server and checks both tools are advertised
```

## More

Guides on Supabase RLS, a live cross-tenant demo, and the hosted Airlock Monitor (continuous checks of your live database): [shipsealed.com](https://shipsealed.com/?utm_source=readme&utm_medium=referral&utm_campaign=airlock-rls-mcp)

## License

MIT © Mateus Zingano

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools target entirely different surfaces: one greps a deployed website's HTML/JS bundles for leaked keys, the other inspects a Postgres/Supabase catalog for RLS misconfigurations. There is no overlap in inputs, resources, or failure modes, so an agent can never misselect between them.

Naming Consistency4/5

Both names are snake_case and verb-first (scan_site_for_exposed_key, audit_supabase_rls), which is a predictable convention. The only minor deviation is that one embeds a prepositional phrase while the other is a flat verb+object, but the pattern is still readable and consistent.

Tool Count3/5

Two tools is thin even for a narrowly scoped security-audit server; there is no tool for configuring scope, aggregating findings, or emitting a structured report. Each tool clearly earns its place, but the surface is smaller than the domain implies.

Completeness3/5

The two core checks (frontend key leak, database RLS) are well covered, but a Supabase security audit naturally extends to storage bucket policies, auth/edge-function configuration, and security-definer function review, none of which exist here. Agents must treat this as a partial audit rather than full coverage.

Maintenance

ActivityMaintained
ResponsivenessNo issues