Vault Secrets Rules

FATAL Constraints

• NEVER hardcode API keys, tokens, or credentials in SQL migrations, Edge Functions, or application code. This is a FATAL violation. HALT and replace with a Vault reference immediately.
• NEVER create secret-accessor functions without SECURITY DEFINER. Every function that reads from vault.decrypted_secrets MUST be SECURITY DEFINER.
• NEVER grant EXECUTE on secret-accessor functions to anon or authenticated roles. Only service_role MUST have access.
• NEVER expose decrypted secret values in query logs, RAISE NOTICE, or function return types visible to non-service roles.
• NEVER store secrets in custom tables outside vault.secrets. All secrets MUST reside in the Vault.

Mandatory Behaviors

• All secret-accessor functions MUST be owned by postgres and granted exclusively to service_role.
• Secrets MUST be inserted using vault.create_secret(), not raw INSERT into vault.secrets.
• Edge Functions that need secrets MUST call the accessor function via supabase.rpc('get_secret', ...) using the service-role key, not the anon key.
• After creating any accessor function, the agent MUST verify the access boundary: service_role succeeds, anon is denied.
• When rotating a secret, use vault.update_secret(secret_id, new_secret). NEVER delete and re-create — this breaks referencing UUIDs.
• All Vault operations MUST be executed through the MCP execute_sql tool to maintain audit traceability.