Security & trust model
What the coordinator sees, what receipts prove, and what they don’t.Malibu is a cooperative-trust network. Cryptography protects specific boundaries. This page sets out what each participant sees and what a signed receipt does and does not prove.
What the coordinator sees
Prompts and responses pass through the gateway and coordinator so they can be routed and metered. Model weights stay on the provider Mac and never leave it. Buyer prompts and model outputs are processed as plaintext on provider hardware, so providers can technically see the prompts and outputs that pass through their Mac. That fits cooperative deployments where buyer and provider already trust each other. It is NOT a private-inference guarantee. Encryption that hides request bodies from the relay (relay-blind request encryption) has been built but is default-off and not enabled in production. Thetier1_disclosure.plaintext_to_provider field in GET /v1/models reports the live state. See Trust disclosure.
What a valid receipt proves
A signed receipt proves that:- a holder of the provider’s receipt signing key signed a canonical tuple that binds the request, the output and the provider’s reported model hash;
- for settlement receipts, the tuple also binds the request id, attempt, usage counts, and the catalog and route snapshot the coordinator used when it routed the request.
What it does NOT prove
- Honest computation. The model hash is reported by the provider. A provider that falsifies its own loaded-model hash, or runs a different computation, can still produce a receipt that verifies.
- Hardware or binary integrity. Receipts are not hardware attestation or runtime-binary attestation.
- Timestamp honesty. Timestamps come from the provider’s clock.
- Privacy. Receipts do not hide prompt content from the provider or the coordinator.
- Safe output. Receipts do not stop harmful or malicious output.
- Independence from the coordinator. Provider receipt keys are held by Malibu’s coordinator and are not exposed on
api.malibu.tech, so a compromised coordinator changes the trust root.
Buyer-side validation obligation
For tool-calling responses, the returnedtool_calls[] are model output, not intent the provider has checked. Buyer-side agent frameworks MUST validate them before running anything. Malibu passes through the parsed OpenAI-compatible shape. It does not decide whether a requested tool name or argument payload is safe under your agent policy. Treat tool calls with the same caution you would apply to a model running on your own hardware.
See Agentic tooling → Buyer-side validation.
Transport
- Provider ↔ coordinator. Outbound WSS; TLS is terminated at the coordinator edge. The provider authenticates with a bearer
provider_token. No inbound port on the provider. See Transport. - Buyer ↔ gateway. HTTPS to
api.malibu.tech, with API-key bearer auth. - Provider receipt keys. Ed25519. After a rotation, the previous key stays valid for a 7-day grace window.
Provider onboarding
Production requires provider tokens for normal reconnects. A new provisional install may connect once without a token so it can mint and persist its ownprovider_token. Every later reconnect needs that token. See Transport → Token gates.