Built for CISOs
and the reviews they run.

Server-Side Key Custody (Secret Manager + CMEK)

Your AI provider keys are stored server-side in Google Cloud Secret Manager, encrypted at rest with AES-256-GCM and wrapped by a Cloud KMS key (CMEK). They are not held in zero-knowledge form, because the backend must be able to decrypt them to forward your requests to the provider. But they are never written to our application database, never logged, and only the hub-core service account can read them. Keys are fetched at the moment of an API call and discarded from memory immediately after. There is no browser-side or passkey-based key vault: the key you paste is sent to our backend over TLS and encrypted there.

Zero-Knowledge I/O Encryption (per user, opt-in)

Stored agent content is a separate system from provider keys, and it can be zero-knowledge. A user who enables I/O encryption under Settings → Privacy derives a key from a passphrase in the browser (PBKDF2, 600,000 rounds) and generates an RSA-OAEP-2048 keypair; only the public key and a passphrase-wrapped private key reach Clevername. Every stored copy of that user's agent content (I/O log prompts and responses, tool-call arguments, results, and errors, PII and secret-finding excerpts, tool-call renders in observed actions, system-prompt previews and baselines, false-positive report text, and ClaimGuard evidence) is then encrypted with a per-record AES-256-GCM key wrapped once to the user's public key. No escrow, no server-side decrypt path. CleverGuard still scans the plaintext in memory before encryption, so this is zero-knowledge at rest, not end-to-end. Four things remain server-readable by design: tool arguments parked for a human approval (platform KMS envelope, deleted after execution or expiry), the results of asynchronous tool executions (same platform KMS envelope, so the requesting agent can poll for them; pruned by the 90-day content sweep), the contents of files the user's agent reads (same platform KMS envelope, so the server-side agent can receive the body it requested; the browser-held private key is not available to it), and content the user explicitly donates for training. For all four, an operator holding the KMS key and database access can read the content; the envelope means a database dump alone is not enough. Note also that this is a per-user opt-in setting rather than an organization-wide control. An administrator cannot enable it on a member's behalf, and content belonging to users who have not enabled it is stored readable subject to the platform-wide metadata-only default.

Encryption Keys (CMEK)

Clevername uses Google Cloud KMS (CMEK) to wrap stored secrets. On the default multi-tenant deployment this is a single shared Clevername-managed KMS key. You get CMEK protection without operating a key yourself, but the key is not per-tenant and is not one you own or control. Disabling the key renders all wrapped secrets unreadable, and every KMS operation generates an audit log entry exportable to your SIEM. The roadmap enterprise Dedicated deployment runs in your own cloud, where the KMS key lives in your GCP project and you control revocation directly.

Least-Privilege IAM

The service account that runs Clevername's backend has conditional IAM bindings that restrict Secret Manager access to only the secret name prefixes it needs. It cannot read platform infrastructure secrets (database credentials, OAuth client secrets) using the same binding that allows it to read user-key secrets. No service account key files exist anywhere in the CI/CD pipeline or runtime. All GCP authentication uses Workload Identity Federation with short-lived OIDC tokens.

Agent Review: Agent Governance

Before an agent can be deployed in production, it must complete a 27-question security intake covering data flow, tool scope, autonomy level, network access, compliance frameworks, and prompt security. The intake compiles to a guardrail profile stamped with a SHA-256 version hash of the agent's configuration. Changing the agent's saved model or system prompt invalidates that hash and forces re-governance, so you cannot silently change a governed agent's saved configuration. Separately, the system prompt sent on each request is compared at runtime against the baselines learned for that agent: a wholesale rewrite is rejected with HTTP 429, and smaller edits are recorded as drift alerts.

Human-in-the-Loop for High-Risk Actions

When an agent triggers a high-risk pattern (file deletion, payment initiation, sensitive system access), hub-core intercepts the tool call before execution and sends a push notification to the approver's mobile device. The decision is signed with Ed25519, so it cannot be forged or replayed. The LLM cannot bypass this gate; it operates at the protocol layer between the LLM's tool call request and the MCP server's execution.

Audit Trail

Every AI action is logged: token counts, provider, model, cost attribution, tool calls (server, tool name, arguments, not return values), policy decisions, and content hash. Records use a hash chain: SHA-256 of each record incorporates the previous record's hash. Modifying a retained record, forging a record, or deleting one from inside the chain breaks verification detectably; truncation of the newest records is covered by SIEM forwarding rather than by the chain itself. GCP Secret Manager DATA_READ/WRITE audit logs are enabled separately and cannot be modified by the application layer.

Standard multi-tenant SaaS on GCP clevername-488215. Tenants share infrastructure and a single platform database; isolation is logical (app-layer), with server-side ownership checks that scope every query to the caller's org. DB-level Row Level Security policies are deployed and rolling out to enforce mode. Secrets are wrapped with a Cloud KMS (CMEK) key, so you benefit from CMEK protection without operating a key yourself.

• +CMEK encryption (shared Clevername-managed key)
• +Logical per-tenant isolation (app-layer scoping today; DB-level RLS rolling out)
• +App-layer tenant scoping today; DB-level RLS rolling out
• +365-day audit log retention

On the roadmap for enterprise: deploy Clevername as a container in your own cloud environment, against your own GCP project and your own KMS keyring. You hold and control the KMS key; Clevername provides the software and the deployment pipeline. This is physical isolation in infrastructure you own, not a per-tenant project we run for you inside our cloud. Contact us to discuss timeline.

• +Runs in your own cloud: your GCP project, your KMS key
• +Your own infrastructure, physically separate from other tenants
• +Available for enterprise on request
• +Contract-defined support terms and custom retention

For enterprises with existing HashiCorp Vault, AWS Secrets Manager, CyberArk, or Azure Key Vault deployments. Your agents use your existing vault. Clevername never holds your secrets in its own Secret Manager.

• +HashiCorp Vault (AppRole + Kubernetes auth)
• +CyberArk CCP (read-only)
• +AWS Secrets Manager (IAM role)
• +Azure Key Vault (service principal or managed identity)