airlock-rls-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_site_for_exposed_keyA | Scan a DEPLOYED website's HTML and JavaScript bundles for an exposed Supabase service_role key (a service_role JWT or an sb_secret_... key). Needs only the public URL — no database, no credentials. A found key is a critical leak: it bypasses ALL Row Level Security, giving anyone who reads it full read/write to the database. Use this right after deploying a Supabase app, or whenever an AI-generated app might have bundled a secret into the frontend. Never prints the full key. |
| audit_supabase_rlsA | Audit a Supabase/Postgres database's Row Level Security. Fails when a table has RLS disabled, when a policy is permissive (USING (true) / WITH CHECK (true) or anything that reduces to always-true), when an anon or authenticated policy does not scope rows to the caller (tenant leak), and on exposed materialized views. Reads ONLY catalog metadata (pg_tables, pg_policies, grants, functions, views) — never your row data. A read-only connection string is enough. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
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.
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.
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.