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.

Attestation is the mechanism by which Darkbloom proves, cryptographically, that a provider Mac has not been tampered with before your request is routed to it. Rather than asking you to trust that a provider has the right security configuration, the system produces machine-verifiable evidence that is checked before every session and refreshed continuously while inference runs. This page explains what that evidence consists of, how it is verified, and how you can inspect it yourself.

​
What attestation proves

A fully attested provider has demonstrated all of the following to the coordinator:
  1. It is running a blessed binary — a provider build whose SHA-256 hash matches a coordinator-approved release.
  2. Its Secure Enclave has produced a hardware-bound P-256 keypair and a signed attestation blob tied to that specific piece of hardware.
  3. MDM SecurityInfo has been cross-checked via Apple MDM to confirm SIP, Secure Boot, and FileVault are all enabled on the machine.
  4. An Apple Managed Device Attestation (MDA) certificate chain — rooted at Apple’s Enterprise Attestation Root CA — has been verified, meaning Apple has independently vouched for the device’s hardware integrity.

​
Four layers of verification

Every provider generates a hardware-bound P-256 identity inside the Secure Enclave — a dedicated security processor that is isolated from the main CPU and operating system. The private key never leaves the enclave. The coordinator uses the corresponding public key to verify attestation blobs that only that specific Mac can produce.
Providers enroll in an MDM profile. The coordinator uses Apple’s MDM SecurityInfo API to independently check that SIP (System Integrity Protection), Secure Boot, and FileVault are all enabled. This check runs from outside the provider process, so the provider cannot manipulate the result.
For hardware-attested providers, the coordinator verifies a certificate chain issued through Apple’s Managed Device Attestation program and rooted at the Apple Enterprise Attestation Root CA. This means Apple itself has cryptographically vouched for the device’s hardware. See Trust levels for what this means for your requests.
Attestation is not a one-time check at startup. The coordinator sends a fresh challenge to every connected provider every 5 minutes. The provider must re-demonstrate its SIP and Secure Boot status. If a provider’s security posture changes — for example if someone rebooted into recovery mode and disabled SIP — it would fail the next challenge and be removed from the routing pool.

​
Verifying attestation yourself

Attestation data for all active providers is publicly accessible with no authentication required: 
curl https://api.darkbloom.dev/v1/providers/attestation
The response contains the attestation blobs, public keys, and certificate chains for each provider. You can independently verify the Apple MDA certificate chain against Apple’s published root CA.

​
Per-request trust headers

Every API response from Darkbloom includes headers that tell you exactly which provider served your request and what its trust level was at the time:
HeaderDescription
x-provider-attestedtrue if the provider was attested when your request ran
x-provider-trust-levelTrust level: self_signed or hardware
x-se-signatureSecure Enclave signature over the response
x-response-hashSHA-256 hash of the response body
x-se-public-keyThe provider’s Secure Enclave public key

​
Reading trust headers from a response

curl -i https://api.darkbloom.dev/v1/chat/completions \
  -H "Authorization: Bearer $DARKBLOOM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"mlx-community/gemma-4-26b-a4b-it-8bit","messages":[{"role":"user","content":"Hello"}]}'
An example response header set looks like: 
x-provider-attested: true
x-provider-trust-level: hardware
x-se-signature: MEUCIQD...
x-response-hash: sha256:a3f1...
x-se-public-key: MFkwEwYHKoZIzj0C...
The x-se-signature is a Secure Enclave signature over the response hash. You can verify it against the provider’s x-se-public-key using standard P-256 ECDSA verification.