Trust Center

Sensitive vault content and metadata are end-to-end encrypted with XChaCha20-Poly1305 (AEAD) using keys derived in the client’s browser — the server stores ciphertext it cannot decrypt. Server-side operational material (audit-log signing keys, per-tenant server salts, email ciphertext) is additionally encrypted with AES-256-GCM under a per-tenant Key Encryption Key held in AWS KMS.

A breach of our database yields ciphertext only. A breach of our KMS yields server-side material only — never vault content, because vault content keys are never present on our servers.

TLS 1.3 for all connections, fronted by Cloudflare. Our content-security policy pins font and asset sources to self; there is no runtime third-party script required to render the application.

Vault keys are derived from a Two-Secret Key Derivation (2SKD). The Master Key is computed as Argon2id(masterPassword, salt) where salt = BLAKE3(serverSalt ‖ secretKey ‖ lowerCaseEmail). It requires TWO client-held secrets: a master password the user memorizes, and a 128-bit Secret Key generated client-side at onboarding (printed and vault-stored, never transmitted to us).

From the Master Key we derive — client-side, via HKDF-SHA-256 with distinct domain separators — a Master Root Key (metadata) and a Content Root Key (content); per-item keys derive from those. None of the master password, Secret Key, Master Key, Master Root Key, or Content Root Key is ever stored by GuardKin in any form. An attacker who coerces the password but lacks the physically-held Secret Key still cannot derive the keys.

The per-tenant Key Encryption Key lives in AWS KMS. Every encrypt/decrypt operation is logged in CloudTrail, and the IAM policy enforces dual control for human callers. KMS-resident material protects operational assets only (audit signing keys, server salts, email DEKs) — it cannot decrypt vault content, which uses client-derived keys the KMS never sees.

Primary storage and processing are in the United States: Neon (Postgres) and AWS for compute, storage, and KMS. Edge layers (Cloudflare, Vercel) operate globally but terminate TLS and forward to US-region origins. At UK/EU launch (Stage 3) we operationalize GDPR data-subject handling with SCCs in place for non-Data-Privacy-Framework subprocessors. Full per-vendor regions are listed in the subprocessor register above.

Vault data persists for the life of the account and is deletable by the customer at any time. The tamper-evident audit chain is dual-written across two tiers — hot 90 days (Axiom) and cold WORM 7 years (S3 Object Lock); the 7-year cold-tier retention is immutable and survives company wind-down. Several subprocessors hold no data beyond the request: Anthropic runs on a zero-retention tier, and Persona is contractually bound not to retain identity documents after verification.

Yes. Customers can delete vault items and close accounts at any time, independent of subscription status or firm relationship. Because sensitive content is zero-knowledge, deleting the ciphertext and rotating/destroying the associated key material renders content permanently unrecoverable. The immutable 7-year audit chain is the one deliberate exception — it records that events occurred, never the plaintext content of vault items.

Yes — export is an architectural commitment (#7). User data is portable at any time regardless of subscription status or firm relationship. There is no hostage state: ending a subscription or unlinking from a firm never withholds the customer’s own data.

Authentication, MFA, and SSO are handled by Clerk (SOC 2 Type 2). MFA is required on every account; passkey / WebAuthn is supported and hardware keys are strongly preferred for the customer-side responsibility set. Sessions use short-lived tokens with session binding.

Crucially, access control is enforced by the data model, not only by policy: a bug in the advisor dashboard cannot expose sensitive content, because the server does not hold the keys to decrypt it (commitment #3).

Only consent-scoped planning metadata the client explicitly shares. Credentials, personal letters, specific beneficiary instructions, and medical directives are cryptographically invisible to the advisor, the firm, and to GuardKin. The client owns the vault and retains a unilateral right to unlink from the firm that no firm contract, configuration, or administrative action can override (commitments #1 and #2).

P0 incidents engage 24×7 founder on-call, with a target of counsel engaged within 4 hours and a postmortem within 7 days of any P0/P1 (design targets, measured from GA). Telemetry runs on Datadog and Sentry (with PII scrubbing at ingestion). If a security incident affects customer data, we notify affected customers and firms within 72 hours per applicable law (GDPR Art. 33/34) — in plain English, not legal boilerplate. The 72-hour notification is a legal commitment, not a target.

Infrastructure uses geographic redundancy with continuous backups and restore testing; no single-vendor outage takes the service offline except AWS, which is the trust root. Company-survival is an explicit architectural commitment (#8): source-code escrow, an encrypted-data custodian, key-material escrow held separately from source and data, and a 12-month minimum wind-down backed by insurance.

The 7-year cold-tier audit retention survives wind-down. Founder-incapacity continuity is counsel-led per a documented runbook. These provisions exist so that the people who depend on GuardKin at the worst moment are not stranded by a corporate event.

An independent cryptography review of the Two-Secret KDF and the metadata/content boundary is scheduled; the firm is not yet finalized (candidates: Trail of Bits, Cure53, NCC Group) — none is engaged or retained today. The full cryptographic specification and round-trip test vectors are published so reviewers can verify an implementation independently. Penetration testing runs against the in-scope surface; the executive summary is available under NDA once the first engagement concludes. A bug-bounty program opens at general availability.

Report to security@guardkin.com; the machine-readable policy is at /.well-known/security.txt. Our targets: acknowledge within 24 hours, give an initial assessment within 3 business days, and remediate Critical issues within 7 days (24 hours if exploitable in production) — design targets, measured from GA. Good-faith research conducted per the policy is authorized under a published safe harbor — we will not pursue legal action for compliant activity.

AI features call the Anthropic Claude API on a zero-data-retention (ZDR) tier: Anthropic does not retain the requests, and the requests are contractually excluded from model training. Inputs are redacted before they leave GuardKin — zero-knowledge vault content is never sent to the model, because the server cannot decrypt it to send in the first place.

Anthropic is a SOC 2 Type 2 subprocessor under a signed DPA. No AI provider receives credentials, personal letters, specific beneficiary instructions, or medical directives.

Every vault item splits into two cryptographic records: a metadata record (consent-scoped, decryptable for the experiences the client authorizes) and a content record (zero-knowledge, decryptable only by the client). The boundary is enforced by the data model, not by an access policy — so it cannot be relaxed for a single firm contract, a compliance request, or a law-enforcement demand. A subpoena can compel ciphertext and audit metadata; it cannot compel plaintext, because we do not possess it.

Recovery is Shamir 3-of-5 social recovery. At onboarding the user nominates five trusted parties and the Master Root Key is split into five shares with a threshold of three; any three reconstruct it. GuardKin stores only share indices and shareholder hashes plus encrypted labels — never the share bytes, and never enough to reconstruct anything alone. Shares are ceremony-bound with an HMAC tag so shares from different or tampered ceremonies fail to combine. This is a recovery path that routes around the user, not a back door that routes around the architecture: GuardKin still cannot decrypt content on its own.

Because the architecture is honestly zero-knowledge, some responsibility sits with the customer (per the customer-controls / CUEC document): enable MFA (hardware key preferred), treat the master password and Secret Key as two distinct secrets and do not lose either, and distribute Shamir shares only to parties you genuinely trust. Device-resident malware that reads the browser during decryption is the customer’s threat to manage — it is the one adversary the server-side architecture cannot neutralize, and we state that plainly rather than imply otherwise.