---
title: "Supabase"
description: "Scoped Supabase credentials for AI agents"
url: "https://gazebohq.com/services/supabase"
---

Supabase projects expose different kinds of credentials with very different consequences. A publishable or anon key is used with Row Level Security (RLS) in client-facing flows, while a service-role key is a server-side administrative secret that bypasses RLS. Agents building schemas, debugging storage, or running migrations should never receive the latter by default. Keep projects and environments distinct, validate RLS policies and database migration review, and use Gazebo to broker the particular project key only to the approved agent.

## Why scope Supabase credentials for AI agents?

A service-role key can bypass RLS and must be treated as a production administrator credential; Gazebo cannot make it row- or table-limited after delivery. The real capability boundary is the selected Supabase project, key type, RLS policy, database role, and any server-side API design. Gazebo adds agent-specific retrieval decisions and logs, so an agent that only needs a frontend integration receives the appropriate lower-privilege credential. Disable its profile for containment, but rotate the Supabase key if it may have been copied and use Supabase/database logs to investigate actual data or schema operations.

## How it works

1. Identify the project and credential type required for each workflow. Confirm RLS is enabled and tested for client-facing access; reserve service-role credentials for trusted server-side administration.
2. Store development, staging, and production keys as separate secrets and map each to the exact build, migration, or runtime profile.
3. Agents request the approved secret through MCP, and Gazebo authorizes the profile before release.
4. Review Gazebo retrievals with Supabase logs, database audit/query tooling where configured, migration history, and application errors. An allowed retrieval does not show which SQL or storage operation followed.
5. Remove a profile when work finishes. Rotate a project key after suspected disclosure, review RLS changes and migrations, and update only the still-authorized runtime profiles.

## Use cases

**Anon key vs service role separation:** Give frontend integration work the project’s client-facing key and test the intended RLS policies with representative users. Put any service-role key in a separate, tightly limited profile for a trusted migration or administrative workflow. Gazebo controls who can fetch it; RLS, key type, and server-side design control what it can do once fetched.

**Per-project isolation:** Use distinct project credentials as well as distinct Gazebo profiles. A profile name alone is not isolation if the underlying secret belongs to multiple environments. This separation makes a mistaken target URL or agent retry easier to contain and makes key rotation for one project less disruptive to the others.