Diagnose Supabase with an AI Agent

Use an AI agent to find and fix a deliberate Supabase fault from logs.

Introduction

30 Second Summary

A broken database can leave you staring at failed requests with no clear cause. The repair is often quick once the right log entry reveals the problem.

In this project, you will watch an AI coding agent diagnose a deliberate fault in a small Supabase database. The agent gets read-only access while you apply the proposed migration yourself.

What You'll Build

You'll watch a read-only coding agent query the errors you triggered in Supabase until it pinpoints their cause.

By the end of this project, you'll have:

  • A seeded table whose rows you can inspect before you trigger a burst of failing requests.
  • A read-only agent connection through MCP that keeps migration approval in your hands.
  • A verified repair where the Advisor returns clean after you apply the migration.
  • Secret Mission: An optional challenge that extends your agent-led diagnosis workflow.

Are there any prerequisites?

You'll need a Supabase account plus a coding agent that supports MCP. You'll also need Node or Python to generate test traffic.

Before We Start

A reliable database diagnosis starts with access to the right workspace. Missing tools can interrupt the investigation before the first log query.

In this step, you will prepare the Supabase Dashboard for the project.

Your MCP-capable coding agent will be open for later log analysis.

Your terminal will be ready for the test traffic you send later.

In this step, get ready to:
  • Sign in to the Supabase Dashboard with access to create projects.
  • Launch an MCP-capable coding agent.
  • Open a terminal for later project commands.
Sign in to the Supabase Dashboard

The Supabase Dashboard is where you will create the database project in the next step. Signing in now confirms that your account can reach the project creation flow.

Your account status determines the sign-in path.

GitHub account

Use this path when your Supabase account is connected to GitHub.

Email account

This is a normal account sign-in. Keep your password out of screenshots or project files.

  • Visit the official Supabase Dashboard.
  • Enter the email address attached to your account in the Email field.
  • Enter your account password in the Password field.
  • Click Sign in.

New account

Keep your new password private. This project never asks you to paste it into code.

  • Visit the official Supabase Dashboard.
  • Click Sign up.
  • Complete the account form with credentials you control.
  • Follow the confirmation steps shown in your browser.
  • Locate the project creation option in the Supabase Dashboard.

Seeing the project creation option confirms that your account has the access required for the next step.

You have cleared the first gate. Your Supabase account is ready to host the database you will diagnose.

Launch your coding agent

A coding agent that supports MCP can receive tools from external services. You will connect it to Supabase later with read-only access.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type your coding agent application name into the search bar.
  • Press Enter to launch the selected application.

You should see the coding agent's home screen or workspace.

Can't launch your coding agent?

  • Check that the application name matches the installed coding agent.
  • Install your chosen MCP-capable coding agent from its official website if no installed application appears.
  • Ask for help with getting an MCP-capable coding agent ready.
Open your terminal

The terminal gives you a place to run the fault script later. A visible command prompt confirms that it is ready for input.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Search for the terminal application included with your operating system.
  • Open the result that provides a command prompt.

You should see a terminal window with a command prompt ready for input.

Before the final check, which three ready screens do you expect to switch between?

  • Return to the browser tab containing the Supabase Dashboard.
  • Switch to your coding agent application name.
  • Return to the terminal window.

The browser should show the Supabase Dashboard with a project creation option. The coding agent should show its home screen or workspace.

The terminal should show a command prompt ready for input.

Your investigation workspace is ready. Next up, you will create the Supabase project and seed its first database table.

Create and Seed Your Database

Your agent needs a known database state before it can diagnose anything. A seeded table gives it real evidence to inspect later.

In this step, you will create a Supabase project with a seeded public.diagnostic_notes table. You will enable Row Level Security while leaving the anonymous role without a read policy.

In this step, get ready to:
  • Create the ai-agent-db-diagnosis project in your selected Supabase region.
  • Build the public.diagnostic_notes table with the required columns.
  • Seed the table with sample rows and verify its security state.
Create your Supabase project

Every Supabase project includes its own Postgres database. The region determines where that database runs.

