Skip to content

privacy-expectations.md

Latest commit

 

History

History
32 lines (23 loc) · 5.14 KB

privacy-expectations.md

File metadata and controls

32 lines (23 loc) · 5.14 KB
Raw

Privacy expectations

Last updated: 2026-09-03 · commit 5d400cf75

What you can and cannot rely on when you send an inference request through Darkbloom. For consumers deciding what to send; the mechanism — which key opens which hop, wire formats, error codes, and the code that enforces each guarantee — is stated once in ../architecture/security/encryption.md and is not restated here.

In one sentence: your request is encrypted between the coordinator and the provider that runs the model, and optionally between you and the coordinator; the coordinator decrypts it in memory to route and bill it and writes no content to logs or storage, and the provider sees your prompt and the completion in plaintext.

What you can rely on

  1. The two legs between the coordinator and the provider are always encrypted with NaCl Box, whether or not you sealed your request; a provider without a registered key is never selected — hop 2, hop 3.
  2. You can seal your request body to the coordinator's published key so that TLS-terminating intermediaries in front of the coordinator never see it; the response comes back sealed to your ephemeral key with X-Eigen-Sealed: true — hop 1; wire shape in ../reference/api-contracts.md#sealed-transport-wire-shape.
  3. The coordinator holds your prompt, attached media and the completion in memory only for the life of the request and writes none of it to logs or the store; the only content-derived artifacts are keyed digests used for cache routing — what the coordinator logs and retains.
  4. Your request is dispatched only to a provider that passes every privacy gate: an X25519 key bound to an attested Secure Enclave identity, in-process inference, coordinator-verified SIP, and code identity once it is enforced — invariants, routing gate.
  5. A provider that returns a plaintext or wrong-key response chunk is marked untrusted and your request fails rather than being served insecurely — hop 3.
  6. The provider never sees your API key, Privy identity or balance, and never sees another consumer's prompts — what each party can observe.
  7. Provider error text is reduced to a closed vocabulary before it is logged or returned to you, and client telemetry ingest is disabled so no free-form fields reach the coordinator — what the coordinator logs and retains.

What you cannot rely on

  1. "The coordinator never sees plaintext" is false. The coordinator opens your request in memory to route, bill and enforce the request contract, then re-encrypts it for exactly one provider — what each party can observe.
  2. The provider sees your prompt and the completion in plaintext: it is the decryption endpoint, because in-process inference at native speed requires it. The guarantee is about which process holds the key — ../architecture/security/attestation.md, ../architecture/security/identity-binding.md.
  3. Sealing is optional and deployment-dependent: plaintext JSON is accepted on the same routes, and GET /v1/encryption-key returns 503 encryption_unavailable when the coordinator has no sealing key, leaving the consumer → coordinator hop TLS-only — failure modes.
  4. A sealed request cannot use remote image_url media: the coordinator refuses to fetch on behalf of a sealed body — hop 1.
  5. Metadata is retained: model, sampling parameters, token counts, latency, request and trace IDs, the selected provider, the remote address of your connection (access log), and your account identity (API key hash, Privy DID, balance) — what the coordinator logs and retains.
  6. There is no per-response signature or receipt: the X-Provider-* headers are the coordinator's assertion over TLS, not a provider-signed proof — verification.md.

Related