> ## 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.

# Verifying provider attestation on Darkbloom

> Darkbloom's four-layer attestation proves every provider's security posture is intact. Learn how to verify attestation data and read per-request trust headers.

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

<AccordionGroup>
  <Accordion title="Secure Enclave signature">
    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.
  </Accordion>

  <Accordion title="MDM-based hardware verification">
    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.
  </Accordion>

  <Accordion title="Apple MDA certificate chain">
    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](/security/trust-levels) for what this means for your requests.
  </Accordion>

  <Accordion title="Challenge-response every 5 minutes">
    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.
  </Accordion>
</AccordionGroup>

## Verifying attestation yourself

Attestation data for all active providers is publicly accessible with no authentication required:

```bash theme={null}
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:

| Header                   | Description                                               |
| ------------------------ | --------------------------------------------------------- |
| `x-provider-attested`    | `true` if the provider was attested when your request ran |
| `x-provider-trust-level` | Trust level: `self_signed` or `hardware`                  |
| `x-se-signature`         | Secure Enclave signature over the response                |
| `x-response-hash`        | SHA-256 hash of the response body                         |
| `x-se-public-key`        | The provider's Secure Enclave public key                  |

### Reading trust headers from a response

<CodeGroup>
  ```bash curl theme={null}
  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"}]}'
  ```

  ```python Python theme={null}
  import httpx

  response = httpx.post(
      "https://api.darkbloom.dev/v1/chat/completions",
      headers={"Authorization": "Bearer eigeninference-your-key-here"},
      json={
          "model": "mlx-community/gemma-4-26b-a4b-it-8bit",
          "messages": [{"role": "user", "content": "Hello"}],
      },
  )

  print(response.headers.get("x-provider-trust-level"))
  print(response.headers.get("x-provider-attested"))
  print(response.headers.get("x-se-signature"))
  ```
</CodeGroup>

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...
```

<Note>
  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.
</Note>