The project form also asks for a database password. This credential protects direct database access.

  • Go to Supabase's new project page.
  • Select the organization that should own your project.
  • Enter ai-agent-db-diagnosis as the project name.
  • Create a strong database password.
  • Store the database password in your password manager.
  • Select the Supabase region closest to you.
  • Submit the form to create the project.
  • Wait for project provisioning to finish.

You'll land in the project dashboard with ai-agent-db-diagnosis shown as the project name.

That's the foundation in place. Your diagnosis project now has its own database.

Project Not Provisioning?

  • Check that your account can create projects in the selected organization.
  • Choose another available region if the selected region cannot accept the project.
  • Confirm that the database password meets the requirements shown in the form.

Help me troubleshoot my Supabase project creation issue. For peer support, ask the Supabase community.

Build and seed the diagnostic table

The Table Editor creates the id column automatically. It also creates created_at with the current time as its default.

Keeping these defaults gives each note a unique number. The timestamp records when each row was created.

  • Select Table Editor in the project sidebar.
  • Click New table.
  • Enter diagnostic_notes in the Name field.
  • Confirm that the table uses the public schema.
  • Keep the editor-created id column as the primary key.
  • Keep the editor-created created_at column.

What Do These Defaults Create?

  • The id column uses bigint as its type. Its identity setting generates a value for each row.
  • The created_at column uses timestamptz as its type. Its now() default records the insertion time.
  • Click Add column under Columns.
  • Enter title as the column name.
  • Select text as the column type.
  • Set the title column to reject null values.
  • Confirm that Row Level Security is enabled.
  • Click Save.

You'll see diagnostic_notes in the Table Editor with id, title, and created_at columns.

You have the database shape locked in. Each diagnostic note now gets an identifier and creation time.

Seed rows give the agent evidence to inspect later. Three distinct titles also make the table easy to recognize in screenshots and query results.

  • Click Insert row in diagnostic_notes.

You'll see the row editor with fields for the table's columns.

  • Enter API health check started in the title field.
  • Click Save.

You'll see the first row with a generated id and a populated created_at value.

  • Click Insert row again.
  • Enter RLS policy check pending in the title field.
  • Click Save.

You'll see two diagnostic notes in the table.

  • Click Insert row once more.
  • Enter Advisor baseline recorded in the title field.
  • Click Save.

You'll now see three rows with generated identifiers and timestamps.

Table State Does Not Match?

  • Edit the table if one of the required columns is missing.
  • Check that title uses the text type.
  • Remove any policy that was added to diagnostic_notes.

Help me correct my Supabase diagnostic_notes table. For environment-specific help, ask the Supabase community.

Verify the security state

Row Level Security checks each Data API request against the table's policies. The project owner can still see the rows through the Table Editor.

The anon role should have no SELECT policy. This creates the controlled access gap that the project investigates later.

Before you check, do you think an anonymous request can read these rows without a SELECT policy?

  • Count the rows visible in diagnostic_notes.
  • Select Database in the project sidebar.
  • Select Policies.
  • Locate diagnostic_notes in the public schema.
  • Review the Row Level Security status.
  • Review the policy list for the anon role.
  • Return to Table Editor to confirm that the three seeded rows remain visible.

You'll see three seeded rows in diagnostic_notes. The Policies page shows Row Level Security enabled with no policy entries for the anon role.

That controlled starting point is ready. Your agent will have a real database state to investigate.

Your Supabase project now contains a seeded table with the intended security gap. Next, you'll create a project-scoped read-only token for your coding agent.

Create a Read-Only Access Token

Your Supabase project now contains seeded diagnostic notes. Its Row Level Security setup contains the intentional gap that the agent will investigate.

The coding agent needs a safe credential before it can inspect the project. A scoped personal access token limits that credential to one project.

In this step, you will grant read access for the investigation. You will store the one-time token value outside the project files.

In this step, get ready to:
  • Start a new scoped personal access token.
  • Limit the token to the project capabilities needed for investigation.
  • Store the token value securely.
Start a scoped token

A personal access token authenticates tools built on the Supabase Management API. The MCP server can later use it to access only the capabilities you choose.

You will see a Resources section beside Permissions. An Expiry choice completes the setup.

Why scope the token?

A project scope prevents the token from reaching your other Supabase projects. A leak can expose only the resources you selected.

Read access lets the agent investigate the project. Write operations remain unavailable.

Restrict the token to read access

