Where do your AI keys go when you use our tools? A straight answer
An AI provider API key is a credit card number that also reads your mail. Any tool that asks for one should answer first: where does this string actually go? We ship several BYOK surfaces — the SamAI browser extension, the /chat page, the account vault — so here is the answer in enough detail to check our work, not just trust it.
The rule: your key goes to your provider, never through us
Every BYOK surface calls the provider directly from your browser. On /chat the request travels browser → provider; open devtools and you watch it happen. Our servers never see the prompt, response, or key in transit. The page makes only two kinds of requests: provider API calls to the host you configured, and one same-origin fetch that supplies your key from your own vault at /dashboard/settings when you choose to save.
How to verify it in 30 seconds
Open /chat signed in, save a test key, open Network, and send a message. You will see a fetch to api.openai.com, api.anthropic.com, api.groq.com, or the provider you selected — not to dracon.uk. Filter by dracon.uk and the only hit is the vault fetch that gave the browser the key.
- Open /chat and either paste a key per session or save one in the vault and reload.
- Open DevTools → Network, clear, send one prompt.
- Filter by the provider host. The headers carry Authorization: Bearer sk-… and the payload is your prompt. Our origin is not the destination.
- If you ever see chat content POST to dracon.uk, that is a bug — report it as severity-one.
The vault: AES-256-GCM per key, honest about the rest
If you save keys so they follow you, they live in the settings vault: AES-256-GCM encrypted per key before storage, decrypted only when your authenticated session asks over TLS, with list views showing only last four characters. The full key is shown once at create; after that only last-four hints remain. Rotation is one click — save a new key, old ciphertext is overwritten. Deletion is immediate. Vault access logs store key ID and timestamp, not the string.
We say plainly on the settings page: because encryption is server-side, the server can technically decrypt when serving your session. That is the trade for cross-device sync. If you do not want it, do not save — /chat works with a per-session paste that never touches our servers, and the SamAI extension defaults to an even stricter local path.
The extension: local first
The SamAI extension defaults to browser-local: keys in BYOK mode live in chrome.storage.local / browser.storage.local, used only to call providers you configured. Memory features that remember tab context store locally for the same reason. The philosophy holds across the 12 tools in our products catalog: credentials are load-bearing for you, not inventory for us. Uninstall the extension and the keys go with it.
Threat model: what we protect, what we do not
A key must be usable to be useful, so no storage protects against every attacker. Here is the boundary:
| Threat | Mitigated? | How |
|---|---|---|
| Network snooping | Yes | TLS to dracon.uk and to provider; vault fetch over TLS |
| At-rest theft of vault DB | Yes | AES-256-GCM per key; lists show last four only |
| Our servers seeing prompts | Yes | Browser-direct BYOK: prompts go browser → provider |
| Compromised browser/extension | No | If malware reads storage or intercepts before TLS, rotate keys on a clean profile |
| Stolen dracon.uk session | No | Session can fetch decrypted key via vault API — protect session, rotate if suspected |
What we never do
- Never proxy provider traffic — no middlebox, no logging, no optimization layer reading prompts.
- Never train on keys, prompts, or outputs. The question is legitimate, the answer is invariant.
- Never email a key, display it in a list, or include it in a support export — last-four hints only.
- Never gate BYOK behind a subscription. Chat with free-tier keys is free; Dracon Omni at /pricing buys tools and intel, not access to your own accounts.
- Never log plaintext keys. Logs record key ID + timestamp, not the string.
Save vs. paste: who should choose which
- Save in the vault if you work across devices and want keys to follow you. Cost is server-side AES-256-GCM and last-four display.
- Paste per session on /chat if you want zero server persistence — the key lives in memory for that tab and dies when you close it.
- Use the SamAI extension's local storage for daily driver work — browser profile, provider-direct, no server copy.
If a key leaks
Assume a key can leak like a password — screenshot, env file, screen share. Rotate at the provider first, not at Dracon.
- Revoke/rotate at the provider dashboard — the old string dies immediately there.
- In Dracon delete or overwrite the entry in the vault; last-four hints let you find the slot.
- If the leak was a shared session or extension compromise, sign out, rotate, and paste per session until you have a clean profile.
Where your keys live on dracon.uk today
Three surfaces, three homes. /chat can run with per-session paste (no home) or a vault key from /dashboard/settings. The vault is the cross-device home — AES-256-GCM per key, last-four, TLS only. The SamAI extension is the local home — browser storage, provider-direct, no server copy. For the rest of the catalog see all products and our pricing page: BYOK is constant, where the key lives is your choice.
The threat model we design against
A browser operator that holds API keys is a high-value target, so we name the threats plainly. Eavesdropping: every BYOK call from chat goes browser → provider over TLS; our servers never see the key in transit and we carry no proxy that could. At-rest theft: keys you save live encrypted in the settings vault — AES-256-GCM per key, with list views showing only the last four characters and decryption gated to your own session. The server can technically decrypt (that is the trade for cross-device sync), so if you do not want that capability to exist, do not save — chat works with a key you paste per session, and the SamAI extension keeps keys in your browser profile's own storage for the same reason. Phishing and support-channel leakage: we never email a key, never display one in a list, never include one in an export, and never train on prompts or keys — these are policy choices enforced by what the UI does not allow, not by fine print.
How to verify and what we still owe you
Open /chat, sign in, save a key, and watch the network tab: you will see provider API calls and one same-origin call that fetches your key from your own vault, nothing else. That observation is worth more than this paragraph. What we still owe is an independent audit letter and a public key-transparency log — both are planned after the next vault rotation, not before, because a premature audit that does not cover the rotation is a checkmark, not assurance. Until then we publish the mechanics in the open: the 12 tools in our products catalog share the same credential philosophy, the Dracon Omni subscription never gates BYOK surfaces (free-tier keys work without paying us), and the chat page states the tradeoff on the surface where you make the decision. If you ever see chat content hit dracon.uk, that is a bug — report it and we treat it as one.