Built for CISOs
AI deployments create a hard problem: credentials must be accessible enough for agents to use, but secure enough that a breach does not result in unlimited inference spend, data exposure, or regulatory liability. This page explains how Clevername addresses that problem.
Existing approaches fail in predictable ways: store keys in environment variables and they appear in logs and are visible to every developer with container access. Rotate keys manually and it doesn’t happen. Let the AI platform hold your keys and you have no audit trail, no visibility into usage, and no recourse if the platform is breached.
Clevername’s model: bring your own keys, we handle routing and policy, you keep control.
Security Architecture
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 — 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. (Conversation I/O logs are a separate system and can be encrypted client-side; see the I/O-log encryption setting in the dashboard.)
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 cryptographically bound to the agent version. Model or system prompt changes require re-governance — you cannot silently update a governed agent.
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 — 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. Any deletion or modification breaks the chain detectably. GCP Secret Manager DATA_READ/WRITE audit logs are enabled separately and cannot be modified by the application layer.
Deployment Security
The hub-core backend has no public IP address. All traffic arrives through Vercel’s edge network and is authenticated with a short-lived GCP identity token before reaching Cloud Run. GCP organizational policy blocks allUsers invoker bindings — enforced at the organizational level, not by per-service configuration.
Every production deployment follows a canary pattern: new version deployed with zero traffic, smoke test runs against the canary directly, traffic shifted only on passing. A deployment with a startup crash or auth regression never reaches users.
Data Handling
| Data | Storage | Retention | Encryption at Rest |
|---|---|---|---|
| Conversation history | Supabase (Postgres) | User-controlled | Supabase TDE (AES-256) |
| Provider API keys | GCP Secret Manager | Until deleted | AES-256-GCM + CMEK |
| Conversation I/O logs (if client-side encryption enabled) | Supabase | User-controlled | AES-256-GCM, key derived in-browser |
| Audit logs | Supabase | 365 days (configurable) | Supabase TDE |
| Agent vault grants | Supabase | Until revoked | AES-256-GCM + VAULT_DELEGATION_KEY via CMEK |
| MCP credentials | Supabase | Until deleted | AES-256-GCM |
| Secret Manager audit logs | Cloud Logging | 365 days (configurable) | Google-managed |
- ✓Plaintext API keys in our application database (stored only in Secret Manager, fetched in-memory at call time)
- ✓Conversation content in logs (metadata only, unless org enables content logging)
- ✓Payment card data (Stripe handles payments; Clevername stores only Stripe customer ID)
- ✓Passwords (Supabase Auth handles all credential storage)
Access Controls
MFA is required for all platform admin actions, creating or modifying vault grants (AAL2), and signing approval decisions. Users without MFA are blocked from sensitive operations via HTTP 403.
RBAC with four roles: Owner (full control including billing), Admin (agents, integrations, keys), Member (use agents within scope), Viewer (read-only). Roles can be scoped to specific agents, departments, or environments.
SCIM 2.0 and SSO (SAML 2.0 / OIDC) are available on Enterprise — contact us to enable. When active, SCIM supports automated user provisioning from Google Workspace, Azure AD, and Okta; deprovisioned users are removed from all organizations and their agents are reassigned or quarantined, with API gateway tokens expiring within a 72-hour grace window so in-flight automation winds down cleanly. SSO allows admins to enforce SSO-only login to prevent password-based access. Both capabilities require Enterprise plan activation; they are not enabled by default.
Regulatory Alignment
Controls documented across CC6, CC7, CC9, A1, C1, and P5 criteria. Formal third-party audit planned for 2026.
Data minimization, right of access, right to erasure (account deletion removes all user data). DPA available for enterprise customers.
Not BAA-covered by default. Enterprise customers requiring HIPAA coverage should contact us for a dedicated deployment arrangement.
Clevername does not process, store, or transmit payment card data. Stripe is the payment processor (PCI DSS Level 1 certified).
Enterprise Deployment Options
Shared Infrastructure
DefaultStandard 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 — 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
Dedicated Deployment
Enterprise · RoadmapOn 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
Bring Your Own Vault (BYOV)
EnterpriseFor 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)
Penetration Testing and Vulnerability Disclosure
Clevername maintains an active red-team testing program. Adversarial test suites cover prompt injection bypasses (Unicode smuggling, Base64 obfuscation, XML injection, temporal bypasses), IDOR attacks on org and user endpoints, budget enforcement circumvention, auth bypass via header manipulation, and guardrail bypass attempts.
Responsible disclosure: report to support@clevername.net. We acknowledge within 2 business days, provide a resolution timeline within 10 business days for critical issues, and credit researchers in release notes with their permission.
For SOC 2 report requests, dedicated deployment discussions, BAA arrangements, or custom security reviews, reach out to our enterprise team.