Security

Secure Mode & the Confidential tier

A co/core provider can carry two independent security postures. They answer different questions and are earned separately — you can have either, both, or neither. This page explains what each one aims to show, how it works, and what it means for the prompts you send (as a requestor) or serve (as an operator). Both are experimental and not independently audited yet — the note below says what that means in practice.

Confidential mode is experimentalIt aims to keep your prompt unreadable to the machine's operator: a trusted brokerage routes your job to genuine Apple hardware running a known build under a hardened runtime, with the agent's signing and prompt-decryption keys held in the Secure Enclave so the operator can't copy them to another machine, and the receipt is countersigned to prove that machine served it. But it's a raised bar, not a hardware guarantee — Apple Silicon has a secure enclave for keys but not for general compute, so a compromised OS kernel or someone with physical access to the machine could still read your prompt while it's being processed. Don't send anything you'd need cryptographically kept private. Hardware attestation, which the confidential tier builds on, is experimental in the same way: a best-effort signal, not a verified guarantee.

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 attest its hardware and still run inference somewhere its operator can read, or aim to seal inference from its operator without an Apple hardware-root attestation. Neither posture is independently proven — treat both as experimental.

Secure Mode — “this aims to show it's a real Mac”

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 is designed to show the silicon is genuine, the OS is intact, and System Integrity Protection is on. It sets the provider's trust level to hardware-attested. This is experimental: we don't treat the attestation as independently verified, and it may be wrong or worked around in ways we haven't ruled out.

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 — sealing prompts from the machine's operator

This is what the confidential tier aims to give a requestor — though it's experimental and unproven, so don't rely on it for anything you couldn't stand to have exposed. The goal: when you send a prompt to a confidential provider, the machine's own operator has no ordinary, supported way to read it. A best-effort provider runs inference in a helper process the operator controls and can freely 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 stays inside the attested binary, under a hardened runtime with library validation and anti-debugging. The operator's everyday tools for looking inside a running program — reading another process's memory, attaching a debugger, swapping in a logging build — don't reach it.

“Operator” here means the person running the provider machine. If you're an operator reading this in the app: confidential means that you have no ordinary way to read what requestors send you — and that's the point. It's what lets requestors trust your machine with sensitive work.

How it's checked, 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. The agent's signing and prompt-decryption keys are held in the Secure Enclave, so they can't be lifted onto another host — the fix for the 2026-07-05 copy-the-key spoof, where a genuine Mac's software key was copied to a non-Apple box to serve “confidential” traffic. Only when all of that holds does the provider advertise the attested-confidential tier.

What the confidential tier is — and isn't

Be precise about the kind of guarantee this is, because it's easy to overstate. The confidential tier is not a hardware trusted-execution environment (TEE) in the sense of Intel SGX, AMD SEV-SNP, or AWS Nitro Enclaves. Apple's Secure Enclave protects the device's signing keys and produces the attestation, but it does not run the model — your prompt and the model weights execute in ordinary macOS user space and on the GPU, like any other app.

What seals them from the operator is the verified platform-security posture, not memory isolation in silicon: code signing, System Integrity Protection, the hardened runtime, library validation, anti-debugging, disabled core dumps, and the absence of any subprocess or IPC to tap. Under that posture the operator has no ordinary path to the plaintext — but the guarantee still rests on the OS and the signed-binary supply chain being intact. A vulnerability in macOS or in the agent, or a maliciously substituted signed build, could still expose plaintext. So the honest claim is a raised bar, not an absolute: confidential moves the trust from “trust the machine's operator” to “trust Apple's platform security and co/core's measured, signed build” — a meaningful shift, but a different and shallower one than a hardware enclave that isolates memory from the host itself. If you need that stronger property, a hardware-TEE provider is the right tool; the confidential tier is the strongest posture we can reach on stock Apple hardware without one — and, for now, an experimental one.

Why they're independent

Neither — fast best-effort serving: a real-enough machine whose operator can read prompts. Secure Mode only — attested genuine hardware, but inference still runs where the operator can read it. Confidential only — the operator has no ordinary way to 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 inference path the operator can't ordinarily read.

The model constraint for operators

Confidential serving runs in the agent's in-process engine, which only loads certain model architectures — Qwen2 / Qwen3 / Qwen3.5 / Qwen3.6 / Llama / Gemma / Phi / Mistral-class weights. A model outside that set (for example a 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 posture while serving it, even if the machine is otherwise confidential-capable. Pick a confidential-capable model to keep it.

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.