Terms, in plain English.
Umbra's trust and attestation docs use a lot of security and inference jargon. Here is what each term means and why it matters for private-prompt inference.
- Secure Enclave
- A dedicated security chip inside Apple Silicon. It generates and holds a private key that never leaves the chip, not even to main memory (RAM). An Umbra provider signs its registration with a Secure Enclave key, which is how the coordinator knows the request comes from genuine, hardware-bound identity rather than copied credentials.
- Apple MDA (Managed Device Attestation)
- An Apple mechanism where the device, through an MDM profile, produces Apple-signed evidence about its own security state (serial number, SepOS, SIP, Secure Boot). Because the operating system reports this, not the provider's own software, it can catch a provider that is lying about its posture. Umbra uses MDA-over-MDM as its operative hardware-trust anchor.
- SEV-SNP
- AMD's confidential-computing technology (Secure Encrypted Virtualization – Secure Nested Paging). It runs a virtual machine with its memory encrypted from the cloud operator, and lets that VM prove which image it is running. Umbra's coordinator runs inside a SEV-SNP confidential VM, so neither the cloud provider nor Umbra-the-company can read the coordinator's memory while it routes and meters requests.
- X.509 chain
- The standard format for digital certificates and the "chain" that links one certificate to the next up to a trusted root authority. Umbra validates the Apple MDA evidence against a chain that ends at the Apple Enterprise Attestation Root CA, which is how it confirms the attestation was really signed by Apple and not forged.
- Attestation
- Cryptographic proof about the state of a machine, rather than a promise. Instead of trusting "we don't log your prompts," attestation lets the system verify the hardware and software boundary that handled a request. Umbra's goal is that you do not have to trust the machine owner: the hardware attests to the lockdown.
- Trust level: hardware
- The current maximum trust tier a real Umbra provider reaches. It means the provider passed Secure Enclave identity, Apple MDA chain validation, five-minute signed-blob freshness, serial binding, and binding of the prompt-encryption key to the signed blob. It proves the machine is genuine Apple Silicon in a verified posture.
- Trust level: code_attested
- A stronger live tier than hardware that adds an independent proof of the running code's identity via an APNs app-targeted nonce challenge: only the genuine entitled provider app can receive and answer it. MDA-only providers remain at hardware; authenticated private routing fails closed below code_attested.
- GGUF
- The file format used to package quantized open-weight models for efficient local inference. Every model in Umbra's catalog is a public GGUF pulled from Hugging Face. Each catalog entry pins a GGUF SHA-256 digest so the exact file can be verified at request time.
- llama.cpp
- The inference engine Umbra uses to run models. It is linked directly into the provider binary (as libllama) and called in-process, with no separate inference server, socket, or IPC, which is what lets Umbra close the software paths an adversarial machine owner could use to read a prompt from memory.
- NaCl box
- A well-established public-key authenticated-encryption scheme (from the NaCl / libsodium library). Umbra uses it to seal a prompt to a specific recipient's key: the consumer's request is sealed to the coordinator, then re-sealed to the individual provider's attested X25519 key, with a fresh ephemeral key per request for forward secrecy.
- Quantization (quant)
- Compressing a model's weights to smaller numeric precision (for example Q4) so it fits in less memory and runs faster, at a small quality cost. The catalog lists each model's quant alongside its minimum unified-memory requirement.
- SIP (System Integrity Protection)
- A macOS protection that prevents even the root user from modifying protected system files or loading unsigned kernel extensions. Disabling it requires a reboot into Recovery mode, which would terminate a running provider, so a single start-time SIP check covers the whole request lifetime.
Back to the trust model, the attestation spec, or the threat model.