Supabase Vault

Replace OpenClaw's local file vault with Supabase Vault for AES-256 encrypted-at-rest secret storage. All API keys and auth tokens stored encrypted in Postgr...

Security Scan

The skill’s code and instructions broadly match a Supabase-backed secrets backend, but the registry metadata omits the high-privilege bootstrap credential the skill requires and there are a few risky/privileged actions (config mutation, service_role usage, a prompt-injection signal) that warrant manual review before installing.

Purpose & Capability

The skill's name/description (Supabase-backed vault) matches the included code and runtime instructions: it stores secrets in Supabase, provides dashboard UI, migration, and an exec bridge. However the registry metadata declares no required credentials or primary credential, while the SKILL.md and code clearly require the Supabase Project URL + service_role key — a high-privilege secret. That metadata omission is incoherent and reduces transparency for users.

Instruction Scope

SKILL.md and the scripts instruct the agent/admin to: run setup SQL in Supabase, copy TypeScript UI & RPC files into the OpenClaw codebase, run npm install in the skill directory, run migration (reads ~/.openclaw/secrets.json), and the connect handler will add an exec provider to ~/.openclaw/openclaw.json and suggest restarting the gateway. All of these actions are within the stated purpose (migrating/managing secrets), but they are impactful (mutating openclaw.json, migrating secrets from disk to a remote service, restarting gateway). The migration script reads local secrets.json and uploads values to Supabase — intended for this feature but high-impact, so require careful review and backups.

Install Mechanism

No remote arbitrary download/install spec is included; the SKILL.md instructs installing @supabase/supabase-js into a local skill directory via npm (npm install --prefix ~/.openclaw/skills/supabase-vault). That is a common and expected mechanism. There is no installer that fetches code from arbitrary URLs; code files are included in the skill bundle. Still, running npm will bring external NPM packages into your environment — standard but should be considered.

Credentials

The skill requests (in instructions and at runtime) your Supabase Project URL and the service_role key. The service_role key bypasses RLS and is highly privileged; asking for it is coherent with providing a vault but it is sensitive and should be limited to a dedicated Supabase project. The registry declares no required env vars/primary credential which is inconsistent with the actual credential needs. The key storage methods (OS keychain or AES-GCM file) are appropriate, but the overall privilege of the requested secret is high and should be justified and isolated.

Persistence & Privilege

The skill is not always:true and allows user invocation. It does modify OpenClaw configuration (writes to ~/.openclaw/openclaw.json to add an exec provider) and the SKILL.md recommends restarting the gateway. Modifying the agent config is necessary for the exec-based secret provider, but it is a privileged, persistent change — the user should expect and review it. The skill does not attempt to change other skills' configs beyond adding the provider entry.

Scan Findings in Context

[unicode-control-chars] unexpected: The SKILL.md contained unicode control characters detection. This is not required for a vault integration and can be used to obfuscate or manipulate parsing of the file; inspect the SKILL.md for hidden characters before trusting/automating installation.

What to consider before installing

What to check before installing: - Metadata mismatch: the registry lists no required credentials, but the skill requires your Supabase Project URL and the service_role key. Treat that as a red flag: ask the publisher why metadata omits this, or treat the omission as an indicator you should proceed cautiously. - Use a dedicated Supabase project: the skill requires the service_role key which bypasses RLS. Create a new Supabase project used only for OpenClaw secrets so the key cannot access other data. - Audit the code & SQL: review assets/setup.sql, migrate.js, fetch-secrets.js, and rpc-handler.ts to confirm they do exactly what you expect (they do in this bundle, but confirm no hidden endpoints or extra network calls). Pay attention to the migration script which will read ~/.openclaw/secrets.json and upload values to your Supabase project. - Backup local secrets & config: before running migration or letting the skill modify ~/.openclaw/openclaw.json, make backups of secrets.json and openclaw.json so you can revert if needed. - Credential storage & file permissions: the keychain fallback writes ~/.openclaw/supabase-vault-config.enc (mode 0600). Verify that file ownership/permissions are appropriate and that scripts in ~/.openclaw/skills/supabase-vault are owned by your user (the exec provider relies on trustedDirs and ownership checks). - NPM dependency risk: the instructions install @supabase/supabase-js into ~/.openclaw/skills/supabase-vault. Ensure you control the environment or pin a vetted version if you need a higher assurance. - Prompt-injection artifact: the SKILL.md contained unicode control characters according to the scanner — inspect the raw file for hidden characters or unexpected content. - Test in a sandbox: first deploy and test this integration in a non-production environment to validate behavior (connectivity, migration dry-run, provider registration, restart behavior) before using it on production secrets. If you are not comfortable auditing the code and managing a dedicated Supabase project with a service_role key, consider not installing or ask the skill author/publisher for verification and corrected registry metadata.

Supabase Vault — Enhanced Secret Storage

Replaces the local secrets.json vault with Supabase Vault. All OpenClaw API keys, tokens, and auth credentials are stored AES-256 encrypted in your Supabase Postgres database. Bootstrap credentials (the Supabase URL + service_role key needed to reach the vault) are encrypted locally using OS keychain or machine-derived AES-256-GCM.

