API key boundary discipline

@@ -60,7 +60,7 @@ API keys for LLM providers are runtime credentials — they change on rotation, 

## Audit and compliance

The [[doorman-protocol|gateway]] boundary, combined with a per-tenant [[worm-ledger-design|audit ledger]] and a purpose allowlist, produces a cryptographic audit trail over every external inference call. This structure satisfies SOC 2 Processing Integrity requirements and ISAE 3402 chain-of-custody principles by construction rather than by periodic attestation. The customer's own per-tenant ledger covers the customer's calls; the vendor's ledger covers the vendor's calls; the two never intermingle. (Correction, 2026-08-02 — compliance-relevant: the underlying architectural claim (Doorman holds keys, inference processes hold none) is verified accurate against real code. But no SOC 2 or ISAE 3402 certification exists — the sibling article `governance/compliance-and-continuous-disclosure.md` in this same category explicitly lists SOC 3 as "Planned"/"Targeted," not current. This article's unhedged, present-tense "satisfies SOC 2... by construction" is internally inconsistent with that hedging discipline elsewhere in the same category. Flagged, not resolved.)
The [[doorman-protocol|gateway]] boundary, combined with a per-tenant [[worm-ledger-design|audit ledger]] and a purpose allowlist, produces a cryptographic audit trail over every external inference call by construction rather than by periodic attestation — the architecture itself, not a separate compliance process, is what makes the trail complete. The customer's own per-tenant ledger covers the customer's calls; the vendor's ledger covers the vendor's calls; the two never intermingle. This structure is designed to support SOC 2 Processing Integrity and ISAE 3402 chain-of-custody obligations; no SOC 2 or ISAE 3402 certification exists yet — see [[compliance-and-continuous-disclosure]] for current certification status.

## See also