The investigation needs four read capabilities. Each capability unlocks a specific source of diagnostic evidence.

  • Name the token ai-agent-db-diagnosis-readonly.
  • Under Resources, select only ai-agent-db-diagnosis.
  • Keep the preselected option under Expiry.
  • Under Permissions, set Project Settings to Read.
  • Set Database to Read.
  • Set Logs to Read.
  • Set Advisors to Read.
  • Leave every Read-write option disabled.

What Do These Permissions Unlock?

  • Project Settings lets the agent read project details plus service health.
  • Database allows read-only SQL queries.
  • Logs gives the agent access to project logs.
  • Advisors allows on-demand checks. It also returns their results.
  • Continue to the review of the token's access.

The review should show only ai-agent-db-diagnosis as a resource. Every selected capability should show Read.

Protect the token value

Protect the Live Credential

The full token value appears only once. A password manager keeps it away from project files.

A screenshot of the creation screen could expose the credential. Wait until the one-time value is closed before capturing any evidence.

  • Confirm the review to create the token.
  • Copy the full token value with the copy control.
  • Store the copied value in your password manager.
  • Confirm that the stored value begins with sbp_fc.
  • Close the one-time token display.

Before you check the saved token, do you expect the dashboard to show one project or account-wide access?

  • Return to the access tokens list.
  • Select ai-agent-db-diagnosis-readonly to view its details.

You should see ai-agent-db-diagnosis as the only project scope. The four selected capabilities should show Read access.

The full secret should no longer appear. That is the sensitive part complete. Your agent now has a credential for investigating one project without write access.

Scope Looks Too Broad?

A broader scope means the token needs replacing. Nothing uses this token yet, so deleting it is safe.

  • Delete the incorrectly scoped token from the access tokens page.
  • Recreate the token by repeating this substep with the correct project scope.
  • Replace the stored credential with the new token value.

Help me verify the scope of my Supabase personal access token. You can also share a redacted screenshot in the Supabase community.

Your read-only credential is scoped to the diagnosis project. Next, you will connect the coding agent through MCP and confirm which Supabase tools it can use.

Connect Your Agent Through MCP

Your scoped personal access token now protects the Supabase project from broad access. However, your coding agent still has no route to the project tools or logs.

The Model Context Protocol (MCP) creates that route. In this step, you connect the agent with project-scoped read-only access.

In this step, get ready to:
  • Record the project reference for your Supabase project.
  • Configure the Supabase MCP server with protected credentials.
  • Confirm that the agent displays the database tools plus the log-querying tools.
Record your project reference

The MCP connection uses a project reference to identify one specific Supabase project. Recording that value keeps the agent scoped to ai-agent-db-diagnosis.

  • Switch back to the Supabase Dashboard from earlier.
  • Click Project Settings in the project navigation.
  • Select General.
  • Find the Reference ID for ai-agent-db-diagnosis.
  • Store the value here: your Supabase project reference.

The next action handles a credential. Your token stays out of chat because the agent reads it from protected environment storage.

  • Return to the coding agent application from earlier.
  • Use its settings search to locate the secure environment variable controls.
  • Create SUPABASE_PROJECT_REF with the value your Supabase project reference.
  • Create SUPABASE_ACCESS_TOKEN with the token value you copied earlier.
  • Save the protected environment settings.

You should see both environment variable names saved. The token value should appear masked.

Cannot Find Protected Environment Settings?

  • Check your coding agent's documentation for its environment variable or secret storage feature.
  • Keep the token outside project files to prevent accidental commits.
  • Ask for help with your agent's secure credential storage.
Configure the Supabase MCP server

The project_ref parameter limits the server to your project. The read_only=true parameter runs database queries through a read-only role.

  • Return to your coding agent's MCP server configuration.
  • Add a server named supabase by pasting this JSON configuration:
{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=${SUPABASE_PROJECT_REF}&read_only=true",
      "headers": {
        "Authorization": "Bearer ${SUPABASE_ACCESS_TOKEN}"
      }
    }
  }
}

What Does This Configuration Do?

  • The http type connects the agent to the hosted server through HTTP.
  • The server URL reads SUPABASE_PROJECT_REF from protected environment storage.
  • The Authorization header sends the scoped token as a Bearer credential.
  • The token value stays outside the configuration snippet.
  • Save the MCP server configuration.
  • Reload the server configuration using your agent's MCP controls.

