How your broker keys are actually protected.

You paste your API key into the Connect form. It travels over HTTPS straight into a database function — it never touches our application servers as a readable value in between.

That function encrypts it immediately using Supabase Vault (built on pgsodium) and stores only the encrypted secret. The broker_connections row you can see in your dashboard never contains your real key — only a pointer to the encrypted value and the last 4 characters of your key ID, for you to recognize which connection is which.

• Only our trading engine can decrypt a stored key — never the web dashboard you're using right now.
• That's enforced at the database level, twice: the decrypt function's execute permission is revoked from every normal login and granted only to the engine's own database role, and the function itself independently checks that it's being called by that role before it will decrypt anything.
• Row-level security means you can only ever see your own connection — and even your own row never holds a usable secret, so there's nothing to leak by seeing it.
• Every broker request goes out over HTTPS to the broker's own API — no unencrypted fallback exists.

Once decrypted, your key exists in memory for exactly as long as it takes to build one API client for your bot — and it's used for exactly one thing: placing the orders your own bot's strategy decides on. There's no second code path that reads it for analytics, no admin tool that lets our team pull it up for a support ticket, no feature anywhere in the product that touches it for any purpose other than the trade your bot is about to place.

That's not a policy we're promising to follow — it's the only code path that exists. There is exactly one function that can decrypt a stored key, and its only caller is the trade-execution loop shown above.

• Disconnect, any time. Removing a connection deletes the encrypted secret immediately and permanently — it isn't soft-deleted or kept around.
• Rotate a key today by disconnecting and reconnecting with a new one. We don't yet have a single-click in-place rotation — see below.
• Create a trading-only key on your broker's side, with no withdrawal or transfer permission. Our own risk limits (max order size, exposure caps, a daily-loss halt, a kill switch) bound what your bot can do inside our platform — they can't restrict what your key is allowed to do at the broker itself. That part is on you when you generate the key, and we now say so directly on the connect form.
• See it happen. Connecting, disconnecting, and regenerating a webhook token all now write to a security-events log you can see on your Connections page.

Each bot also gets its own webhook token — a separate, much lower-stakes secret from your broker key. A leaked webhook token can only trigger a buy/sell signal for that one bot, and every trade it triggers still passes through that bot's own risk limits and the platform kill switch. It cannot read your broker key, touch another bot, or exceed the limits you've already set. It also can't be reused to hammer the endpoint — we rate-limit every token-authenticated request.

You can regenerate it instantly from the Strategies page if you ever suspect it's been shared or leaked.

We'd rather tell you what's incomplete than let a polished page imply otherwise.

• No one-click account deletion yet. Deleting your account (and therefore your keys) is a manual step on our end today, not a self-serve button. If you just want a key gone, Disconnect on the Connections page already does that immediately and doesn't require deleting your whole account.
• Key rotation is disconnect-and-reconnect, not an in-place "replace this key" action. Functionally equivalent, just two steps instead of one.
• Your broker key's own permissions are your responsibility. We don't currently validate or restrict what scope a connected key has at Alpaca or Coinbase — see the trading-only key guidance above.
• Database administrator access is a separate, platform-level concern. Our application code has no path — no admin panel, no support tool, no debug route — that reads a decrypted key. But like any hosted database, someone with direct Postgres administrator credentials to our infrastructure could, in principle, query the decrypted value directly. That's a property of how hosted databases work, not a gap our application code can close, and we think it's more honest to say so than to imply "not even we can see it".