When you give a chatbot platform your AI provider key, you are handing it a secret that can spend your money. How the platform stores that secret matters more than almost any feature. A key saved in plain text in a database is one leak away from a bill you did not authorise. A key encrypted properly is useless to anyone who steals the database. This guide explains, in plain language and with enough technical detail for developers, how a key vault should work: what encryption at rest means, what AES-256-GCM is and why it is used, the role of nonces and authentication tags, where the encryption key itself lives, how keys are used at request time without being exposed, how rotation works, what encryption does not protect against and the questions to ask any vendor. Crescelo stores provider keys with AES-256-GCM.
The threat model
| Threat | Example | Defence |
|---|---|---|
| Database leak | A backup or a compromised admin exposes stored records | Encrypt keys at rest |
| Curious insider | An employee browsing data | Encryption, access controls and audit logs |
| Application bug | An endpoint accidentally returns a key to the browser | Never send keys to clients; store them encrypted; return masked values |
| Log leakage | A key is written to a log file | Redact secrets from logs |
| Stolen backup | An old backup surfaces | Encryption with a key stored elsewhere |
Encryption at rest is a strong defence against the first, second and fifth. Careful coding covers the third and fourth.
What AES-256-GCM is
AES is a widely used and heavily studied encryption standard. The 256 refers to the key length in bits, which makes brute-force guessing infeasible. GCM is a mode of operation that provides two things at once: confidentiality (nobody can read the data) and integrity (nobody can alter it without detection). This combination is called authenticated encryption, and it is the standard recommendation for encrypting data at rest.
| Term | Meaning |
|---|---|
| Key | The secret used to encrypt and decrypt; 256 bits (32 bytes) for AES-256 |
| Nonce or IV | A number used once for each encryption, so the same plaintext never produces the same ciphertext |
| Ciphertext | The encrypted result |
| Authentication tag | A short value that proves the ciphertext was not tampered with |
To store a key, the platform generates a fresh random nonce, encrypts the key with the master key, and stores the nonce, ciphertext and tag together. To read it, it uses the master key, the nonce and the tag; if the tag does not match, decryption fails, which reveals tampering.
Why the nonce must never repeat
GCM is fast and safe as long as a nonce is never reused with the same key. Reuse can leak information and allow forgery. The safe approach is to generate a fresh random 12-byte nonce for every encryption, which makes a collision astronomically unlikely at normal volumes, and to store the nonce alongside the ciphertext. Any implementation that derives nonces predictably or reuses them is a serious flaw.
Where the master key lives
Encryption is only as strong as the protection of the encryption key. Storing the master key in the same database as the encrypted secrets defeats the purpose. Good practice separates them:
- Keep the master key in an environment secret or a dedicated key management service, not in the database.
- Give the application access only at runtime.
- Restrict who can read production environment variables.
- Never commit the key to source control.
- Keep offline backups of the master key in a safe place; losing it means losing every stored secret.
Some platforms derive per-record keys from a master key, so a single leaked record key does not expose everything. Stronger setups use a cloud key management service that performs encryption operations without ever exposing the master key to the application.
Using the key at request time
- A visitor sends a message; the server needs to call the AI provider.
- The server reads the encrypted key record and decrypts it in memory using the master key.
- It makes the request to the provider, attaching the key.
- It discards the plaintext key immediately; it is never written to logs, error messages or responses.
- The dashboard shows only a masked version, such as the last four characters, when you view settings.
At no point does the key travel to your visitor's browser or appear in your website's code.
Rotation and revocation
- If a key might have been exposed, revoke it at the provider and paste a new one; the old ciphertext becomes useless.
- Rotate the master key periodically, re-encrypting stored secrets with the new one, and keep the old one only until migration completes.
- Keep an audit trail of when keys were added, changed or removed, and by whom.
- Tie rotation to events such as staff leaving.
What encryption at rest does not protect against
| Scenario | Encryption helps? | What else is needed |
|---|---|---|
| A stolen database backup | Yes | Protect the master key separately |
| An attacker who compromises the running application | Not fully: the app can decrypt keys | Least privilege, monitoring, network isolation, spending limits at the provider |
| A malicious insider with access to the application and environment | Not fully | Separation of duties, audit logs |
| A phishing attack on a customer's account | No | 2FA and access hygiene; see securing your chatbot account |
This is why you should also set a spending limit with your AI provider. If a key is ever misused, the damage is capped.
How to check a vendor
- Do you encrypt customer API keys at rest? With what algorithm and mode?
- Where is the master key stored, and who can access it?
- Are nonces random and unique per encryption?
- Can support staff see plaintext keys?
- Are keys ever returned to the browser or written to logs?
- How does rotation work, and can I revoke a key immediately?
- Do you have an audit trail for key changes?
Be wary of vague answers such as 'we take security seriously'. Specifics are the sign of a real implementation.
What you should do on your side
- Create a dedicated key for the assistant.
- Set a monthly spending limit at the provider.
- Enable alerts for unusual usage.
- Restrict who on your team can see or change the AI settings.
- Rotate the key if a team member with access leaves.
- Never paste the key into chats, emails or code.
See bring your own key explained for the wider picture.
Frequently asked questions
How does Crescelo store my API key?
Encrypted with AES-256-GCM, decrypted only in server memory when needed, and never sent to visitors' browsers.
What is AES-256-GCM?
A widely used authenticated encryption method: AES with a 256-bit key in Galois/Counter Mode, providing both confidentiality and tamper detection.
What is a nonce?
A number used once per encryption. It must be unique for each encryption with the same key.
Where should the master key be stored?
Separately from the encrypted data, in an environment secret or a key management service, with tight access.
Can encrypted keys still be misused?
If the running application is compromised, yes. That is why spending limits and access controls matter too.
Should I rotate my key?
Yes, after any suspected exposure and when someone with access leaves.
See how your data is protected, the data processing addendum, the AI assistant feature and pricing, and read SSRF protection for web scrapers.
Further reading
- OWASP Top 10 for Large Language Model Applications: The main security risks of AI assistants, including prompt injection.
- OpenAI API documentation: Models, pricing and limits for the OpenAI API.
SVARA ALLA BESÖKARE. BOKA DEM SOM ÄR REDO.
Lägg in Crescelo på din webbplats på 15 minuter
Träna din assistent på dina prislistor, dokument och tjänstevillkor. Aktivera välgrundade svar dygnet runt och bokning av tider direkt i chatten utan krockar.