You should see the supabase server reach a connected or ready state.

Server Fails to Connect?

  • Confirm that the coding agent can read both protected environment variables.
  • Restart the coding agent after saving new environment variables.
  • Re-enter the token in protected storage if authentication still fails.
  • Help me troubleshoot the Supabase MCP connection.

✔️ Awesome, I've got everything!

The Supabase MCP connection is saved. Your scoped token remains protected outside the visible configuration.

ⓧ I'd like to double check the full code

Compare your complete MCP server configuration with this version. The environment variable references should remain unchanged.

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=${SUPABASE_PROJECT_REF}&read_only=true",
      "headers": {
        "Authorization": "Bearer ${SUPABASE_ACCESS_TOKEN}"
      }
    }
  }
}
Confirm the read-only tools

A successful connection proves that the agent can reach the MCP server. The available tool list proves that the token authorizes the diagnostic capabilities you need.

Before you ask, which read-only database tools do you expect to see? Which logging tool should appear?

  • Ask your agent to list its Supabase MCP tools without running one by sending this prompt:
List the Supabase MCP tools available to you. Do not call any tool.

Why This Check Works

This prompt asks the agent to inspect its registered MCP tools. No database query runs during this check.

You should see database tools such as list_tables plus execute_sql. The debugging group should include query_logs plus get_advisors.

That bridge is live. Your agent can now inspect the project through MCP while the scoped token keeps its access read-only.

Tools Missing From the List?

  • Reload the MCP server configuration from your agent's connection controls.
  • Confirm that SUPABASE_PROJECT_REF contains the Reference ID for ai-agent-db-diagnosis.
  • Return to the token scope page to confirm that its read permissions cover the expected tools.
  • Help me find the missing Supabase MCP tools.

Your agent now has a protected read-only window into the project. Next up, you will generate the failing requests that give those diagnostic tools something real to investigate.

Generate Failing API Requests

Your coding agent now has read-only access to Supabase logs. It needs clear evidence of a database problem before it can investigate.

The public.diagnostic_notes table has Row Level Security enabled with no anon SELECT policy. This access gap gives you a controlled fault that leaves a repeatable trail in the project's REST logs.

In this step, get ready to:
  • Gather the existing project URL plus anon key.
  • Send a burst of anonymous SELECT requests to the diagnostic table.
  • Confirm the failed requests in the project logs.
Gather the project request details

Each request needs the project's public API address. It also needs the existing anon key so Supabase evaluates the request as the signed-out anon role.

  • Switch back to the Supabase Dashboard from earlier.
  • Click Connect in the project header.
  • Record the project URL here: https://your-project-ref.supabase.co.
  • Close the Connect dialog.
  • Select Settings in the project sidebar.
  • Select API Keys.
  • Copy the existing anon key.

The project URL is now recorded above. Your clipboard holds the anon key for the interactive script.

Test the anonymous access gap

Entering an API key can feel risky. This script keeps the anon key out of shell history. The value exists only while the function runs.

Before you start the burst, do you think the anon role can return one seeded note? Hold that prediction while the script runs.

  • Return to the terminal from earlier.
  • Start the interactive request script by pasting the code below:
generate_fault() {
  # Keep the request details inside this temporary function
  local SUPABASE_URL
  local SUPABASE_ANON_KEY
  local request_number

  printf "Project URL: "
  read -r SUPABASE_URL
  printf "Anon key: "
  read -rs SUPABASE_ANON_KEY
  printf "\n"

  # Request one visible row repeatedly so the access gap produces errors
  for request_number in {1..50}; do
    curl --fail --silent --write-out "Request ${request_number}: %{http_code}\n" \
      "${SUPABASE_URL%/}/rest/v1/diagnostic_notes?select=*&limit=1" \
      --header "apikey: ${SUPABASE_ANON_KEY}" \
      --header "Accept: application/vnd.pgrst.object+json"
  done
}

generate_fault

