# ArcaKey Private AI — Threat Model

**Version:** 0.1
**Date:** 2026-04-18
**Status:** Public draft. Companion to the cryptographic whitepaper.

---

## 1. Scope

This threat model specifies the adversaries ArcaKey is designed to defend against, the assumptions on which those defenses rest, and — critically — the adversaries it is *not* designed to defend against. A customer whose real adversary is in the second category should not rely on ArcaKey alone.

## 2. Assets

1. **User content in transit** — the prompts and files a user sends; the responses streamed back.
2. **User content at rest** — encrypted memories, documents, and conversation summaries in the vault.
3. **User-held keys** — passphrases, FIDO2 tokens, derived data encryption keys.
4. **Attestation evidence** — signed NRAS reports binding a session to a verified TEE enclave.
5. **Audit log integrity** — the signed, chained record of all vault operations.
6. **Billing metadata** — user, tier, token usage, timestamp. Intentionally *not* protected as content; needed to operate the business.

## 3. In-scope adversaries

**A1. Honest-but-curious ArcaKey operator.** An ArcaKey employee with production credentials who reads user content out of curiosity, commercial interest, or under management pressure. Defenses: TEE isolation (operator cannot read process memory), Phase 2 end-to-end-to-enclave (Sovereign; operator is cryptographically excluded from the plaintext path), Ghost Mode (no persistent content to read), signed audit log (any access creates an attributable record).

**A2. Network adversary with store-and-decrypt capability.** An adversary who captures TLS traffic today with the intention of decrypting it in the future — whether by future cryptanalysis, subpoena of a CA, or quantum advance. Defenses: hybrid classical-plus-postquantum key agreement (ML-KEM-768 alongside X25519) so that breaking either primitive alone does not yield plaintext.

**A3. Compromise of the ArcaKey application server.** An attacker who gains root on a production application server, whether through a vulnerability in our code, a supply-chain compromise, or a malicious insider with infrastructure access. Defenses: TEE isolation separates the plaintext-bearing inference runtime from the application server; Phase 2 removes the application server from the key-exchange path entirely; zeroized in-memory session keys limit the window of opportunity to the lifetime of an active session.

**A4. Subpoena-compelled disclosure of operational logs.** Legal process compelling ArcaKey to produce logs, backups, or records that would reveal user content. Defenses: we structurally cannot produce what we do not have. Ghost Mode emits no content. Permanent Vault stores only ciphertext wrapped under user-held keys we cannot decrypt. Our subpoena response policy (see /security page) commits to producing only metadata we demonstrably retain, and to notifying the user where the law permits.

**A5. Malicious or compromised infrastructure provider.** A cloud provider operator or a compromised hypervisor reading VM memory. Defenses: AMD SEV-SNP encrypts VM memory against the hypervisor; NVIDIA H100 CC-mode encrypts GPU memory and CPU-GPU traffic; NRAS attestation verifies that the workload we expect is what is running and that CC-mode is active. Failure of attestation rejects the inference request.

**A6. Response tampering on the wire.** An adversary who modifies response chunks in transit to mislead the user — a particularly important threat for AI output where the user may act on the response. Defenses: ML-DSA-65 signatures on every response chunk, verified client-side before rendering. Unsigned or badly signed chunks are rejected, not displayed.

## 4. Out-of-scope adversaries

We state these explicitly so customers do not assume protection we do not provide.

**O1. Compromise of the user's own device.** Keyloggers, clipboard readers, screen scrapers, or any malware with local privileges on the user's client. Client-side encryption is rendered moot if the attacker is already inside the client. Customers whose realistic adversary is a device-level implant (nation-state targeting, for example) must combine ArcaKey with a hardened endpoint posture — we can advise on configuration but the defense is not cryptographic.

**O2. Physical coercion.** The five-dollar-wrench attack. If the user is compelled to unlock their vault in person, the vault will unlock. This is a limit of any consent-based cryptographic system and not specific to ArcaKey.

**O3. Long-lived compromise of NVIDIA's root of trust.** If an adversary compromises NVIDIA's attestation signing infrastructure at the root, the attestation chain is broken. We mitigate by following NVIDIA's revocation feeds and by failing closed on any attestation that does not verify. We do not re-implement NVIDIA's cryptographic root.

**O4. Cryptanalysis of AES-256, SHA-2, or Argon2.** These primitives are assumed cryptographically sound per the current state of the art in 2026. Targeted break of AES-256 or SHA-2 would compromise essentially every cryptosystem deployed today, not merely ArcaKey.

**O5. Social engineering of the user directly.** An attacker who convinces the user to paste their own sensitive content into a malicious channel masquerading as ArcaKey. We mitigate with unambiguous TLS indicators, a verifiable attestation UI, and an explicit "your data is private here" product frame — but we cannot prevent a convinced user from exporting their own data.

**O6. Loss of user-held keys.** Our guarantee that user-held keys mean we cannot read your data cuts both ways: if you lose your passphrase *and* any hardware backup token, we cannot recover your data. This is a documented property, not a defect.

## 5. Trust assumptions

The system's security rests on the following trust assumptions, in decreasing order of how tolerable a violation would be.

1. NVIDIA's NRAS root of trust is intact. A violation would compromise attestation for every confidential-GPU workload across the industry, not merely ArcaKey.
2. AMD SEV-SNP provides the memory-encryption guarantees specified in its manual. Independent research has not demonstrated a practical break at the time of this writing.
3. Our cryptographic library dependencies (`@noble/post-quantum`, `argon2`, Node's WebCrypto) match their specifications. `@noble/post-quantum` is publicly audited; `argon2` is a reference implementation; WebCrypto is widely scrutinized.
4. GCP's confidential-VM orchestration layer correctly provisions CC-mode. Attestation verification is our control: if CC-mode is not actually active, attestation fails and the session is rejected.
5. The user's device is not compromised at the time of session establishment. This assumption is acknowledged as out-of-scope and must be managed by the customer.

## 6. Defense-in-depth summary

| Threat | Primary defense | Secondary defense | Detection |
|---|---|---|---|
| A1 — curious operator | TEE + Phase 2 | Signed audit log | Access entries in audit export |
| A2 — harvest-now-decrypt-later | Hybrid PQ key agreement | Forward secrecy on session keys | N/A (preventive) |
| A3 — app-server compromise | TEE isolation + Phase 2 | Session-key zeroization | Attestation failure alarms |
| A4 — subpoena | No-content-retained architecture | Subpoena response policy | Legal process notification |
| A5 — infra-provider compromise | AMD SEV-SNP + H100 CC-mode | Attestation-before-inference gate | Attestation verification failure |
| A6 — response tampering | ML-DSA signed chunks | Client-side verification | Signature verification failure |

## 7. Change log

- **v0.1 (2026-04-18):** Initial public draft.

---

**Contact for threat-model questions:** `security@arcakey.ai`