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 tier than hardware that adds an independent proof of the running code's identity, via an APNs app-targeted nonce challenge: only the genuine notarized app can receive the push token needed to answer. It is implemented and tested but goes live only once the operator wires the APNs key and ships the entitlement, so today the verifier caps providers at hardware and 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.