Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.darkbloom.dev/llms.txt

Use this file to discover all available pages before exploring further.

When you send a prompt to Darkbloom, it travels through a Mac you don’t own, operated by someone with full root access and physical custody of the hardware. The core privacy guarantee of Darkbloom is that this person cannot read what you sent — not through software, not through the operating system, and not through attached debugging tools. This page explains how that guarantee is constructed and what it means for you in practice.

​
The threat model

The machine owner has administrator privileges on their Mac. Without protections, they could in principle attach a debugger to the inference process, read process memory, or intercept data as it arrives over the network. Darkbloom closes every one of those software paths:
  • Debugger attachment is refused at the kernel level via PT_DENY_ATTACH. No process — not even root — can attach.
  • Memory inspection is blocked by macOS Hardened Runtime, which prevents memory-reading APIs from returning inference process data.
  • Code injection into the provider process is blocked by the same Hardened Runtime entitlements.
  • SIP (System Integrity Protection) makes these protections immutable for the lifetime of the process. Disabling SIP requires a reboot, which terminates the provider process. There is no way to weaken the protections while inference is running.
The only remaining attack against a Darkbloom provider is physically probing the memory chips soldered into the Apple SoC package. This is the same residual threat model Apple accepts for Private Cloud Compute (Siri and Apple Intelligence).

​
End-to-end encryption

Your request never travels to the provider in plaintext. Before the coordinator forwards any request, it re-encrypts the payload with the provider’s X25519 public key. Only the hardened provider process holds the corresponding private key — so only that process can decrypt and run your prompt. This means even if someone intercepted traffic between the coordinator and the provider, they would see ciphertext they cannot decrypt without the provider’s private key, which never leaves the secured process.

​
The coordinator runs in a Confidential VM

The Darkbloom coordinator — the routing and authentication layer your API requests first reach — runs inside a Confidential VM using AMD SEV-SNP. SEV-SNP encrypts the VM’s memory so that even the hypervisor host cannot read coordinator state. This protects your request in transit before it is forwarded to the provider.

​
Logs never contain prompt content

Coordinator logs record metadata — request IDs, model names, token counts, timestamps — but never prompt text or response content. You can verify the attestation of any provider at any time without authenticating (see Attestation).

​
Verifying security yourself

Every aspect of this security model is independently verifiable:
  • Attestation data is public at GET /v1/providers/attestation — no API key required.
  • Per-request trust headers on every API response let you confirm the provider that served your request was attested at the time it ran.
  • The binary hash of every provider binary is verified by the coordinator before routing begins. Providers cannot run modified code.
For a deeper look at the cryptographic proof behind each provider’s security claims, see Attestation and Trust levels.