What does this script do?

  • The local variables keep the project URL plus anon key inside generate_fault.
  • The read -rs command accepts the anon key without displaying it.
  • The loop sends 50 GET requests to /rest/v1/diagnostic_notes.
  • The select=* query requests every column.
  • The limit=1 query caps each result at one row.
  • The Accept: application/vnd.pgrst.object+json header requires one object in the response.
  • Enter https://your-project-ref.supabase.co when the terminal shows Project URL.
  • Press Enter.
  • Paste the copied anon key when the terminal shows Anon key.
  • Press Enter to send the request burst.

You should see 50 response lines from Request 1: 406 through Request 50: 406.

That is the intended fault. RLS hid every row from anon, which converted the singular request into PGRST116 with HTTP 406.

Not seeing 406 responses?

  • Confirm the project URL matches the value shown in the project's Connect dialog.
  • Confirm the copied key is the project's anon key.
  • Avoid using the scoped personal access token from the MCP connection.
  • Return to Table Editor.
  • Confirm RLS remains enabled for public.diagnostic_notes.
  • Confirm no SELECT policy exists for the anon role.
  • Help me diagnose why my Supabase request burst is not returning HTTP 406..

✔️ Awesome, I've got everything!

Great. Your terminal has completed the anonymous request burst without storing the anon key in a file or shell history.

ⓧ I'd like to double check the full code

Compare your terminal script with this complete version. The function should prompt for both values before sending 50 requests.

generate_fault() {
  # Keep the request details inside this temporary function
  local SUPABASE_URL
  local SUPABASE_ANON_KEY
  local request_number

  printf "Project URL: "
  read -r SUPABASE_URL
  printf "Anon key: "
  read -rs SUPABASE_ANON_KEY
  printf "\n"

  # Request one visible row repeatedly so the access gap produces errors
  for request_number in {1..50}; do
    curl --fail --silent --write-out "Request ${request_number}: %{http_code}\n" \
      "${SUPABASE_URL%/}/rest/v1/diagnostic_notes?select=*&limit=1" \
      --header "apikey: ${SUPABASE_ANON_KEY}" \
      --header "Accept: application/vnd.pgrst.object+json"
  done
}

generate_fault
Confirm the errors in Logs

Supabase records REST request metadata in API Gateway logs. Filtering by the table path isolates your request burst from unrelated project activity.

Before you filter the logs, do you expect one isolated error or a cluster of matching errors? Keep your prediction in mind while you inspect the results.

  • Return to the Supabase Dashboard from earlier.
  • Click Logs in the project sidebar.
  • Set Time Range to include the moment you ran the script.
  • Select API Gateway under Log Type.
  • Click Add filter.
  • Select Pathname.
  • Enter /rest/v1/diagnostic_notes as the path.
  • Select one of the newest matching rows.

You should see repeated GET entries for /rest/v1/diagnostic_notes with status 406. The detail panel should show the matching request path plus response status.

That fault is now doing its job: the dashboard has a repeatable cluster for the agent to investigate.

No matching errors in Logs?

  • Expand Time Range to cover an earlier start time.
  • Confirm API Gateway remains selected under Log Type.
  • Check that the Pathname filter contains /rest/v1/diagnostic_notes.
  • Run generate_fault again if the selected time range contains no matching activity.
  • Help me find my failed diagnostic_notes requests in Supabase Logs..

The error trail is ready for investigation. Next, you'll run the Advisor checks and give your agent the Health starter prompt.

Diagnose the Errors with Your Agent

Your failed requests now appear in the Supabase project logs. That evidence proves the fault is reproducible.

The challenge is turning a burst of errors into a defensible diagnosis. Supabase Advisors gives you a health signal before the deeper investigation begins.

Your coding agent uses the Model Context Protocol (MCP) to query those logs with SQL. It inspects the table access rules before drafting an unapplied migration.

In this step, get ready to:
  • Run the Health Advisor checks for ai-agent-db-diagnosis.
  • Give your coding agent the official Health starter prompt.
  • Receive an evidence-backed diagnosis with an unapplied migration proposal.
Run the Health Advisor checks

Advisor checks apply consistent rules to recent project activity. The Health view looks for elevated error rates across Supabase services.

  • Switch back to the Supabase Dashboard from earlier.
  • Confirm that ai-agent-db-diagnosis is selected in the project header.
  • Select Advisors in the left sidebar.
  • Select Health on the Advisors page.

