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

# Understanding provider trust levels on Darkbloom

> What self_signed and hardware trust levels mean for your privacy, how each is verified, and how to check the trust level of any inference response.

Not all providers on the Darkbloom network carry the same level of cryptographic assurance. The trust level attached to a provider tells you what verification has been performed on its hardware and security configuration — and therefore how strong the privacy guarantee is for requests routed to it. This page explains the two trust levels, how they differ, and what each means for your prompts.

## Trust levels at a glance

<CardGroup cols={2}>
  <Card title="self_signed" icon="shield">
    Verified by Secure Enclave attestation and periodic challenge-response. The provider's hardware identity is established and its security posture is re-checked every 5 minutes.
  </Card>

  <Card title="hardware" icon="shield-check">
    All `self_signed` checks, plus an Apple Managed Device Attestation certificate chain rooted at Apple's Enterprise Attestation Root CA. Apple has independently vouched for the device's integrity.
  </Card>
</CardGroup>

## self\_signed

A `self_signed` provider has passed the following verification:

* Its **Secure Enclave** has produced a hardware-bound P-256 identity and signed an attestation blob. The private key never leaves the enclave and is bound to that specific Mac's hardware.
* The coordinator has verified that the provider is running a **blessed binary** — a build whose SHA-256 hash matches a coordinator-approved release.
* A **periodic challenge-response** re-confirms SIP (System Integrity Protection) and Secure Boot status every 5 minutes. If the provider's security configuration changes, it is removed from routing.

This level provides strong assurance that the provider process cannot be debugged, its memory cannot be read by the Mac owner, and it is running unmodified code. The attestation is self-generated — meaning the cryptographic evidence originates from the device itself rather than from Apple.

## hardware

A `hardware` provider has passed all `self_signed` verification, and additionally:

* An **Apple Managed Device Attestation (MDA)** certificate chain has been verified, rooted at the **Apple Enterprise Attestation Root CA**. This certificate chain is issued by Apple and proves that Apple's infrastructure has independently verified the device's hardware identity and security posture.

This is the strongest trust level available. The difference from `self_signed` is that Apple — not just the device itself — has cryptographically vouched for the machine's integrity. An attacker who somehow compromised the provider binary or the attestation process would also need to forge an Apple-signed certificate chain to appear hardware-attested.

## What the trust level means for your privacy

Both trust levels provide the same runtime protections for your prompts: E2E encryption, Hardened Runtime, SIP-enforced anti-debugging, and binary hash verification. The trust level affects the **strength of the attestation evidence** backing those claims:

|                                | self\_signed | hardware |
| ------------------------------ | ------------ | -------- |
| Secure Enclave identity        | Yes          | Yes      |
| Binary hash verified           | Yes          | Yes      |
| Challenge-response every 5 min | Yes          | Yes      |
| MDM SecurityInfo check         | Yes          | Yes      |
| Apple MDA certificate chain    | No           | Yes      |
| Apple Enterprise Root CA       | No           | Yes      |

<Tip>
  You can check the trust level of the provider that served any request using the `x-provider-trust-level` response header. See [Attestation](/security/attestation) for the full list of per-request trust headers.
</Tip>

<Warning>
  `self_signed` providers still provide meaningful privacy protection. The Secure Enclave and periodic challenge-response together make it cryptographically difficult — though not impossible — to mount an attestation forgery. `hardware` providers add Apple's independent verification on top of this.
</Warning>