TLS in transit
Every hop — your client to our API, our coordinator to the provider's Mac computer, results back out — is TLS 1.2+. Nothing crosses the public internet in the clear.
Signed task envelopes (Ed25519)
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 computer or impersonate the router.
Providers can't choose whose jobs they run
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.
Storage and size caps
Inputs and results are staged in Cloudflare R2 under per-task keys. Inputs for terminal jobs become eligible for an early purge after a one-hour grace period. A separate sweep deletes stored task artifacts after 30 days, and a customer can request earlier deletion for a final job with DELETE /v1/jobs/{id}/data. These are outer operational controls, not a guarantee of immediate deletion. Per-workload input size caps bound what any single task can carry to a provider machine. Shortening storage time does not change the execution boundary: the assigned provider sees the input in plaintext while running it.
Restricting who can run a job
Before a payload-bearing marketplace job runs, the customer must explicitly acknowledge that an independently operated provider Mac computer can receive plaintext needed to execute it. We persist the current notice version and timestamp on the job and include it in its signed receipt. At authenticated completion, that receipt also captures the pseudonymous executing device's trust state, score, evaluation time, vetting time, integrity score, and the concrete process boundary that handled task plaintext; a sharded job reports a bounded summary for every completed child execution. Those are marketplace accountability records, not an attestation that the provider computer could not read the payload. data_class is the customer's sensitivity label for that evidence; neither 'public' nor 'confidential' makes a third-party provider computer blind. Device integrity screening, automated trust evaluation, quarantine, and payout holds apply to every job. A private-fleet or confidential-compute offering will be a separate execution mode with separate guarantees.
Result checks, reputation, and payout controls
The platform includes golden-task checks, keyed replication sampling, integrity scoring, quarantine, and payout-hold mechanisms. Their observed frequency and fleet coverage can vary, so they should be treated as layered detection controls rather than a continuous-verification guarantee. A failed check can reduce eligibility or hold payout when the configured policy and evidence thresholds are met. Two honest limits: canary inputs can come from a fixed fixture set that a device might recognise, and a provider can decline categories of work without penalty. Neither lets a provider pick a customer.
A locked-down provider app
The macOS app runs under Apple's hardened runtime, is App-Sandboxed, and ships Developer ID signed, notarized, and stapled. It declares the outbound network-client entitlement but no server entitlement; its isolated XPC compute service is separately App-Sandboxed and declares no network entitlement. The app opens no listeners anywhere in its source. Job inputs can't reach private network addresses — every fetch goes through a gate that refuses non-public hosts even across redirects. App Sandbox limits filesystem and network capabilities; it does not make plaintext assigned work invisible to the provider. Providers never see your account identity — tasks arrive pseudonymous.
The verification design — golden tasks, replication sampling, reliability scoring, and payout controls — is documented in our result-verification spec. These mechanisms improve detection and accountability; they do not make dishonest execution mathematically impossible or establish that every production job was independently replicated.