Browser-local provider tokens
Your cloud provider API token is encrypted using PBKDF2 key derivation (600,000 iterations) combined with AES-256-GCM authenticated encryption. All cryptographic operations use the browser's native WebCrypto API. No JavaScript crypto libraries. Your provider token is never sent to RunClaw's servers.
Browser-direct API calls
When you create, resize, or delete a server, your browser calls the cloud provider API directly (Hetzner) or through a stateless proxy (Vultr, due to CORS restrictions). The decrypted token exists only in browser memory during the API call. RunClaw's server stores only one-way SHA-256 hashes of tokens for verification.
Setup-time secrets
During initial provisioning, some secrets -- such as an access gate token and optional LLM API keys -- are temporarily sent to RunClaw so they can be injected into your server's cloud-init script. LLM keys are encrypted at rest and deleted from our database after provisioning completes. These are setup-time secrets, not long-lived stored credentials.
Management features and relay
After provisioning, RunClaw's dashboard provides optional management features -- logs, terminal, workspace file access, and configuration updates -- that relay content through the control plane when you use them. These features are customer-initiated: RunClaw does not continuously inspect your server. When you are not using these features, no content flows through RunClaw beyond system-level metrics (CPU, memory, disk).
Verify it yourself: open DevTools, go to the Network tab, and watch the requests when you manage a server. You'll see your browser calling api.hetzner.cloud directly (or /api/vultr-proxy for Vultr). Check the Content-Security-Policy response header to confirm the enforcement.