Home · docs · threat model
Threat model
Umbra assumes the provider owns the Mac, has root, and may be actively hostile to prompt privacy. The product promise is that prompts and outputs are not logged or persisted, inference runs in-process, and trust comes from attestation rather than operator promises.
Actors
Answer: Four actors matter: the buyer (protected prompts), the coordinator (routes and meters from a confidential VM), the provider (adversarial Mac owner running public GGUF models), and Apple (trusted for Secure Enclave, SIP, and Managed Device Attestation).
Consumer
Sends prompts; authenticated non-self routing requires
code_attestedproviders and fails closed when none qualify. Their data is the protected asset.Coordinator
Routes, meters, and verifies providers from an attested confidential VM.
Provider
Runs public GGUF models on Apple Silicon. Assumed adversarial with physical custody.
Apple
Trusted for Secure Enclave keys, SIP, Hardened Runtime, Managed Device Attestation, and the APNs app-targeted challenge used for running-code identity.
Access Paths
Answer: Umbra defends debugger attachment with Hardened Runtime, blocks local inference interception by linking llama.cpp in-process (no socket server), pins model digests in the catalog, and treats provider logging of prompts as a P0 bug with memory-only buffers.
| Attack vector | Defense |
|---|---|
| Debugger or memory reader | Hardened Runtime, no get-task-allow, and startup anti-debug checks. |
| Intercept local inference traffic | No local inference server, socket, subprocess, or IPC: libllama is linked in-process. |
| Modified provider binary | Code signing, SIP, MDA, and a live APNs app-targeted nonce challenge. MDA-only providers remain at hardware; a successful app challenge reaches code_attested. |
| Fake model weights | Catalog entries pin the public repo, revision, quant, and GGUF SHA-256 digest. |
| Provider logs prompts | Prompt/output buffers are memory-only and zeroized after each request; logging them is a P0 bug. |
Trust Tiers
Answer: Trust tiers run from none and self_signed up to hardware and code_attested. MDA evidence alone reaches hardware; authenticated buyer routing requires the independent code_attested layer and returns unavailable below it.
| Tier | Guarantee |
|---|---|
none | No provider hardware proof. |
self_signed | Secure Enclave signed blob only. |
hardware | Secure Enclave identity, Apple MDA chain, five-minute signed-blob freshness, serial binding, and prompt-key binding. |
code_attested | Apple MDA evidence plus a successful APNs app-targeted nonce challenge proving the genuine provider app can receive and answer it. Live for admitted providers. |
For authenticated non-self traffic, code_attested is a hard floor. The trust_level field can request an equal or stronger tier, but cannot opt a private buyer request down to weaker public-provider routing.
Residual Risk
The model excludes unpatched kernel or Secure Enclave vulnerabilities, Apple attestation CA compromise, and destructive physical memory probing. Those are explicit assumptions rather than hidden guarantees.
The implementation details live in umbra/docs/threat-model.md, umbra/docs/SPEC.md, and the provider/coordinator attestation code. This page is the routable web summary.
Frequently asked questions
What does the Umbra threat model assume about providers?
Umbra assumes the Mac owner has physical custody, root access, and may be actively hostile. The product goal is that prompts and outputs are not logged, inference runs in-process, and hardware attestation backs the privacy boundary rather than operator promises.
What data is protected in Umbra v0.4?
Buyer prompts and generated outputs are the protected assets. Public GGUF model weights are not secret. Device-bound serving statements prove which model digest ran, but the prompt text itself is what attestation and encryption protect.
What trust tier does Umbra route to by default?
Authenticated buyer traffic to non-self providers requires code_attested trust. A lower trust_level request cannot weaken that floor; the coordinator returns unavailable when no qualifying provider exists.
Can the coordinator operator read prompts?
The design goal is no: the coordinator runs in an AMD SEV-SNP confidential VM so operator RAM snapshots should not reveal prompts in flight. Current evidence covers coordinator posture and provider registration; signed per-response receipts are still pending.
What risks remain outside the model?
Residual risks include unpatched kernel or Secure Enclave vulnerabilities, compromise of Apple attestation CAs, and destructive physical memory probing. These are documented assumptions, not hidden guarantees.