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 modesCopy Anchor Link

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 beginCopy Anchor Link

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

SetupCopy Anchor Link

1. In the Agent Authority console, go to Tools & Services 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 registrationCopy Anchor Link

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 connectionCopy Anchor Link

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 connectCopy Anchor Link

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 toolsCopy Anchor Link

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 scopesCopy Anchor Link

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 examplesCopy Anchor Link

Read-only Supabase for everyoneCopy Anchor Link

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

1. In Agent Actions, 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 docsCopy Anchor Link

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. That is 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.

Block destructive toolsCopy Anchor Link

One deny rule blocks every tool tagged destructive, regardless of its name:

1. In Agent Actions, click Add Rule and name it "Supabase: no destructive tools."
2. Set the effect pill to Deny and the MCP scope pill to Supabase.
3. Open the Tools pill and pick the built-in tag destructive.
4. Set the status to Active and click Create.

Next stepsCopy Anchor Link

• 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.