Your keys live in Google’s vault.

When you add an API key for OpenAI, Anthropic, or Google Gemini, that key is sent 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. Your key is never written to our database. The Clevername database holds only a masked hint (first 4 + last 4 characters) so you can identify which key you've connected. The plaintext key exists only inside Google's Secret Manager and in our backend process's memory during the milliseconds it takes to make a provider API call. In production, Google Cloud Secret Manager is the exclusive key store. Local development instances use AES-256-GCM encryption with a server-side secret instead of Secret Manager. That fallback is never active on clevername.net.

Google Cloud Secret Manager encrypts every secret version with AES-256-GCM. Access is controlled by Google Cloud IAM. Only the runtime service accounts that run our backend (hub-core-runtime@clevername-488215.iam.gserviceaccount.com, plus a separate identity per service) have permission to read secrets. Each service holds only the per-secret grants it needs; the CI deployer identity is separate and does not serve traffic. No Clevername employee is granted a standing IAM binding to read Secret Manager secrets, and every access is recorded in Cloud Audit Logs. As on any cloud platform, holders of high-level GCP project-administration roles retain the technical ability to change these IAM bindings. That access is itself restricted and logged, and we are tightening it further. On the roadmap enterprise Dedicated deployment (runs in your own cloud) you hold that administrative control yourself. Each time you update a key, the old secret version is immediately destroyed. There is never more than one live version of your key in Secret Manager.

By default, cloud providers encrypt your data with keys they control. Clevername adds a layer: every secret in our Secret Manager is wrapped with a key that lives in GCP Cloud KMS (CMEK), on top of Google's default encryption. On the default multi-tenant deployment, this is a single shared KMS key that Clevername manages. It is not a per-tenant key, and it is not one you own or control. What it gives you: • Disabling the KMS key makes all wrapped secrets unreadable (a break-glass control). • Secrets carry a CMEK wrapping layer above Google's standard at-rest encryption. • The encryption layer is auditable: every KMS key usage (encrypt, decrypt) is logged to GCP Cloud Audit Logs. Per-tenant, customer-owned key control is on the roadmap as an enterprise Dedicated deployment that runs in your own cloud: your GCP project, your KMS key. That is the model regulated industries (healthcare, finance) rely on for HIPAA and SOC 2 Type II, where the customer must demonstrably control encryption material. On the default tier today, the shared key is Clevername-managed. KMS key: us-east1 · Key ring: clevername-user-secrets · Algorithm: AES-256-GCM

When you send a message through Clevername: 1. Your message arrives at our backend over TLS 2. The backend fetches your API key from Secret Manager (one network call, in-memory only) 3. The key is used to forward your request to the provider (OpenAI, Anthropic, or Google) 4. The key reference is discarded from memory 5. The provider's response is returned to you At no point is your key written to disk, logged, or included in any audit record.

Clevername scans every prompt and response in memory, on plaintext, before anything is written. What is stored afterwards is governed by two controls. 1. Platform-wide default: metadata only. The agent I/O log and the tool-call log record timestamp, model, token counts, latency, verdicts, and a content hash keyed with a server-held key scoped to your organization (enough that a stolen database is not a lookup table for short prompts; not zero-knowledge, since staff holding that key could still test guesses). It does not record the prompt, response, or tool text. Storing prompt and response text is a platform-wide setting that is off; there is no per-organization switch to turn it on. 2. Per user: zero-knowledge I/O encryption. Turn it on under Settings → Privacy. Your browser derives a key from your passphrase (PBKDF2, 600,000 rounds) and generates an RSA-OAEP-2048 keypair; only the public key and a passphrase-wrapped copy of the private key reach Clevername. After that, every stored copy of your agents' content (I/O log prompts and responses, tool-call arguments, results, and error text, PII and secret-finding excerpts, tool-call renders in observed actions, system-prompt previews and baselines, false-positive report text, and ClaimGuard evidence) is encrypted with a per-record AES-256-GCM key wrapped once to your public key. There is no escrow copy and no server-side decrypt path, so Clevername staff cannot read it. Content flags attached to encrypted rows carry only categories and scores. Four things stay readable by the server on purpose: tool arguments parked for a human approval (encrypted with Clevername's platform KMS key so the approved action can run, deleted after it runs or expires), the result of an asynchronous tool execution (same platform KMS key, so the agent that started the call can poll for it; purged with the 90-day content window), the contents of files your agent reads (same platform KMS key, so the server-side agent can receive the body it asked for, since it cannot use the private key held in your browser), and content you explicitly donate for training. For all four, someone with our KMS key and database access can read the content. You can verify what is stored under Security → I/O Log, where encrypted rows are decrypted in your browser only after you enter your passphrase.

Clevername uses Supabase Auth for user authentication, which is built on industry-standard JWTs. Sessions are short-lived and refreshed automatically. All dashboard actions require a valid authenticated session. Our backend verifies your Supabase JWT on every request. API keys stored in Secret Manager are scoped to your user ID. Another user's service account binding cannot access your secrets.

When you disconnect a provider key from the dashboard, two things happen simultaneously: 1. The secret is permanently deleted from Google Cloud Secret Manager (all versions destroyed, unrecoverable) 2. The metadata row (hint, timestamp) is deleted from our database If you delete your Clevername account, all of your secrets are deleted from Secret Manager as part of account cleanup.

If we become aware of a security issue affecting user data, we will notify affected users by email within 72 hours. For responsible disclosure of security vulnerabilities, contact support@clevername.net.