Before you run the checks, do you expect the request burst to appear as a Health finding?

  • Start an on-demand check from the Health page.
  • Wait for the Health page to show the latest completed results.

You will see completed checks for the monitored services. An empty result means the recent activity did not cross the current Health threshold.

Why Use Advisors and Logs?

Advisor results identify which service deserves attention. Log queries expose the individual requests behind that signal.

Together they move the investigation from a symptom to supporting evidence.

No Health Finding?

An empty result means every Health check ran without finding a persistently high error rate. The failed request entries can still support the focused investigation.

Ask for help if the page never finishes the checks: help me troubleshoot a Supabase Health Advisor check that does not complete.

Give the agent the Health starter prompt

The official Health starter prompt gives your agent a read-only investigation procedure. It also tells the agent to separate observed evidence from possible causes.

  • Open the official Health prompt guide in your browser to copy the starter prompt.
  • Find the Step 1: Copy the prompt heading.
  • Copy the entire text block beneath that heading.

You now have Supabase's read-only Health workflow on your clipboard.

  • Switch back to the coding agent from earlier.
  • Paste the Health prompt into the agent chat.

The chat composer now contains the complete Health workflow. Your existing MCP connection already limits the agent to the correct project.

  • Add a final sentence requesting an on-demand run for ai-agent-db-diagnosis.

Your client may ask you to approve each MCP call. These approval prompts keep every read-only operation visible to you.

Before you send the prompt, do you expect the agent to rely on Advisor results alone or gather its own evidence?

  • Send the completed prompt to the agent.
  • Approve each read-only query_logs call requested by the agent.
  • Approve each read-only execute_sql call requested by the agent.

You will see the agent invoke Supabase tools before writing its response. The first run establishes the official evidence-gathering method for the focused diagnosis.

Agent Not Using MCP?

  • Confirm that the existing Supabase MCP connection still lists its read-only tools.
  • Start a fresh agent chat if the current conversation no longer exposes those tools.
  • Ask for targeted help: help me restore the existing read-only Supabase MCP tools in my coding agent.
Turn the evidence into a diagnosis

The starter prompt establishes the investigation rules. A focused follow-up now directs those rules toward the injected REST failures.

Before you ask, which evidence do you expect the agent to inspect first?

  • Ask the agent to use query_logs to investigate the recent anonymous SELECT failures against public.diagnostic_notes.

You will see the agent issue a SQL-backed log query through MCP. Its results should include the failed requests to /rest/v1/diagnostic_notes.

Log Query Returned No Rows?

  • Ask the agent to confirm that its query uses the API Gateway log source.
  • Ask the agent to widen its bounded time window around the fault-script run.
  • Request help with the query: help me find the injected diagnostic_notes requests with Supabase query_logs.

Access controls are enforced through Row Level Security (RLS). A read-only schema inspection can reveal whether anonymous SELECT access exists.

  • Ask the agent to use execute_sql to inspect the access controls on public.diagnostic_notes.

You will see that RLS is enabled on the table. You will also see that no SELECT policy exists for the anon role.

  • Ask the agent to write a diagnosis that connects the REST failures to the missing anonymous SELECT policy.

The diagnosis should identify the missing policy as the cause of the failed anonymous requests. It should support that conclusion with both log evidence and schema evidence.

The proposed SQL changes access behavior. Keeping it unapplied gives you final control over the fix.

  • Ask the agent to propose an unapplied migration named anon_can_read_diagnostic_notes for SELECT access by anon on public.diagnostic_notes with the condition using (true).

The proposed migration creates the policy anon_can_read_diagnostic_notes on public.diagnostic_notes. It grants SELECT to anon with using (true).

The proposal remains text in the agent response. No database change has been made.

That's the investigation complete. Your agent has turned raw request logs into a policy-level diagnosis without changing the project.

You now have an evidence-backed diagnosis plus an unapplied migration proposal. Next up, you will review that migration yourself before applying the fix.

Apply the Database Fix

Your read-only coding agent used Supabase logs to trace the failed requests to a missing SELECT policy on public.diagnostic_notes. Row Level Security protects the table while that policy is absent.

