Privacy Boundary
Where B3IQ does and does not store prompts, what each layer can see, and the path to verified confidential compute.
B3IQ private inference currently uses encrypted transport. It is private from the B3IQ control plane, gateway, hosted playground, router accounting, billing exports, and public explorer payloads. It is not yet a claim that prompts and outputs are hidden from the node operator.
This page describes what is stored, what each layer in the path can see, and the roadmap to verified confidential compute. We state the current boundary honestly: where a protection is not yet in place, we say so.
Privacy Classes
| Class | Status | Claim |
|---|---|---|
| private_transport | Active | Client encrypts to node transport key. Protects content from B3IQ services and public surfaces, not from the node operator. |
| verified_confidential_cpu | Planned | Requires verified TEE attestation, transport key binding, attestation freshness, and receipt evidence. |
| verified_confidential_gpu | Later | Requires practical confidential GPU hardware, driver stack, and attestation tooling. |
Is Your Content Stored?
The short answer: the public inference path stores no prompt or output. The table below is the complete list of paths and exactly what each one retains.
| Path | Content stored? | Detail |
|---|---|---|
| Public / pooled inference | No | Prompt and output transit memory and stream through, but are never written to a datastore. Only token counts and routing metadata are kept. |
| Private inference (private_transport) | Ciphertext only | Stored encrypted to the node. B3IQ holds no key and cannot decrypt. The encrypted payload is auto-purged after about 30 days; a billing skeleton remains. |
| Node-local playground | Plaintext | Lives only in the operator's own node database, on their own machine. Removed on node uninstall or reset. |
| Hosted playground (dashboard) | Plaintext | Stored server-side for the life of the session so conversation history works. Purged by a scheduled retention sweep after the session expires or is deleted, subject to admin retention controls. |
| Node request logs | Off by default | Raw prompt/response logging is opt-in and off by default. The public and gateway paths are always content-redacted regardless. |
For pooled inference, content flows through control-plane memory and the node runtime but is never persisted on either side. The accounting record holds token counts and routing metadata only — no prompt, no completion text.
Current Baseline
- Private job request bodies must include a
b3iq-private-transport-v1envelope. - The envelope uses an X25519 key exchange to the node transport key with AEAD encryption, so only the target node can open it.
- Streaming responses are protected frame by frame: each frame binds a sequence number and a final-frame flag into its authenticated data, so truncated, reordered, dropped, or replayed frames are detected.
- Extra request fields are rejected before dispatch, so plaintext cannot be smuggled in alongside the ciphertext.
- Private command results store only validated encrypted response envelopes and an optional receipt hash.
- Stored state may contain ciphertext envelopes, job state, usage rows, receipt hashes, and signed receipt commitments.
- Stored state must not contain raw prompts, outputs, customer tokens, local node keys, or router secrets.
- Old terminal ciphertext envelopes can be purged while preserving billing, receipt, and settlement evidence.
What Each Layer Can See
Transport encryption terminates at the routing edge, so for pooled traffic the edge and the control plane are in-path and can see content in memory — they just never store it. The private_transport path is zero-knowledge to B3IQ: the control plane relays ciphertext it cannot decrypt. In both cases the node operator, who runs the model, can see the content today.
| Layer | Pooled (public) | private_transport |
|---|---|---|
| Control plane (B3IQ) | Sees content in memory to price and route; never stored | Ciphertext only — holds no key, cannot decrypt |
| Routing edge (TLS terminates here) | In-path for content | Ciphertext only |
| Node operator | Sees prompt and output (runs the model) | Decrypts and sees content, until verified-confidential execution exists |
| Public settlement record | Token counts and aggregate batch totals | Same — hashes and counts, never content |
Privacy-Positive Defaults
- Node location is coarse (city-level) — never a raw IP address.
- IP and user-agent appear only as hashes in admin audit logs, with the IP under a keyed HMAC.
- API keys and tokens are stored only as hashes.
- Work receipts carry content hashes and token counts — never the prompt or output.
- Settlement records only aggregate batch totals — never per-recipient amounts.
- Queue and ledger state hold no content, and no key-value cache is used.
Confidential Routing Is Fail-Closed
A request may declare a privacy class. A verified_confidential_* request is
fail-closed: it routes only to a node whose attestation B3IQ itself has
verified and found fresh — never the node's self-reported claim.
The attestation verifier is not yet enabled, so a request for a
verified_confidential_* class currently matches no nodes. The only active
class is private_transport. We would rather route nothing than route to an
unverified node.
TEE Path
The first confidential CPU target is AMD SEV-SNP. Intel TDX remains a second backend. The TEE path needs:
Quote retrieval and verification
Prototype hardware quote retrieval and verifier service integration.
Transport key binding
Bind the node transport public key to attestation report data.
Sanitized public summary
Publish only verification status, TEE type, provider/verifier, policy ID, measurement/runtime/report-data/public-key/quote hashes, and freshness.
Client-side verification
Verify attestation before encryption in strict confidential mode.
Receipt commitment
Include attestation hash in signed receipts without exposing raw quotes or certificate chains.
Until that flow is implemented and tested end to end, use
private_transport terminology.