Secure Mode & the Confidential tier
A co/core provider can carry two independent security guarantees. They answer different questions and are earned separately — you can have either, both, or neither. This page explains what each one proves, how it works, and what it means for the prompts you send (as a requestor) or serve (as an operator).
The two are orthogonal
Secure Mode answers “is this genuine, untampered Apple hardware?” The Confidential tier answers “can the machine's operator read the prompts a requestor sends it?” One is about the integrity of the hardware; the other is about who can observe the data. A machine can prove its hardware and still run inference somewhere its operator can read, or seal inference from its operator without an Apple hardware-root proof. The strongest providers carry both.
Secure Mode — “this is a real Mac, provably”
Secure Mode enrolls the Mac with co/core's device management and obtains an Apple Managed Device Attestation certificate chain — an Apple-signed credential rooted in the device's Secure Enclave that proves the silicon is genuine, the OS is intact, and System Integrity Protection is on. It sets the provider's trust level to hardware-attested.
What it defends against: a spoofed or tampered provider — a VM pretending to be a Mac, or a machine with SIP disabled. What it does not say: anything about whether the operator can see your data. A genuine, hardware-attested Mac can still run inference in a process its operator reads. Secure Mode is optional and additive — turning it on never changes how the machine serves, only how strongly it can prove what it is.
The Confidential tier — “the operator can't read the prompts”
This is the guarantee that matters to a requestor: when you send a prompt to a confidential provider, the machine's own operator cannot read it. A best-effort provider runs inference in a helper process the operator controls and could observe. A confidential provider instead runs inference entirely inside the measured, signed co/core agent — the in-process engine, with no subprocess and no IPC to tap — so the plaintext never leaves the attested binary. There is no observation surface for the operator to use.
“Operator” here means the person running the provider machine. If you're an operator reading this in the app: confidential means that you can't read what requestors send you — and that's the point. It's what lets requestors trust your machine with sensitive work.
How it's proven, so a requestor doesn't have to take the operator's word for it: the matchmaker challenges the running agent with an AMFI-gated push that only the genuine, team-signed binary can answer, and the binary's measured code identity (its code-directory hash) must be in the blessed-build set, under a hardened runtime with library validation and verified SIP. Only when all of that holds does the provider advertise the attested-confidential tier.
Why they're independent
Neither — fast best-effort serving: a real-enough machine whose operator can read prompts. Secure Mode only — proven genuine hardware, but inference still runs where the operator can read it. Confidential only — the operator can't read prompts, but you're trusting the code-identity proof without an Apple hardware-root attestation of the silicon. Both — genuine attested hardware and a sealed, operator-blind inference path.
The model constraint for operators
Confidential serving runs in the agent's in-process engine, which only loads certain model architectures — Qwen2 / Qwen3 / Llama / Gemma / Phi / Mistral-class weights. A model outside that set (for example a newer Qwen3.5+, Gemma 4, or Llama 4 architecture) can only be served best-effort, in the readable helper process. The provider app marks each model in the picker as “Confidential ✓” or “Best-effort only”: choosing a best-effort-only model means your machine can't offer requestors the confidential guarantee while serving it, even if the machine is otherwise confidential-capable. Pick a confidential-capable model to keep the guarantee.
Turning them on
Both are controlled from the provider app under Open co/core → Status → Security: Enable Secure Mode runs the device-enrollment wizard, and Enable confidential opts the machine into the attested-confidential tier (the same intent the console's per-machine control writes). The machine then restarts serving to earn the posture; it only advertises the higher tier once actually earned, so opting in never overstates what a machine can prove. For the receipt and lexicon fields these map to, see the lexicon reference.