Security Model

XKOVA is an orchestration layer, not a custodian. Human wallet private-key material remains non-exportable in the configured MPC provider, and the XKOVA Relayer can submit a transfer only after the contract receives a valid owner signature. The Thirdweb custom-JWT signing authority is still security-critical because it can bootstrap a general provider signing session. XKOVA enforces business purpose at its capability, frozen-intent, signature-acceptance, and on-chain boundaries.

The non-custodial property

Every value transfer requires a valid signature from the configured owner address or Safe quorum. In the normal product flow, the authorized person reviews and signs an EIP-712 intent through the configured wallet, and the XKOVA Relayer wraps the signed instruction in the contract's meta transaction entrypoint and pays gas to submit it. The contract recovers the signer on chain and rejects anything that does not match. Because the signature is the on-chain authorization, the platform never receives or exports the MPC private-key material. Thirdweb custom-JWT authentication can nevertheless establish a provider session capable of producing signatures. XKOVA therefore authorizes a frozen purpose before bootstrap, keeps the browser session ephemeral, and accepts only a signature that matches the exact intent and signer. See the Non-custodial Model for the mechanics.

The relayer is the on-chain sender and pays gas, but it cannot originate a transfer. Without the valid owner-address or Safe-quorum signatures required by the contract, the call reverts. The relayer moves nothing on its own.

What the platform can and cannot do

The platform can	The platform cannot
Build and freeze an intent, then present it for signing.	Receive or export the MPC private-key material.
Submit an accepted owner-address or Safe-quorum instruction and pay gas.	Move funds without the signatures required by the contract.
Apply policy and screening before relaying.	Extract a member's private key.
Reject signatures outside the authorized purpose.	Make Thirdweb enforce XKOVA's business purpose on a connected custom-JWT session.

Threat model

Platform compromise. XKOVA never receives or exports MPC private-key material. However, compromise of the Thirdweb custom-JWT signing authority plus use of the public client can establish a general provider signing session and produce owner signatures. Protect that authority as signing-critical. XKOVA purpose limits are separate acceptance-layer controls, so incident response must stop JWT issuance, reject affected signatures, revoke capabilities, and disconnect provider sessions where supported.
Relayer compromise. The relayer submits signed instructions and pays gas. Compromising the relayer alone does not provide the owner-address or Safe-quorum signatures the contract requires.
Stolen API key. A workspace API key is bearer authorization for customer server-to-server calls. A production mutation also requires an RFC 9421 signature from the active asymmetric credential bound to that API principal, so the bearer key alone cannot submit a production write or mint the separate Thirdweb custom-JWT bootstrap. Revoke and rotate immediately if a key is exposed.
Stolen request-signing key. The asymmetric credential adds proof of possession but grants no authority by itself. The server requires the separately bound bearer API key and rejects a signing credential registered to another principal. Revoke and rotate the signing credential independently if its private key is exposed.
Stolen application cookie. The browser cookie names only a customer BFF session and carries no reusable XKOVA or provider credential. The BFF validates Origin and CSRF, enforces idle and absolute expiry, and can revoke the exact XKOVA session. The wallet key remains separate.
Replayed request. Idempotency keys make a retried write safe: a key reused with a different body is rejected with a conflict error, so a replay can never submit a different operation under a retried key. See Idempotency.

Customer API request credentials

The bearer API key authorizes every customer API request. Production mutations additionally use XKOVA's strict RFC 9421 HTTP Message Signatures profile and RFC 9530 Content-Digest for a body. Production reads remain bearer-only; sandbox mutations are signed only when configured. The customer-held signing key can be P-256 P1363, Ed25519, or RSA-PSS with SHA-256, MGF1 SHA-256, and a 32-byte salt, and stays in the customer's KMS, HSM, or key provider. XKOVA selects the registered credential algorithm by keyid, not from a client-controlled RFC 9421 alg parameter. See SDK Overview and Key Management.

Authorization and governance

Beyond the signature, every mutation is authorized against a single permission registry, and high blast actions are gated by an approval quorum with separation of duties. Every financial or governed mutation records the authority exercised. These controls run in front of the relayer, so a denied or unapproved action never reaches the chain. The posture is secure by default: a fresh workspace is seeded with owner-approval requirements on six high impact actions (governance changes, ownership transfer, policy commits, API key creation, signer changes, counterparty additions), and the gate on governance changes itself cannot be removed. See Roles and Permissions, Policies and Quorum Governance, and the Audit Log.

Auth boundaries

The customer server authenticates with its workspace API key. A member-initiated BFF request adds an exact XKOVA member session created from a verified provider proof. Provider credentials and XKOVA session material stay server-side. Certain high impact actions additionally require a fresh purpose-bound step-up proof. The full product-specific entry points are in Authentication.

Secrets hygiene

Never commit API keys to source, and never log the Authorization header. Keep tenant keys on a server or trusted worker, not in a browser.
Each key is shown once at creation; only a prefix and a hash are stored. Rotation returns a replacement once and revokes the old key.
Never send provider proofs, XKOVA session IDs, or refresh credentials to browser JavaScript. Store them behind the customer's first-party application session.
Member MPC private-key material remains non-exportable at the wallet provider and is never exposed to the platform or integrators. Treat custom-JWT signing authority as signing-critical because it can bootstrap a general provider session. See Key Management.

Compliance posture

Items defined by the business rather than by the API (formal certifications, data retention windows, support tiers, and service levels) are available on request and are defined by the business. See Support for how to reach the team.

See Key Management for how keys are held and rotated, Screening and Identity Verification for the compliance controls that run before a transfer, and the interactive reference for the operations behind each control.

Was this helpful?