The agent has proposed a migration that grants narrowly scoped read access. You remain responsible for reviewing that change before Supabase Advisor confirms the result.

In this step, get ready to:
  • Review the agent's proposed migration.
  • Apply the policy through the Supabase Dashboard.
  • Rerun the Advisor checks to confirm the clean result.
Review the proposed migration

The coding agent's read-only MCP connection lets it investigate the project without changing the database. Its proposed SQL becomes safe to apply only after you confirm that the policy matches the diagnosis.

  • Return to the coding agent conversation from the previous step.
  • Compare the proposed policy with the existing diagnosis report.
  • Confirm the migration matches this statement:
CREATE POLICY "anon_can_read_diagnostic_notes" ON public.diagnostic_notes FOR SELECT TO anon USING (true);

What Does This Policy Change?

  • The CREATE POLICY clause creates a named access rule for the table.
  • The FOR SELECT TO anon clause limits the rule to anonymous read requests.
  • The USING (true) condition allows the anonymous role to read every row in this diagnostic table.
  • The policy grants no anonymous insert or update access.

Your coding agent may request permission to create a workspace file. That permission covers the migration file without granting database write access.

  • Ask the coding agent to save this exact statement as a migration file in the current project workspace.
  • Approve the workspace-only file change if the coding agent requests permission.
  • Confirm the saved migration file contains the exact policy statement shown above.
  • Leave the existing agent diagnosis report in place beside your project artifacts.

Does the Migration Look Different?

  • Check that the policy targets public.diagnostic_notes.
  • Check that the policy grants only SELECT access to anon.
  • Compare every identifier with the diagnosis before applying the file.
  • Help me review this Supabase policy migration before I apply it.

✔️ Awesome, I've got everything!

Your migration file now contains the reviewed policy. Your diagnosis report remains available as evidence for why the change is needed.

ⓧ I'd like to double check the full code

Your retained migration file should contain exactly this SQL statement.

CREATE POLICY "anon_can_read_diagnostic_notes" ON public.diagnostic_notes FOR SELECT TO anon USING (true);
Apply the policy yourself

Changing a database access policy deserves a deliberate review because it changes who can read table data. This migration grants one read permission while leaving anonymous writes protected.

  • Switch back to the Supabase Dashboard project from earlier.
  • Select SQL Editor from the project navigation.
  • Use the SQL Editor's new-query control to start a blank query.
  • Paste the reviewed migration into the editor by using this exact statement:
CREATE POLICY "anon_can_read_diagnostic_notes" ON public.diagnostic_notes FOR SELECT TO anon USING (true);

Why Apply the Migration Here?

The SQL Editor executes the reviewed policy against your selected project. You control the write operation while the coding agent keeps read-only access.

  • Execute the query with the SQL Editor's run control.

You should see confirmation that the query completed successfully.

  • Select Table Editor from the project navigation.
  • Select public.diagnostic_notes from the table list.
  • Open the table's policy view.
  • Confirm that anon_can_read_diagnostic_notes permits anonymous SELECT access.

You should see the new policy while Row Level Security remains enabled.

Policy Missing After the Query?

  • Confirm that the SQL Editor is connected to ai-agent-db-diagnosis.
  • Check the query result for a syntax issue before running the exact migration again.
  • If the policy already exists, inspect its role and operation instead of creating a duplicate.
  • Help me troubleshoot why my Supabase policy was not created.

That is the critical database change complete. Anonymous clients can now read the diagnostic notes without gaining write access.

Rerun the Advisor checks

The earlier failed requests remain useful historical evidence in your project logs. A fresh Advisor run checks whether the missing-policy problem is still active after your migration.

  • Return to the project logs from earlier.
  • Confirm that the pre-fix anonymous request failures remain visible as historical entries.
  • Return to the Advisor results you used before the migration.

Before you rerun the checks, do you expect the missing-policy finding to remain active or appear only in the historical logs?

  • Rerun the same Advisor checks against ai-agent-db-diagnosis.

The latest Advisor run should return clean. The missing anonymous read-policy finding should no longer appear as an active issue.

Still Seeing the Earlier Finding?

  • Confirm that the policy remains visible on public.diagnostic_notes.
  • Run the check against a comparable post-fix observation window after its measured period updates.
  • Help me understand why the Supabase Advisor still shows the pre-fix finding.

