CommonCompute
Get startedExplore workloads
Security — Trust model

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

Common Compute is a marketplace: the machine that executes your job is a Mac computer with Apple silicon owned and operated by an independent provider — not a server in a datacenter we control. That architecture is why the prices are what they are, and it has real confidentiality consequences. This page lays out what is protected today, what is not yet, and what you should (and shouldn't) send during beta.

What is protected today

The pipe, the dispatch, and the economics.

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.

What is not protected yet

The assigned provider sees your input in plaintext.

Job inputs are not end-to-end encrypted to the provider. To execute your task, the assigned computer must decrypt and process the actual input — the prompt, the audio file, the image, the document. A provider who modified their machine could read, copy, or exfiltrate the inputs of jobs assigned to them, and no cryptographic control currently prevents that.

What limits the blast radius today: providers can't pick whose jobs they receive, inputs are size-capped and pseudonymous, retention is short, and the verification and payout machinery makes operating a dishonest node costly. What doesn't exist yet: payload encryption to an attested per-device provider key, and data-classification routing that keeps sensitive jobs on higher-trust hardware. Both are on the roadmap; neither has shipped. We will update this page when that changes.

If your threat model can't accept a third-party machine seeing job inputs, don't send that workload yet. That's the honest answer.

What to send during beta

Match the data class to the trust model.

Good fit
Public or low-sensitivity data: published documents, marketing assets, open datasets, product imagery, podcast audio, code you'd push to a public repo. This is what the network is built for today.
Think first
Internal business data. Strip or pseudonymize identifiers before submission and use only workloads shown in the live catalog. Use the API's data controls: short retention is the default, and deletion on request is honored.
Don't send (yet)
Regulated or PII-heavy data: health records (HIPAA), payment card data (PCI), government-classified material, or anything containing credentials and secrets. Until payload encryption to attested provider keys ships, this data does not belong on the beta network.

Questions about whether your workload fits?

Ask before you send — we'll tell you straight if the trust model isn't there yet for your data.

contact@commoncompute.aiBack to the security overview