Sanbox By Sanlabs

Guides

Building agent products

Guide

How do I give Supabase users a persistent agent computer that respects RLS?

By the Sanbox team updated

Ask ChatGPT Ask Claude

Let the agent act as the signed-in user, not as an admin with a service-role key. With Sanbox's Supabase integration, you connect your Supabase Cloud project once, create an always-on Hermes Computer for a user with their Supabase Auth ID, and send them a consent link. After they approve, the Computer makes read-only requests to the Supabase Data API as that user, so your Postgres permissions and Row Level Security (RLS) policies decide what it can see.

Run this with your agent

Read https://sanbox.cloud/kb/build/supabase-users-get-a-computer.md and follow it to give one Supabase user an agent Computer.
If the Sanbox CLI is missing, install it with `npm install -g @sanlabs/sanbox-cli@latest`
and sign in with `sanbox login`. Show me each command before you create, stop or delete a Computer.

How does it work?

  • The user approves access through OAuth 2.1, with your existing Supabase Auth sign-in. They don't need a Sanbox account.
  • Every request runs as that user. Supabase applies the project's normal Postgres permissions and RLS policies. Supabase's docs say existing RLS policies apply automatically to OAuth tokens.
  • The real tokens stay outside the Computer. The agent gets a temporary local credential instead of the user's Supabase access or refresh token. Sanbox validates each request and adds the current user token outside the microVM.
  • The agent knows your schema. Sanbox imports a sanitised map of the project's public Data API tables and columns, and preloads it with a Supabase query helper into the Computer's workspace. It copies no table rows, and the map grants no access.
  • The Computer is persistent. Files, memory and learned skills stay on its disk between tasks, so the agent picks up where it left off.

Steps

1. Turn on Supabase's OAuth 2.1 server

In the Supabase dashboard, go to Authentication, then OAuth Server, and enable it. Supabase marks the OAuth 2.1 server as beta, available on all plans. Set an authorization path, such as /oauth/consent, which Supabase appends to your Site URL, and serve a consent page there that shows the request and approves or denies it. Then register Sanbox as an OAuth client so your users can approve access later.

2. Connect the project in the Sanbox console

In the Sanbox console, sign in to Supabase and choose the Supabase Cloud project your Computers should use. The connection lives at the organisation level, so no Supabase secrets go into templates.

3. Create a Hermes template

An organisation admin creates it once, with the model and the network access the agent needs for its other work:

sanbox templates create --name "Support agent" --type hermes-computer \
  --model-provider <provider-id> --model <model-id> \
  --network-policy policy.json --json
sanbox templates validate <template-id> --json

4. Create a Computer for one user

Pass the user's Supabase Auth UUID and a stable external ID, so a retry returns the same Computer:

sanbox run "Act as this user's support assistant" \
  --template <template-id> \
  --external-run-id "hermes:<tenant-id>:<user-id>" \
  --supabase-user-id "<supabase-auth-user-uuid>" \
  --json

The run waits in awaiting_grant until that same user approves.

sanbox runs supabase authorize <run-id> --json

Return the URL to the user. They sign in with your Supabase Auth flow and approve. Without a return URL, the flow ends on a Sanbox-hosted completion page, which is enough for a demo. In your product, add --return-url <https-url> when its origin matches the return origin set on your organisation's Supabase connection. --open opens the link in the local browser, for testing.

6. Check that it's running

sanbox runs get <run-id> --json

Once the run is running, the user's Computer is ready. A Hermes Computer receives work through its hosted web UI and the channels its template allows, email and Telegram. Don't use --wait on these runs: a Hermes Computer stays running until you stop it.

What can it do?

The published examples all use reads scoped to one person:

  • Support: read a customer's orders, subscriptions and support_tickets, build a timeline and draft a reply for a support agent to review.
  • Case work: read the cases assigned to an investigator and build a dated evidence map in the Computer's workspace, to return to later.
  • Account briefs: read the accounts an account owner may see and prepare a call brief before a renewal.
  • Operational research: combine permitted purchase and delivery records with documents to compare suppliers.

Lock down egress

The template's network policy is deny-by-default. List only the other hosts the agent needs, such as a CRM's API:

{
  "default_action": "deny",
  "rules": [{ "destination": "api.example.com", "ports": [{ "from": 443, "to": 443 }] }]
}

Use a Secret Proxy for that API's key, so the agent never sees it.

What this doesn't do

  • Read-only. The Computer reads through the Supabase Data API. It doesn't write to your database.
  • Supabase Cloud and Hermes Computers. The integration works with Supabase Cloud projects, for Hermes Computers.
  • RLS is the limit you set. If a user's permissions allow broad access, the agent has that access too.
  • No forks or snapshots of bound runs. Runs with a delegated Supabase binding can't be forked in this version, and snapshots follow the same rule, so each user's Computer starts on its own.
  • Your operators act with the end user's grant. Members of your Sanbox organisation with operator roles can work on its Computers, including ones connected to an end user's Supabase data, so give those roles only to people who run your service.

Sources