Your jobs run on other people's Macs. Here's exactly what that means.

Every hop — your client to our API, our coordinator to the provider's Mac, results back out — is TLS 1.2+. Nothing crosses the public internet in the clear.

Each task assignment is signed by the coordinator with Ed25519. Provider machines verify against a pinned public key, with a 5-minute clock-skew window and replay protection, and refuse anything that doesn't verify. A third party can't inject work into a provider's Mac or impersonate the router.

Dispatch is platform-controlled and push-only. There is no endpoint a provider can poll to browse the queue or request a specific task, and the assignment carries no customer identity, so targeting a particular customer is not something a provider can arrange. What a provider can do is switch off whole categories of work — by workload, by model, by priority tier — and those declines carry no penalty.

Inputs and results are staged in Cloudflare R2 under per-task keys. A job's input is deleted when the job settles — seconds, not days — because nothing reads it again once the task is terminal; a sweep every 15 minutes is the backstop for anything the fast path missed. Results are kept until the 30-day sweep, since you still have to fetch them, and either can be deleted on demand with DELETE /v1/jobs/{id}/data. Per-workload input size caps bound what any single task can carry to a provider machine. Worth being clear about what this does and does not buy: shortening the window reduces how long a payload is sitting somewhere it could leak from. It does nothing about the assigned provider, who sees the input in plaintext while running it.

Jobs may be submitted with data_class: 'confidential', which routes them only to providers flagged as vetted. It is a hard filter applied before scoring, not a preference: if no vetted provider is available the job waits and then fails saying so, rather than falling back to the open marketplace. Vetting is granted manually and audit-logged, and nothing a machine reports about itself can earn it — the flag asserts something about the operator, not the hardware. Two honest limits. First, this is a supply-chain control rather than a cryptographic one: it narrows who the provider can be, and the assigned provider still decrypts your payload to run it. Second, we are not yet running a standing vetted pool, so confidential capacity is arranged per customer — talk to us before sending traffic with this flag, or it will queue and then fail rather than run.

Providers are continuously tested with golden tasks — canaries with known answers, dispatched through the same path as customer work and carrying byte-identical requirements — plus replication sampling on a slice of standard jobs, sampled with a keyed hash so a device can't predict when it's being watched. A golden failure freezes that device's payouts immediately and counts against an integrity score that gates whether it is paid at all; enough of them push it out of customer dispatch. Earnings only become payable after a verified track record. Two honest limits: our canary inputs are drawn from a fixed fixture set today, so a device that has seen one could in principle recognise it again, and a provider can decline categories of work without penalty. Neither lets a provider pick a customer.

The Mac app runs under Apple's hardened runtime with an outbound-only network entitlement, and ships Developer ID signed, notarized, and stapled. It declares no server entitlement and opens no listeners anywhere in its source — though since it is not App-Sandboxed, that is a property of how we wrote it rather than one the OS enforces. Job inputs can't reach private network addresses — every fetch goes through a gate that refuses non-public hosts even across redirects. It is not App-Sandboxed today, so treat file-system containment as a hardening item we still owe you, not a guarantee. Providers never see your account identity — tasks arrive pseudonymous.