See references/architecture.md for the full threat model and design rationale.

Prerequisites

• A Supabase project (free tier works). Get one at supabase.com.
• Project URL + service_role key (from Supabase Dashboard → Settings → API).
• Node.js 18+ (already available in OpenClaw's environment).

Installation

Step 1 — Install @supabase/supabase-js

npm install --prefix ~/.openclaw/skills/supabase-vault @supabase/supabase-js

Step 2 — Run setup.sql in Supabase

Open your Supabase project → SQL Editor → paste and run assets/setup.sql.

This creates four wrapper functions (insert_secret, read_secret, delete_secret, list_secret_names) restricted to service_role only.

Verify with:

SELECT proname FROM pg_proc
WHERE proname IN ('insert_secret','read_secret','delete_secret','list_secret_names');
-- Should return 4 rows

Step 3 — Install the gateway RPC handler

Copy assets/rpc-handler.ts to src/gateway/server-methods/supabase-vault.ts in the OpenClaw source, then register it in the server-methods index:

// In src/gateway/server-methods.ts (or equivalent)
import { createSupabaseVaultHandlers } from "./supabase-vault.js";
// ...
Object.assign(handlers, createSupabaseVaultHandlers());

Step 4 — Install the dashboard UI

Copy the UI files to their destinations:

assets/controller.ts → ui/src/ui/controllers/supabase-vault.ts
assets/views.ts      → ui/src/ui/views/supabase-vault.ts

Register as an Integrations tab using the plugin architecture (same pattern as pipedream-connect or discord-connect):

// In the plugin registration or plugins-ui.ts:
{
  id: "supabase-vault",
  label: "Supabase Vault",
  icon: "🔐",
  section: "integrations",
  controller: "supabase-vault",
  view: "supabase-vault",
}

Step 5 — Rebuild & restart

cd ~/openclaw && npm run build
(sleep 3 && systemctl --user restart openclaw-gateway) &

Step 6 — Connect via dashboard

Open the Control UI → Integrations → Supabase Vault. Enter your Project URL and service_role key, then click Connect & Test.

Exec Provider Config

After connecting, the skill automatically adds this to ~/.openclaw/openclaw.json:

{
  "secrets": {
    "providers": {
      "supabase": {
        "source": "exec",
        "command": "node",
        "args": ["~/.openclaw/skills/supabase-vault/scripts/fetch-secrets.js"],
        "jsonOnly": true,
        "trustedDirs": ["~/.openclaw/skills/supabase-vault"],
        "timeoutMs": 8000
      }
    }
  }
}

After migrating secrets, SecretRefs in config will point to this provider:

{ "source": "exec", "provider": "supabase", "id": "/OPENAI_API_KEY" }

How It Works

Gateway starts
  → exec provider triggers fetch-secrets.js
      → keychain.js retrieves SUPABASE_URL + SERVICE_ROLE_KEY
          (macOS: Keychain Access / Linux: GNOME Keyring / fallback: AES-256-GCM file)
      → @supabase/supabase-js createClient(url, key)
      → supabase.rpc('read_secret', { secret_name }) for each requested key
      → outputs: { protocolVersion: 1, values: { "/KEY": "value" }, errors: {} }
  → OpenClaw runtime snapshot populated — secrets in memory only

Bootstrap Credential Storage by Platform

Platform	Method	Storage
macOS	security CLI	Keychain Access (hardware-backed on Apple Silicon)
Linux (desktop)	secret-tool	GNOME Keyring / KWallet
WSL2 / headless	AES-256-GCM	~/.openclaw/supabase-vault-config.enc (machine-derived key)
Any	AES-256-GCM	Fallback always available

The AES-256-GCM fallback uses PBKDF2-HMAC-SHA512 (600,000 iterations) with a key derived from /etc/machine-id + $USER + app-salt. The encrypted file is unreadable on any other machine or as any other user.

Migration

From the dashboard: Integrations → Supabase Vault → Migrate from Local Vault.

Or from the CLI:

node ~/.openclaw/skills/supabase-vault/scripts/migrate.js
node ~/.openclaw/skills/supabase-vault/scripts/migrate.js --yes      # non-interactive
node ~/.openclaw/skills/supabase-vault/scripts/migrate.js --dry-run  # preview only

Migration moves all keys from secrets.json to Supabase Vault and updates all SecretRefs in openclaw.json from file → exec/supabase. The local secrets.json is left in place as a safety backup.

Security Notes

• Vault secrets: AES-256 encrypted at rest via libsodium. Encryption key never in DB — database dumps are useless without it.
• Bootstrap creds: Encrypted via OS keychain or AES-256-GCM with machine-derived key. Not readable on another machine.
• Service_role key: Bypasses Supabase RLS — keep this project dedicated to OpenClaw secrets only.
• Memory only at runtime: No decrypted values on disk. Secrets in RAM during gateway session only.
• exec provider security: OpenClaw validates trustedDirs and file permissions on fetch-secrets.js before execution.