> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clarion.cantina.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Supabase

> Give agents read-only access to a Supabase project — security advisors, auth and Postgres logs, schema, and SQL — during an investigation.

Supabase is a hosted Postgres platform. Connecting it lets agents check what your database is actually doing while triaging: whether row-level security is off on an exposed table, whether the auth log shows a burst of failed sign-ins, when a schema change landed, and what a bounded query returns.

<Note>
  **Estimated time:** 2 minutes. You authorize Clarion through Supabase — there is no token to create or paste.
</Note>

## Prerequisites

* A **Supabase** account with at least one project
* Permission to authorize an OAuth application for that organization

## Connect

1. In Clarion, open **Integrations** and find **Supabase**.
2. Click **Connect with Supabase**. You will be sent to Supabase to authorize Clarion for one organization.
3. Back in Clarion, choose the **project** agents may read.

Agents have no Supabase tools until a project is selected — the project is what scopes the connection. Access is stored encrypted, expires on its own, and is renewed automatically; it never enters the agent sandbox.

To revoke access outside Clarion, remove the Clarion app under your organization's **OAuth apps** in Supabase.

## Read-only by design

Clarion connects to Supabase in read-only mode, scoped to the single project you choose:

* Queries run as a **read-only Postgres user**, so a write fails rather than taking effect.
* The connection is **scoped to one project**, which also puts organization-level actions out of reach — agents cannot see, create, pause, or restore any other project in your organization.
* Only the **database** and **debugging** tool groups are enabled. Migrations, edge-function deploys, branching, and storage settings are not available at all.
* Every tool Supabase advertises is checked before an agent is given it, and anything that writes is refused — including a tool Supabase labels read-only but names as a write.

This is why the integration is safe to point at a production project. There is no setting that turns writes on.

Supabase's MCP server does not yet accept read-only OAuth grants — it currently requires an app to be granted every scope — so read-only rests on the four controls above rather than on the authorization itself. We will narrow the grant as soon as Supabase supports per-scope consent.

## What agents can do

The tool list is mirrored from Supabase and refreshed daily, so a read tool Supabase adds becomes available without waiting on a Clarion release. Today that is:

| Tool              | What it returns                                                                                                                                                                   |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `get_advisors`    | Supabase's own security and performance lints — RLS disabled on an exposed table, tables with RLS but no policy, `SECURITY DEFINER` views, mutable `search_path`, missing indexes |
| `query_logs`      | Project logs from the last 24 hours — `auth`, `postgres`, `api`, `edge-function`, `storage`, `realtime`                                                                           |
| `list_tables`     | Tables and RLS status; columns, keys, and constraints when the agent asks for the verbose form                                                                                    |
| `list_extensions` | Installed Postgres extensions and versions                                                                                                                                        |
| `list_migrations` | Applied migrations, so a schema change can be lined up with an incident                                                                                                           |
| `execute_sql`     | Rows from a read-only SQL query                                                                                                                                                   |

## Where it helps

Start with `get_advisors` for any question about exposure — it returns findings rather than customer data, and it is usually the fastest route from "is this project exposed?" to a concrete answer. Use `query_logs` with the `auth` service when investigating suspicious sign-in activity, and `list_migrations` when you need to know whether a schema change lines up with the start of an incident.

<Warning>
  `execute_sql` reads your production data, and what it returns becomes part of the investigation record. Secret-shaped values are redacted before anything is stored or displayed, but that catches credentials, not personal data — nothing bounds which columns a query selects. If a project holds data you would rather no investigation ever surface, connect a project that does not.
</Warning>

## Change projects

The connection is bound to one project ref. To point Clarion at a different project, disconnect and reconnect with the new ref.

## Disconnect

Click **Disconnect** on the integration page. The stored token is deleted.