How We Store Your API Keys
When you add an OpenAI, Anthropic, Google, Azure OpenAI, or any LiteLLM-supported BYOK key, it never touches our database in plaintext. Same storage mechanism on every tier (Free, Pro, Team, Enterprise). Here is exactly where it goes, how it is encrypted, and what happens when you delete it.
The short version
Your API key is transmitted over TLS directly to our backend and stored in Google Cloud Secret Manager — the same infrastructure Google uses to manage secrets across its own services. It is never written to our database. Our database holds only a masked display hint (first 4 + last 4 characters) so you can identify which key is connected.
In production, every secret is further protected by a Cloud KMS (CMEK)wrapping key via GCP Cloud KMS — an encryption layer above Google’s default at-rest encryption. On the default multi-tenant deployment this is a single shared, Clevername-managed key (not a per-tenant key you own). Disabling that key makes all wrapped secrets unreadable.
What our database actually stores
sk-a…3f9bDisplay hintMasked for identification only. Useless for API calls.anthropicProvider nameWhich provider this key belongs to.2026-03-12Created atWhen you added it.nothingPlaintext keyNever written here. Stored in Secret Manager only.What Secret Manager actually stores
GCP Secret Manager holds the plaintext key value, encrypted at rest with AES-256-GCM. On top of that, CMEK wraps the data encryption key (DEK) with a Cloud KMS key that Clevername manages (a single shared key on the default multi-tenant deployment). Access is restricted by Cloud IAM — only our backend service account (hub-core-runtime) can read the secret. No Clevername employee or Google employee has direct access.
Where your key goes, step by step
- 1
You enter your key
The key is entered in your browser and transmitted over TLS 1.3 to our backend. It is never logged or cached at the Vercel edge layer.
- 2
Backend writes to Secret Manager
Our backend creates a new secret version in GCP Secret Manager named clevername-key-{your_user_id}-{provider}. The plaintext value is written there — nowhere else.
- 3
CMEK encryption wraps it
Secret Manager generates a data encryption key (DEK) for this secret version. That DEK is immediately wrapped by our Cloud KMS key. The plaintext DEK is discarded. Going forward, accessing the secret requires both Secret Manager permission and the KMS key to be active.
- 4
Database gets only the hint
Our Postgres database receives a row with the masked hint (sk-a…3f9b), the provider, and a timestamp. No plaintext, no ciphertext — just the metadata.
- 5
Old secret version is destroyed
If you update a key, the previous Secret Manager version is destroyed immediately. There is never more than one live version of your key.
What is CMEK and why does it matter?
By default, cloud providers encrypt your data with keys they control. CMEK means the wrapping key lives in GCP Cloud KMS and is managed by Clevername — a single shared, Clevername-managed key on the default multi-tenant deployment (not a per-tenant key you own). The practical difference:
Google holds the encryption key. Decryption depends entirely on Google-controlled key material.
Clevername manages the KMS wrapping key. Reading a wrapped secret requires that key to be active, so disabling it makes the secrets unreadable. (A Google-managed Cloud KMS key still runs on Google infrastructure — it is not an absolute guarantee against the cloud provider.)
Request arrives at hub-core
A governed agent makes a request through the Clevername gateway (using its cn-*token). The request hits our backend (GCP Cloud Run, private — no public internet access) after passing through Vercel's edge layer.
Key is fetched from Secret Manager
Hub-core makes one API call to GCP Secret Manager to retrieve your key. This call is logged in GCP Cloud Audit Logs with a timestamp and the requesting service account — verifiable by export to your SIEM.
Key is used in memory, then discarded
The plaintext key exists in hub-core's memory for the duration of the provider API call — typically under 100ms. It is never written to disk, never included in logs, and never stored after the request completes.
Response returned, key gone
The provider's response is returned to you. The plaintext key reference is garbage-collected. The next request that needs your key fetches it fresh from Secret Manager. Decrypted keys are never written to a cache — only key metadata (provider, masked identifier, timestamps) is cached, and only to keep the keys page responsive.
Who can read your secrets
Access to Secret Manager is controlled by GCP Cloud IAM with scoped conditional bindings:
| Principal | Access |
|---|---|
| hub-core-runtime service account | Read/write — scoped to clevername-key-* and clevername-mcp-* prefixes only. Cannot read database credentials or OAuth secrets. |
| Clevername employees | No standing IAM binding to read user-key secrets, and every access is recorded in Cloud Audit Logs. Holders of high-level GCP project-administration roles retain the technical ability to change these bindings — restricted, logged, and being tightened; on a Dedicated deployment you hold that control yourself. |
| Google employees | No IAM grant to read user-key secrets. CMEK adds a Cloud KMS wrapping layer on top, though the KMS key itself runs on Google infrastructure. |
| Other GCP services | None. Bindings are explicit and minimal. |
What happens when you delete a key
When you remove a key from the dashboard, two things happen in the same transaction:
- 1.The secret is permanently deleted from GCP Secret Manager — all versions destroyed, unrecoverable. There is no soft-delete, no retention period.
- 2.The metadata row (hint, timestamp) is deleted from our Postgres database.