If your SaaS accepts a customer's own LLM API key, you are now storing a credential that can spend their money. Encrypt it with a managed key, show it once, scope who in your company can read it, use it only from your server, and give customers a clear way to revoke and review usage.
Why customers ask for it
Customers with existing provider agreements want their own pricing, their own data terms and their own spend controls. It also moves the model bill off your books. These are fair reasons.
The price is trust. A leaked customer key can be used by an attacker for their own workloads, billed to the customer, so the risk is theirs but the failure would be yours.
Storing the key
- Encrypt at rest with a key held in a managed key service, not in the same database as the ciphertext.
- Never log the key or return it in an API response. Show only the last few characters afterward.
- Separate the secret store from your main application tables so a database dump does not expose keys.
- Allow only the service that makes model calls to decrypt. Humans should not be able to read plaintext keys in production.
- Delete the key when the customer removes it or closes their account, and say so in your terms.
Validate and scope on entry
Test the key once when it is added, with a minimal, cheap call, and show the customer the result. Encourage them to create a dedicated key for your app rather than reuse one they use elsewhere. Where their provider supports it, tell them to give that key its own project or workspace, and a spend limit, so any misuse is contained. Provider documentation describes spend and rate limits per workspace that cannot exceed the organization's limits, which suits this case.
Limit what you do with it
Make calls only on the customer's behalf, for features they use. Add your own per-user limits so a runaway loop in your app does not burn their budget. See per-user limits for LLM features.
Log which calls used which key, with token counts, so customers can reconcile their provider bill against your records. Do not log content by default.
Error handling
When a customer's key fails, you will see errors they must fix: invalid key, revoked key, spend cap reached, no access to the model. Show a clear message to their admin and not an anonymous failure for end users. A spend cap error will not clear with retries, so do not loop. See telling rate limits from spend caps.
Tell the customer what you hold
Put it in your documentation: how the key is stored, who can access it, how to rotate it, and what happens if you have an incident. Customers will ask in security questionnaires.
Incident planning
Decide before you need to how you will tell affected customers to rotate keys if your secret store is ever exposed. Have a way to disable all stored keys fast, and a template message. The steps for the customer side are in how to rotate leaked API keys.
Quick check
Is accepting a customer key lower risk than using mine?
It changes the risk. Your cost exposure drops, while your duty to protect a stored secret rises. Treat it like handling passwords.
Sources
Last reviewed: 19 October 2026.
