Security

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 that 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 — this 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, logged, and something we are progressively tightening; 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.

By default, Clevername logs metadata only — timestamp, model, token count, and latency — not the prompt or response content itself. This is the default on all plans, so a default account's audit trail records that activity happened without storing what was said. Full prompt/response capture, so you can audit and replay the actual content of AI agent activity, is opt-in and configurable per org. When you enable it, you can store content directly or turn on encrypted (zero-knowledge) I/O logging, where stored content is encrypted under a key derived from your passphrase that Clevername staff cannot read. You control this under Settings → Privacy, and can verify what's stored under Usage → Audit Log.

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.