Security
Your keys stay encrypted. Your prompts stay out.
Your API key is stored encrypted in the LiteLLM proxy, never in the app database. We don't store your prompts or your virtual-key secret. Row-level security is on for every tenant table, so each organization sees only its own rows.
- You paste a keyClaude, OpenAI, or Grok
- LiteLLM proxyStores it encrypted
- App databasefusr_… alias and last 4
Never stored
Virtual key secrets
The secret LiteLLM returns is shown once so you can copy it. It's never written to the database. We keep only the fusr_ alias, plus the last 4 characters of a FUSR.ai key.
Prompts
Usage rows hold a token or request count, never message text. The proxy is set not to log prompts. For fusr/auto, the proxy reads the request to sort it by task, then sends FUSR.ai only the task type, a rough size, a token count for its text, how many images it has, how long an answer it asks for, how many messages it has, two short fingerprints, a few counts for picking a thinking level (tool calls, file names, error lines, and words like architecture), its max_tokens, and the thinking level the request asked for. The fingerprints are keyed hashes: one can only tell two requests on your key were the same, the other that they were the same chat, so the chat can stay on the model whose prompt cache is warm. Neither can be turned back into text. On the Compare page, the app passes your prompt to the two models and hands the answers back to your browser. Neither is written down or logged.
Master secrets
The proxy admin key, the proxy salt, the usage webhook secret, and the key that seals alert webhooks and shared memory notes come from the host environment. They're never in the database or the browser.
Webhook URLs in the clear
A Slack or Discord webhook you add for alerts is encrypted before it's saved. The page shows only the host and the last 4 characters.
What we keep
- Organization
- Its name and members. Nobody outside it can see its rows.
- Provider
- A display name, and whether the account is for coding or general work.
- Key reference
- The virtual key alias, a credential name we generate, whether it's active or revoked, who created it, and the last 4 characters of your provider key.
- Usage
- When it happened, which provider, and how many tokens or requests. That's it.
- Routing log
- For each fusr/auto request: when, the task type, a rough size in tokens, how many messages it had and its fingerprints, how much room it needed and which models were too small for it, which models were picked and which answered, the rule that applied, and a one-line reason FUSR.ai wrote. On Pro and Team, also the thinking level it was sent with and a short reason for it. If you pick a different model later, or give the answer a thumbs up or down, that too. Only you see it. Rows older than 90 days are deleted as new requests come in. Never the prompt.
- Routing that learns
- On Pro and Team, while it's on for you: how each call on your FUSR.ai key ended (worked, failed, timed out, or hit a rate limit) and how long it took, so FUSR.ai can learn from it. Only you see it. Rows older than 30 days are deleted as new calls come in, and turning learning off or resetting it deletes all of it. Also whether it's on for you, when you last reset it, and how many ratings you changed in the last 10 minutes, for a rate limit.
- Shared learning
- Once a day, for each task type and model: how many organizations added to it, the weighted count of requests, how many went well, and the rate from those. Added up from the routing log of everyone on Free, and everyone on Pro and Team with routing that learns on. No prompt, response, fingerprint, key, person, or organization is on it. A total is used only when at least 5 organizations add to it, and no organization counts for more than a quarter of one. Pro and Team picks can start from these totals. On Free your counts are always included. On Pro and Team, turning learning off leaves your counts out from the next daily update, and resetting it leaves out the ones from before the reset.
- Spend caps
- Your daily and monthly caps on your FUSR.ai key and the warning line, plus what the proxy priced each request on that key, with its request ID and time. Only you see it. Rows older than 70 days are deleted as new requests come in. Never the prompt or the reply.
- Prompt caching
- On Pro and Team, for each fusr/auto request: how many input tokens the provider read from or wrote to its prompt cache, and which model. Your organization sees the total under Savings. Never the prompt. While caching is on, the provider keeps the start of a chat in its own cache for a few minutes. Turning it off for your organization is in the audit log.
- Compare
- On Pro and Team, for each compare: when, the task type, the two models, token counts, how long each took, what the proxy priced it at, and your pick. Each side runs on a key made for that one call and deleted right after. Only you see it. Rows older than 90 days are deleted as new compares come in. Never the prompt or the answers.
- Shared memory
- On Pro and Team, only if you turn it on: the notes you type in Settings, encrypted before they're saved, and whether each one is on. Only you see them. When it's on, the proxy reads your notes from FUSR.ai for each request on your FUSR.ai key and adds them as one short note to the model. It keeps them in memory for at most 5 minutes and never logs them. FUSR.ai never saves notes from your requests. Deleting a note, or all of them, removes it for good. The audit log records turning it on or off, exports, and delete all, with a count, never the text.
- Call health
- For each call through the proxy: when it happened, which provider, whether it worked, failed, timed out, or hit a rate limit, and how long it took. It sets the provider status your organization sees. A call on a FUSR.ai key is kept without who made it, and each person counts for at most 20 calls per provider in 15 minutes. No prompt, reply, or error message. Rows older than 14 days are deleted as new calls come in.
- Provider status
- When a provider's public status page, or your own calls, showed a problem, and the incident title from that page.
- Terminal sign-in
- When you set up from a terminal: a scrambled copy (a hash) of its sign-in codes, the device name it sent, a hash of the network address it came from for a rate limit, and whether you approved it. Codes last 10 minutes and work once. Rows are deleted an hour after they expire. Never your FUSR.ai key.
- Setup
- Which setup step you reached, the tool you picked, and whether you closed the setup prompt.
- Audit log
- Every key created, rotated, revoked, paused, resumed, or capped, including the one-call keys a compare makes, every routing rule change, every terminal sign-in approved or canceled, and every change to where alerts go. It names the alias, the rule, or the channel and may include those last 4 characters, never the secret or the webhook.
- Alerts
- What fired, when, the suggested fix, whether you finished or snoozed it, and which channels it went to. Your quiet hours and time zone.
- Weekly digest
- Whether it's on for you, and for each week whether it was sent, skipped, or is waiting, the reason it was skipped (turned off, plan, or no usage), and how many tries it took. Not the email itself. Rows older than 13 weeks are deleted. The unsubscribe link names that week's send, never you.
- Billing
- Stripe customer ID, subscription ID, plan, status, renewal date, and whether it's set to cancel at the end of the period. Your card stays with Stripe.
Provider keys
You paste your own API key. FUSR.ai stores it encrypted inside the LiteLLM proxy and nowhere else. It's not in the app database, and it's never shown again. The database keeps only the last 4 characters, so you can tell keys apart.
How virtual keys work
01
You paste a Claude, OpenAI, or Grok key. FUSR.ai hands it to the proxy, which stores it encrypted.
02
The proxy mints a virtual key. Its secret is shown once and never written to the database.
03
The database keeps the alias, such as fusr_…, the credential name, and the last 4 characters of your provider key.
04
Replace saves the new key first, then revokes the old one at the proxy.
05
Revoke deletes the key at the proxy and marks the alias revoked. A revoked key can't be used again.
Sign-in tokens are encrypted by the auth service and never copied into these tables. Sign in