Security model

What this page covers

This is a summary of the controls in the current release, written for users and contributors. It is not a certification, an audit report, or a guarantee. Every service carries some risk, and this page does not claim that a request cannot fail or be exposed.

Trust model

The control plane is operated by [LEGAL ENTITY NAME]. Workers are independent PCs run by contributors. Users and workers do not trust each other. A worker receives prompt text and intermediate inference data, so it can read what it processes. Transport encryption protects data in transit; it does not hide data from the machine at the other end.

Access control

• User API keys. One key per account. The full secret is shown once; the control plane stores a peppered hash and a short display prefix. Revoked, expired, or inactive-user keys return 401.
• Worker credentials. A one-time enrollment token is exchanged for a short-lived session JWT plus a rotating refresh token. Worker routes require the session token and reject user API keys.
• Invites. Access is reviewed manually. There is no public signup, login, key-creation, or installer download.
• Operator access. Administrative worker endpoints require a separate admin token, configured on the server and not issued through the public site.

Worker identity and signatures

Each install generates an Ed25519 device keypair and registers the public key during enrollment. Only the public key leaves the contributor’s PC. Signing worker challenges with the device key is planned; it is not a live control in this release. Current worker authentication is the session JWT issued after enrollment, and revocation takes effect on the next authenticated call.

Model manifests are signed and verified, and model artifacts are checked against their SHA-256 digests before the worker loads them. Installer and update code-signing are planned, not live. The current installer is not code-signed, so verify that the file came from the operator before running it.

Prompts and completion data

Prompt text is not written to Postgres or application logs by default. For a worker-executed job, the gateway holds the prompt briefly in Redis, encrypted at rest in the hosted service, and deletes the hold when the job settles. Completion chunks travel through a per-job Redis stream, and the stream is deleted when the job settles. Logs redact authorization headers, prompts, and message bodies; route errors log job IDs and error codes, not prompt text.

A worker must receive the prompt to run it, so the assigned worker can inspect prompt and intermediate inference data. This is not end-to-end confidential inference. Treat prompts as visible to the machine that processes them.

Checks on worker output

After a completed job, the gateway samples a share of single-stage jobs for re-execution on a second worker. The source worker is excluded from that shadow job. Outputs are compared by word agreement after whitespace normalization; a token-count ratio below 0.90 or word agreement below 0.95 records a mismatch. A worker with at least three mismatches and at least half of its verdicts mismatched is quarantined from new placements, pending operator review.

Verification runs after delivery, so the user’s answer is not held for it. It catches some bad output; it does not prevent every bad answer, and it is weaker against colluding workers. Non-deterministic backends are recorded as inconclusive and do not penalize the worker. An operator can release a quarantine after review.

Public status and data minimisation

When the public status page launches, it will expose aggregate counts and timing only: active and total workers, models, jobs, tokens, components, and per-model latency. It will not expose worker IDs, IP addresses, regions, prompts, emails, or user IDs. Quarantined workers will be excluded from public capacity. A reachable service with zero active workers will be reported as degraded, never operational.

This site uses no analytics or tracking cookies. When the waitlist opens, its data will be limited to the fields described in the privacy notice.

Planned, not live

• Signed Windows installer and signed application updates.
• Challenge signing with each worker’s registered device key.
• Redundant execution and trusted-only execution modes.
• Broader sandbox and platform security review.
• A published incident-response and notification procedure.

These controls are in the design or on the roadmap. Do not assume they protect a request today.

Reporting a vulnerability

Email [SECURITY CONTACT EMAIL] with the affected endpoint or component, the steps to reproduce, and the impact. Do not include real prompts, API keys, or personal data. Do not test against other people’s accounts or workers.

The operator will triage reports during [SUPPORT WINDOW]. This draft does not promise a response time or a reward.

Changes

This page will change as controls are added. The effective date is [EFFECTIVE DATE]. [MATERIAL-CHANGE NOTICE PROCESS TO BE COMPLETED BY THE OPERATOR.]