Security Model
Kevo is built around authenticated user intent, a sandboxed wallet iframe, server-side policy enforcement, and a hardware-isolated signer boundary running inside a trusted execution environment.
Threat Model
Kevo's security model focuses on these primary threat categories:
⚠ Compromised application frontend
✓ The host app never receives embedded wallet key material. Sensitive wallet UX and export confirmation run inside the Kevo iframe, and the API enforces project- and user-scoped permissions server-side.
⚠ Compromised API or database layer
✓ Signing is separated behind a dedicated hardware-backed TEE signer boundary. The API can validate auth and policy, but key operations remain isolated in the signer.
⚠ Replay and unauthorized internal requests
✓ Internal signer requests are authenticated with signed headers, timestamps, and nonces. User auth endpoints use one-time challenges or OTP verification, with short-lived access tokens and HttpOnly refresh cookies.
Wallet Architecture
Kevo's embedded wallets are provisioned and operated through a server-backed signing model designed for smooth multi-device usage. A normal user login is enough to continue using the same wallet on a new device; there is no local browser share that must be migrated first.
The signing system is intentionally split into layers: the public API handles auth, rate limits, session lifecycle, and policy checks; the signer handles provisioning, export, and signing through a tighter internal interface.
Provisioning: Wallet creation happens after the user authenticates. The resulting EVM or Solana wallet is associated with that project-scoped user record and verified auth/profile methods.
Signer boundary: Key operations are routed through a dedicated signer interface running inside a hardware-backed TEE such as AWS Nitro Enclaves.
Signing: The SDK requests signing through authenticated API endpoints such as /v1/wallets/me/sign and /v1/wallets/me/solana/sign. The response is a signature, transaction hash, or explicit export result.
Exports: Private key export is explicit, verified, and OTP-gated. Users without a provider email must link one by OTP before export. The host page does not directly read raw key material from the browser.
Delegations: Backend automation is controlled by policy-bound delegations instead of exposing wallet secrets to developer backends.
MPC, TSS, TEE, and What Kevo Uses
Wallet security terms are often overloaded. Kevo is intentionally explicit about which model it uses:
Classic MPC / TSS
Multiple parties jointly sign without reconstructing the private key in one place. In a browser wallet this usually means the browser keeps a persistent client share. Kevo does not rely on that model for embedded wallets.
TEE-backed signer
A trusted execution environment isolates key operations from the general API and host system. Kevo routes wallet provisioning, signing, and export through this signer boundary.
Server-backed wallet access
The user authenticates normally on any device. Kevo checks session, origin, project policy, quota, and action-specific rules before routing a signing request to the signer.
Signing Iframe
The signing iframe remains an important browser-side boundary even though it no longer stores a user-side signing share. It isolates sensitive UX from the host application and reduces the blast radius of frontend compromise.
Cross-origin sandboxing
The iframe runs on a separate origin. Same-origin policy prevents the parent page from reading iframe state or storage.
Secure confirmations
Signing, exports, and wallet UX prompts are mediated through the iframe so the host app cannot silently forge user consent.
Strict messaging
Communication uses postMessage with origin validation and a typed message contract.
No key material in parent
The parent application receives only responses such as signatures, wallet metadata, or export results after Kevo-controlled verification steps.
Request Lifecycle
A signing request moves through multiple boundaries before any key operation:
Developer app -> Kevo iframe: user-visible wallet UX and confirmation -> Kevo API: session, origin, project, quota, delegation, and policy checks -> Signer boundary: provision, sign, export, and zeroize key material -> API response: signature, tx hash, wallet metadata, or explicit export result
For sponsored gas and smart-account flows, Kevo also validates sponsorship settings, chain support, project budget, and transaction constraints before submitting the user operation.
Session Security
Access tokens
Access tokens are short-lived JWTs (15 minutes). They are stored in memory only, never in localStorage or cookies accessible to JavaScript on your domain. The SDK refreshes them automatically using the HttpOnly cookie.
Refresh tokens
Refresh tokens are stored in an HttpOnly; Secure; SameSite=Strict cookie. They cannot be accessed by JavaScript and are automatically sent only to the Kevo API domain. Tokens expire after 7 days and are rotated on refresh.
DIDs and user isolation
Each user is identified by a Decentralized Identifier (DID) scoped to the project:
// DID format:
did:kevo:{projectId}:{authMethod}:{identifier}
// Examples:
did:kevo:proj-uuid:email:[email protected]
did:kevo:proj-uuid:wallet:0xAbCd...1234
did:kevo:proj-uuid:sol_wallet:8vCy...XYZUsers are fully isolated per project. The same email address in two different projects creates two separate user records with separate wallets.
HTTP Security Headers
The Kevo API sends the following security headers on every response:
X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Referrer-Policy: strict-origin-when-cross-origin Strict-Transport-Security: max-age=63072000; includeSubDomains; preload // production only
Auditability
Security-sensitive actions can be observed through webhook events and internal logs. Webhook deliveries are signed so your backend can verify that events came from Kevo before updating your own audit trail.
Auth events: User creation, authentication, linked email, and linked provider events.
Wallet events: Embedded EVM and Solana wallet creation events.
Signing events: Message, typed data, transaction, user operation, Solana signing, and delegated signing events.
Export events: OTP request and key export completion events for sensitive recovery or migration flows.
Rate Limiting & MAU
Authentication, export, and other sensitive endpoints are rate-limited by IP and by identifier using Redis-backed controls. See the API Reference for specific endpoint behavior.
Free-tier projects are limited to 1,000 Monthly Active Users (MAU). When the limit is reached, new sign-ins return a 429 with a user-facing error. Existing sessions continue to work.
Responsible Disclosure
If you discover a security vulnerability in Kevo, please report it to [email protected]. We commit to acknowledging reports within 48 hours and resolving critical issues within 7 days.