​
Threat model

Who can cheat, what breaks, and what cryptography actually bounds. Last reviewed: September 2026.
This page complements Security & trust model with a view organized by adversary. It is the canonical list of what could go wrong. The Litepaper stays narrative; this page stays falsifiable.

​
Trust boundaries (summary)

Not in scope today: confidential compute, private inference, and forward-pass honesty (TOPLOC is planned). Hardware attestation exists for a small number of Macs but does not affect routing or settlement (see the matrix below).

​
Adversary catalog

​
A1: lazy, slow or offline provider

Goal: collect routing weight without serving good responses. Mechanism: accept requests, then return garbage, time out, or omit or delay receipts. Mitigations (live):
  • A missing, invalid or late settlement receipt pays the provider nothing (Verified model settlement).
  • A per-provider circuit breaker marks a provider degraded and unroutable after repeated faults in a short window.
  • A throughput floor keeps providers whose estimated throughput is below the production minimum out of dispatch.
  • New providers start provisional, with lower routing weight and an hourly request quota (Reputation).
Residual risk: the buyer loses latency before a fault is detected. There is no automatic quality SLA beyond settlement.

​
A2: receipt forger (wrong key)

Goal: forge receipts without holding the provider’s signing key. Mechanism: re-sign tuples with the attacker’s key, or replay old receipts. Mitigations (live):
  • Ed25519 verification against the provider’s receipt key on record. Settlement receipts name that key by fingerprint (provider_receipt_key_id).
  • Settlement receipts bind request_id and attempt_n, and the coordinator quarantines replayed receipts.
Residual risk: a stolen provider key produces valid-looking receipts until the key is rotated. A compromised coordinator shifts the default trust root.

​
A3: model swap (honest hash, dishonest compute)

Goal: serve from different weights, or shortcut the computation, while advertising a catalog model. Mechanism: report the catalog hash while running a cheaper model or an approximation. Mitigations (live):
  • The coordinator routes only to providers whose reported model hash matches the signed catalog.
  • Settlement receipts bind the reported hash and the route-time catalog snapshot. A mismatch does not settle.
Mitigations (built, not active):
  • Compute-integrity sampling (a sampled distribution-drift check) is built but not active. Buyers see its status as unavailable.
  • Losslessness probes and nonce canaries are implemented but disabled in production.
Mitigations (planned):
  • TOPLOC forward-pass attestation on buyer completions.
Residual risk: the model hash is provider-reported. A malicious provider can falsify its own hash measurement, or run different computation, and still produce receipts that verify. Live receipts do not prove forward-pass fidelity.

​
A4: mine M, serve M′ (mining vs serving divergence)

Goal: mine on a cheap substrate while serving buyers from different hardware or a different model. Mechanism: run the PoMW walk on one weight file and serve inference from another process or machine. Mitigations (planned):
  • The PoMW walk hashes the same canonical weights as the inference catalog.
  • Cooperative scheduler design, so that at v1 mining state approximately equals serving state.
  • TOPLOC ties served output to an attested forward pass.
Residual risk: PoMW is not part of the production provider runtime. The threat is documented; protocol integration is pending.

​
A5: coordinator or gateway compromise

Goal: mis-route traffic, alter billing, or substitute public keys. Mechanism: an attacker controls the coordinator or the gateway’s TLS termination. Mitigations:
  • The verifier accepts an explicit provider public key, bypassing live key resolution. Offline verification of current receipts is pending a verifier update.
  • Model hashes come from a signed static catalog feed.
Residual risk: routing, metering and settlement are coordinator-trusted. v0.4 settlement receipts are verified only by the coordinator today.

​
A6: buyer tool-call injection

Goal: trick an agent runtime into running tools the model suggested. Mechanism: the model emits malicious tool_calls[] and the buyer runs them without validation. Mitigations: Residual risk: outside Malibu’s transport. The buyer’s framework must enforce policy.

​
A7: privacy expectation mismatch

Goal: none. This is a buyer mistake: assuming prompts are private. Mechanism: misreading marketing copy. Prompts cross the gateway, the coordinator and the provider as plaintext. Mitigations:
  • The security page and the Introduction state the cooperative-trust boundary explicitly.
  • GET /v1/models returns tier1_disclosure.plaintext_to_provider: true (Trust disclosure).
  • The Litepaper says “Cooperative trust”, not “Private”.
Residual risk: buyers who need confidential compute must not use Malibu as it stands. Relay-blind request encryption is a default-off pilot.

​
A8: overstated hardware or capacity

Goal: claim more RAM, throughput or serving seats than the Mac has. Mechanism: misreport hardware or benchmark values in heartbeats. Mitigations (live): the throughput floor and the circuit breaker. A Mac that fails requests it accepted can trip the circuit breaker and lose routing. Advertised seat counts themselves are provider-reported. Mitigations (built, not active): a hello-time gate that would require verified hardware evidence before admission is implemented but disabled in production. Residual risk: RAM and hardware profile values are provider-reported, and public capacity figures are labelled as estimates.

​
Verification primitive matrix

​
Reporting

Report security-sensitive findings through GitHub private vulnerability reporting on the relevant repository. Do not attach private prompts, API keys, or receipt bundles to public issues.