Architectural commitments. Not aspirational.
GuardKin stores some of the most sensitive information families possess. The protections below are not policy preferences — they are properties of how the system is built. They cannot be relaxed for a single firm contract or a single regulatory request.
- ✓Zero-knowledge for sensitive content
- ✓Metadata / content boundary, enforced cryptographically
- ✓No key-escrow back door to subpoena
advisor-shareable · the server can read this
a7f3…e201 · the server holds no key
What the server can read, and what it never can.
One vault item leaves your device as two sealed records. Both cross the same wire into the same database row — but only one is something the server can open. The other is ciphertext it holds no key for. The split is enforced by the data model, not by an access policy a bug could defeat. Scroll to watch it happen.
How one vault item becomes two sealed records — and why the server can read only one
A single vault item leaves your device as two separately sealed records. The metadata record is encrypted with a key you wrap to your advisor under your consent, so the server can present it to an authorized advisor. The content record is encrypted with a key the server has never held. Both records cross the same connection into the same database row, but the server can read only the metadata record. For the content record it holds ciphertext it has no key to open. The content key derives only on your device, where your two secrets meet; a subpoena to GuardKin resolves to noise.
If we are subpoenaed, we hand over ciphertext. If the advisor dashboard has a bug, it can leak only what the client consented to share — never content. Read the full architecture
Who holds which key — and why nobody can quietly hold yours.
Two secrets only you control are combined with a per-user salt to derive your keys. Recovery reconstructs your Secret Key from shares you pre-authorized — it never reconstructs a key GuardKin could use alone. There is no key-escrow back door to subpoena, misuse, or leak.
See the full derivation — three inputs through Argon2id to a Master Key, branching into independent content and metadata root keys — on the architecture page
This page is the architecture. The Trust Center is the paperwork.
The nine architectural commitments, the framework-status badges, the 17-vendor subprocessor register, the document library, and the independent cryptography-review status all live in the Trust Center — the surface your procurement team self-serves.
Trust Center: compliance status, documents, subprocessorsWhere data lives, how long it stays, how it leaves.
Concrete answers, by data category. Content is held as ciphertext we cannot read, so “deletion” for content means destroying a blob that was never legible to us. Windows are maximums; most happen sooner.
| Data category | Residency | Retention | Deletion | Export |
|---|---|---|---|---|
| Vault content (zero-knowledge) | us-east · us-west | until you delete | ciphertext purged ≤ 30d; we delete what we could never read | anytime · encrypted blob + keys |
| Vault metadata (consent-scoped) | us-east · us-west | until you delete | purged ≤ 30d of account closure | anytime · JSON |
| Account & identity (name, email) | United States | life of account | ≤ 30d; legal/tax minimum may persist (disclosed) | anytime · JSON |
| Advisor / firm linkage records | United States | life of relationship | unlinked immediately on your request; keys rotated | included in account export |
| Audit log (security events) | United States | hot 90d (Axiom) · cold WORM 7y (S3 Object Lock) | immutable in cold tier; tamper-evident chain; survives wind-down | your own entries on request |
| Backups & snapshots | same region as source | 35 days, rolling | deletions propagate; aged out ≤ 35d | n/a — restore only |
| Operational telemetry (scrubbed) | United States | 30–90 days | PII scrubbed at ingestion; auto-expired | n/a |
| UK / EU client data | eu-region · at UK/EU launch | as above, per category | GDPR erasure honored ≤ 30d | GDPR portability · machine-readable |
Export Guarantee (commitment #7): your data is portable at any time, regardless of subscription status or firm relationship. Region pinning is enforced at the storage layer.
What happens when something goes wrong — and if we don’t make it.
Operational commitments first; then the provisions that keep your family’s access alive even if GuardKin does not. The response, recovery, and backup figures are design targets, measured from GA and reported in the annual transparency report — not retroactive uptime claims. Breach notification (≤ 72h) is a legal commitment, not a target.
| Control | Commitment | Target |
|---|---|---|
| Breach notification | Affected users and firms notified directly, in plain languageLegal commitment (GDPR Art. 33/34) — honest disclosure even when the news is bad. | ≤ 72h |
| Critical incident — first response | On-call engineer engaged; status page updated | Target P1 · 15 min |
| High / Medium / Low triage | Acknowledged and triaged on a severity ladder | Target P2 1h · P3 1d · P4 5d |
| Recovery objectives | Restore service / bound data loss after a disaster | Target RTO 4h · RPO 1h |
| Backups | Encrypted, cross-AZ, continuously verifiedPoint-in-time restore; restores rehearsed, not assumed. | Target 35d · PITR |
| DR exercise | Full failover + restore drill, findings logged | Annual |
| Independent penetration test | Third-party test of app, infra, and the crypto boundary | Annual + on major change |
| Vulnerability disclosure | Published channel, scope, and safe-harbor terms | security.txt |
| SOC 2 attestation | Type II — actively in preparationOn track for the next 4–6 months. Status shown honestly — pre-certification, never a report before it is issued. | Targeted Q4 2026 |
If the company does not survive, your family’s access does.
Commitment #8, made concrete. Three escrows held by three separate parties, plus a funded wind-down — so no failure of GuardKin, and no single custodian, can strand the archive.
Source code escrow
The client and server source is held by an independent escrow agent and released on defined trigger events.
escrow · third-party agent
Encrypted data custodian
Your encrypted data has a designated custodian, separate from the source escrow, so the archive survives the company.
custodian · separate party
Key material escrow
Key material is escrowed separately again — never co-located with the source or the data, so no single party can reconstruct access.
kept separate · no single point
12-month insured wind-down
A minimum 12-month wind-down is contractually funded and insurance-backed, so families keep access and export while they transition.
≥ 12 months · insurance-backed
The boundary holds for the AI, too.
GuardKin uses AI to make estate work less overwhelming — not to read your secrets. The model is a subprocessor that sits outside the content boundary. It never holds a key, and the server has nothing to give it but consent-scoped metadata and the words you write into a prompt.
- Provider
- Anthropic · Claude API
- Retention
- zero-retention tier
- Training
- excluded · contractual
- Sees
- metadata + your prompt only
Does the AI ever see zero-knowledge content?
No. The server has no key to decrypt content, so it cannot pass content to any model. The AI sees only consent-scoped metadata and text you author into a prompt.
Which model provider, and on what terms?
Anthropic (Claude API) on a zero-data-retention tier. Prompts and completions are not stored by the provider after the response is returned.
Is our data used to train models?
No. Requests are contractually excluded from training — GuardKin’s and the provider’s. Not for fine-tuning, not for evaluation sets.
Where does inference run, and is it a subprocessor?
In the United States, under a DPA. The model is a named subprocessor in the register, scoped to internal · redacted-confidential data — never restricted vault content.
Can the AI take actions on the vault?
No. It drafts and suggests within the consent boundary. It holds no keys and cannot read, decrypt, or move content.