Secure Supabase access for AI agents

Supabase is one of the sharpest tools you can hand an agent. execute_sql runs raw SQL against your project's database; apply_migration changes its schema; deploy_edge_function ships code. All of that is genuinely useful during development and genuinely destructive by accident. Adding Supabase here puts every call through your policies and onto the audit log, so you can decide which of those tools an agent ever gets to reach.

Server URL: https://mcp.supabase.com/mcp

Credential modes

Supabase supports per-org dynamic registration only, so there is no app to create on Supabase's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you begin

• A Supabase account that can reach the projects your agents need.
• Administrator access to your Agent Authority workspace, to add the resource.

Setup

1. In the Agent Authority console, go to Resources and click Add Resource.
2. Select Supabase from the catalog.
3. On Choose how to install Supabase, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.

Dynamic client registration

When you add the resource, the gateway registers its own OAuth client with Supabase – the credential that lets it sign users in. Supabase's own organization and project-level permissions still apply, so an agent can only reach what the person who signed in could already reach.

Verify the connection

The gateway syncs the Supabase tools automatically. To check the connection end to end, ask your agent to run a request:

List my Supabase projects

If your projects come back, the connection is working.

How users connect

Access is per user. Each additional user connects their own Supabase account the first time their agent calls a Supabase tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Available tools

Supabase exposes 29 tools. They are grouped below; the resource's Overview tab shows the authoritative per-tool list under Available Tools once installed.

Required scopes

The gateway does not request a fixed scope list for Supabase. It registers the client without naming any scopes and records the ones Supabase returns.

Policy examples

Read-only Supabase for everyone

One deny rule blocks every tool that can change something, leaving inspection on the default path:

1. In Access Policies, click Add Rule and name it "Supabase: no writes."
2. Set the effect pill to Deny and the MCP scope pill to Supabase.
3. Add these tool patterns: execute_sql, apply_migration, deploy_edge_function, create_*, delete_*, merge_branch, reset_branch, rebase_branch, pause_project, restore_project.
4. Set the status to Active and click Create.

create_* covers create_project and create_branch; delete_* covers delete_branch. The rest are named because they don't share a prefix. Reads – list_*, get_*, search_docs, generate_typescript_types – keep working.

If you want the SQL reads too, allowing execute_sql back in is not something a tool pattern can do safely. Enforce it with a read-only Postgres role in Supabase itself, and let the connection's own permissions be the boundary.

Scope one agent to inspection and docs

An allow rule on its own restricts nothing, because every org is seeded with an Allow all rule that anything unmatched falls through to. To confine an agent, pair the allow with a deny beneath it:

1. Create the deny rule first: effect Deny, MCP scope Supabase, Agent scope your agent, tool pattern *.
2. Then create the allow rule: effect Allow, MCP scope Supabase, the same Agent scope, tool patterns search_docs, list_projects, get_project, list_tables, list_extensions, list_migrations, get_logs, get_advisors.

New rules insert at the top of the list, so creating the deny first leaves the allow above it – the order you need. Evaluation is first-match-wins: the eight inspection tools match the allow, every other Supabase call matches the deny, and neither reaches Allow all.

Scope both rules to one agent. An unscoped deny would cut Supabase off for every agent and user in the org.

Next steps

• Create a policy – the full rule editor walkthrough.
• Policies – how first-match-wins ordering and the default Allow all rule interact.
• Data Protection – redact keys and other sensitive values out of tool responses before an agent sees them.