You closed the diagnosis loop with evidence from both sides. The agent found the cause while you kept control of the database change.

Secret mission

Audit the Agent's Diagnosis

Put the diagnosis through a skeptical evidence review. Use the existing read-only connection to separate direct observations from inference. Test the root cause against a competing explanation without changing the project.

Clean Up Your Resources

Clean Up Your Resources

Your main path used a free Supabase project. Your current account plan still governs any future usage.

Choose whether to keep the project active, pause it for later, or delete it entirely. Every option removes the scoped personal access token because the diagnosis is complete.

Resources you used:

  • The scoped read-only token ai-agent-db-diagnosis-readonly.
  • The Supabase project ai-agent-db-diagnosis.
  • The public.diagnostic_notes table with Row Level Security enabled.
  • The anon_can_read_diagnostic_notes policy with the historical request logs.

Keep everything running

No action is needed for the Supabase project. Choose this if you want the fixed database available for more experiments.

Revoking the token only ends the coding agent's access. The project stays active.

  • In Supabase Dashboard, open your account settings area for personal access tokens.
  • Find ai-agent-db-diagnosis-readonly in the token list.
  • Delete ai-agent-db-diagnosis-readonly.
  • Confirm the deletion when Supabase asks.
  • Return to the coding agent from earlier.
  • Ask the coding agent to run a read-only project check through the existing MCP connection.

You should see an authentication failure without any live token value on screen. This confirms the agent no longer has project access.

The retained migration file and agent diagnosis report remain your reusable record.

Pause - I'll come back to this later

Pause the Supabase project when you want to preserve the fixed database for later. The project stops running until you resume it.

Removing the token only disconnects the coding agent. Your project data remains part of the paused project.

  • In Supabase Dashboard, open your account settings area for personal access tokens.
  • Find ai-agent-db-diagnosis-readonly in the token list.
  • Delete ai-agent-db-diagnosis-readonly.
  • Confirm the deletion when Supabase asks.

The coding agent no longer has permission to query the project.

  • Return to ai-agent-db-diagnosis in Supabase Dashboard.
  • Open the project's settings area for lifecycle options.
  • Choose the option to pause the project.
  • Complete the confirmation prompt.
  • Check the project status to confirm it is paused.

You should see that ai-agent-db-diagnosis is paused. Keep the retained migration file and agent diagnosis report for your next session.

Delete - I don't want to use this again

This option removes the hosted project when you no longer need the database. You can start fresh in Supabase later.

Deleting the project removes the seeded table, the access policy, and the historical logs. Your retained migration file and agent diagnosis report remain as evidence of the investigation.

  • In Supabase Dashboard, open your account settings area for personal access tokens.
  • Find ai-agent-db-diagnosis-readonly in the token list.
  • Delete ai-agent-db-diagnosis-readonly.
  • Confirm the deletion when Supabase asks.

The token is now revoked. The coding agent can no longer authenticate to the project.

  • Confirm the retained migration file is saved.
  • Confirm the agent diagnosis report is saved.
  • Return to ai-agent-db-diagnosis in Supabase Dashboard.
  • Open the project's settings area for lifecycle options.
  • Choose the project deletion option.
  • Complete the confirmation prompt.
  • Return to the Supabase Dashboard project list.

You should no longer see ai-agent-db-diagnosis in the project list. Its table, policy, and historical logs have been removed with it.

Nice Work!

Nice Work!

That investigation paid off. You built an end-to-end database diagnosis workflow where an AI agent used read-only Supabase access to trace failed requests to a missing Row Level Security policy.

You've learned how to:

  • Fault reproduction: Seeded public.diagnostic_notes with diagnostic rows. Generated a burst of failed anonymous requests that stayed visible in the project logs.
  • Read-only agent investigation: Connected a coding agent through MCP with a project-scoped token. Used SQL log queries plus Advisor results to produce a report naming the missing anonymous SELECT access.
  • Human-controlled remediation: Reviewed the agent-written migration before applying it yourself. Confirmed anon_can_read_diagnostic_notes closed the policy gap when Advisor checks returned clean.
  • Secret Mission: Extended the read-only diagnosis workflow through the optional project challenge.

Ready to quiz yourself?