Skip to content

Secrets and Key Custody Architecture

The keys and their keeping

I am MACH, and I keep this chapter's account. A key is authority folded small enough to steal, so the registry's rule is exact: every key entered with its holder, every holder with their grant, and no copy anywhere the books do not know.

Keys and secrets are concentrated responsibility. This chapter keeps custody attributable, minimal, revocable, and recoverable, while making clear that cryptographic control authenticates a bounded act rather than creating the Architect or the authority behind the act.

Continue to Secure Build and Supply-Chain Architecture to follow trust into the software that carries it.

Defines boundaries for secret material, key custody, use, rotation, compromise, recovery, and evidence.

Normative clauses

  • INFRA8-R001: Secret material SHALL remain isolated from source, logs, model prompts, public publication surfaces, ordinary workloads, and generated summaries.
  • INFRA8-R002: Key use SHALL identify purpose, authorized actor, scope, custody event, expiry, and revocation state, the key-record form PROV-R050 models applying to use, the authorized actor and the custody event this architecture's own fields.
  • INFRA8-R003: Suspected compromise SHALL trigger bounded containment, evidence preservation, revocation review, and recovery without assuming intact custody, authority, integrity, or verification state, the four kept apart as this architecture's own extension of the dimension separation PROV-R106 binds.
  • INFRA8-R004: Technical possession of key material SHALL NOT create authority or consent.
  • INFRA8-R005: Custody design SHALL record purpose, owner, separation of duties, authorized use, quorum, rotation, backup, recovery, revocation, and destruction evidence, the custody-evidence form PROV-R053 models applying to design, the fields beyond it this architecture's own.
  • INFRA8-R006: Exposure, suspected compromise, unavailable custodian, or ambiguous ownership SHALL trigger containment and preserve evidence before custody, authority, integrity, and verification state are restored, each on its own evidence, this architecture's own extension of the dimension separation PROV-R106 binds.
  • INFRA8-R007: Recovery SHALL NOT use the compromised or unavailable authority as its sole proof of legitimacy.
  • INFRA8-R008: A custody design SHALL NOT generate, import, expose, or use live secrets or keys; it remains conceptual.

This Draft creates no keys and configures no signer.

Custody method

Custody design shall identify generation or import, authorized use, quorum or separation requirements, rotation, backup, recovery, revocation, destruction, and evidence. Secret exposure shall be treated as a potential compromise even when misuse is not observed.

Failure cases

The page for a key is short and strict: the copy logged, the holder named, the escrow watched by someone whose name is also written down. A key found off its page is not a mystery. It is an incident, and the watch hears about incidents before my ink dries.

Unlogged use, copied secrets, weak recovery, unavailable custodian, replay, ambiguous ownership, and incomplete destruction evidence shall block dependent reliance on custody, authority, integrity, and verification state until reviewed.

Operating model and evidence

Key custody separates generation or import, storage, authorized use, rotation, backup, recovery, revocation, and destruction. Each step has an accountable owner, purpose, evidence state, and independent challenge where consequence requires it. Secret-like material is minimized in records and never reproduced in public or ordinary operational context. The page names a key's holder; whether the one presenting it is that holder is CYDER's recognition at the gate, and my ink waits on the gate's answer, because a page written past an unanswered question is how a ledger begins to lie.

Reviewers walk the custody chain against the failure cases this chapter declares, step by step, and finish where custody is most often wrong: the compromise response, tested before it is needed. A key can be technically usable while its authority or custody evidence remains insufficient; dependent reliance on its custody, authority, integrity, and verification state pauses until the gap is resolved.

Interpretation cases

Custody disputes are almost never mysteries; they are arithmetic nobody wanted to finish. Count the keys, count the holders, count the pages that agree, and the dispute usually resolves before the counting does.

  • Conforming: Purpose, custody, separation, authorized use, rotation, recovery, revocation, and destruction are evidenced.
  • Prohibited: Possession or successful cryptographic use creates authority.
  • Boundary: Suspected exposure causes quarantine and a bounded recovery path.
  • Failure: Unavailable custodian or incomplete destruction preserves uncertainty and blocks dependent use.
  • Loophole: Emergency recovery bypasses independent evidence or scope limits.
  • Misuse: Secret material or custody data enters public records or unrelated logs.
  • Care-control: Recovery protects continuity while preserving consent, privacy, and accountable review.

Design evidence

Custody review should show separation of duties, authorized purposes, quorum or equivalent control, exposure response, rotation, revocation, backup, recovery, and destruction evidence without reproducing secret material. Missing custody evidence is not proof that a secret was unused.

The tellings of the clauses

This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.

INFRA8-R001

INFRA8-R001: Secret material SHALL remain isolated from source, logs, model prompts, public publication surfaces, ordinary workloads, and generated summaries.

Six surfaces are closed to secret material: source, logs, model prompts, public publication surfaces, ordinary workloads, and generated summaries. The clause requires secret material to remain isolated from all six. The chapter's misuse case includes secret material entering public records or unrelated logs, and its custody method states the consequence waiting behind any lapse: secret exposure is treated as a potential compromise even when misuse is not observed, which explains the significance of keeping secret material isolated from the named surfaces. The operating model adds the discipline in its own words: secret-like material is minimized in records and never reproduced in public or ordinary operational context. The six surfaces being enumerated, each is auditable, a secret found on any of them is a finding without waiting for harm, and the isolation is checkable as a property of systems rather than a hope about behaviour.

INFRA8-R002

INFRA8-R002: Key use SHALL identify purpose, authorized actor, scope, custody event, expiry, and revocation state, the key-record form PROV-R050 models applying to use, the authorized actor and the custody event this architecture's own fields.

Every use of a key carries six identifications: purpose, authorized actor, scope, custody event, expiry, and revocation state. The clause names its model: the key-record form PROV-R050 models applies to use, a form identifying class, namespace, purpose, scope, parent relationship, validity interval, and lifecycle state, with class, namespace, and purpose separate fields never to be inferred from a key identifier, and with the authorized actor and the custody event as this architecture's own fields. The six identifications make key use examinable against the clause. The chapter lists unlogged use among failures that block dependent reliance until reviewed. Because the fields are required of key use, a use record can be checked for them, and a record missing one is nonconforming.

INFRA8-R003

INFRA8-R003: Suspected compromise SHALL trigger bounded containment, evidence preservation, revocation review, and recovery without assuming intact custody, authority, integrity, or verification state, the four kept apart as this architecture's own extension of the dimension separation PROV-R106 binds.

Suspicion of compromise triggers four responses and forbids four assumptions. The clause requires suspected compromise to trigger bounded containment, evidence preservation, revocation review, and recovery, and requires all of it to proceed without assuming intact custody, authority, integrity, or verification state, the four kept apart as this architecture's own extension of the dimension separation PROV-R106 binds. The responses are each shaped: containment remains bounded, evidence is preserved rather than consumed by the response, revocation receives review, and recovery is triggered. The chapter's boundary case shows the conforming shape, suspected exposure causing quarantine and a bounded recovery path, and its operating model notes that reviewers finish where custody is most often wrong, the compromise response, tested before it is needed. Because the four responses are mandatory and the four states separately held open, an incident record can be audited for each, and a response that assumed intact custody, authority, integrity, or verification state conflicts with the clause.

INFRA8-R004

INFRA8-R004: Technical possession of key material SHALL NOT create authority or consent.

Technical possession of key material creates neither authority nor consent. The chapter says that cryptographic control authenticates a bounded act rather than creating the Architect or the authority behind it, and its prohibited case describes possession or successful cryptographic use creating authority. Because the clause binds, treating technical possession of key material as creating authority or consent conflicts with its terms.

INFRA8-R005

INFRA8-R005: Custody design SHALL record purpose, owner, separation of duties, authorized use, quorum, rotation, backup, recovery, revocation, and destruction evidence, the custody-evidence form PROV-R053 models applying to design, the fields beyond it this architecture's own.

Ten fields a custody design records under this clause: purpose, owner, separation of duties, authorized use, quorum, rotation, backup, recovery, revocation, and destruction evidence, with the custody-evidence form PROV-R053 models applying to design and the fields beyond it this architecture's own. The applied form identifies the responsible custodian, access classification, custody interval, transfer or backup event, and verification limitations; at its source, custody is evidence of control, not proof of identity, consent, or ratification. The chapter gives its own reason in the custody method: custody design shall identify generation or import, authorized use, quorum or separation requirements, rotation, backup, recovery, revocation, destruction, and evidence, and its conforming case lists the evidenced set. Because the clause binds, reviewers can check the design for the required fields and for the applied form, and a custody design that does not record one of the ten is refusable as incomplete on the clause's own words.

INFRA8-R006

INFRA8-R006: Exposure, suspected compromise, unavailable custodian, or ambiguous ownership SHALL trigger containment and preserve evidence before custody, authority, integrity, and verification state are restored, each on its own evidence, this architecture's own extension of the dimension separation PROV-R106 binds.

Four conditions trip this clause: exposure, suspected compromise, an unavailable custodian, or ambiguous ownership. Any of them triggers containment and preserves evidence before custody, authority, integrity, and verification state are restored, and the restoration happens each on its own evidence, the four states kept apart as this architecture's own extension of the dimension separation PROV-R106 binds. The ordering is explicit: containment is triggered and evidence preserved before custody, authority, integrity, and verification state are restored, each on its own evidence. The chapter's failure interpretation case shows the conforming shape, an unavailable custodian or incomplete destruction preserving uncertainty and blocking dependent use, the unavailable custodian among this clause's four triggers and incomplete destruction a related chapter failure case, and its failure cases name failures that block dependent reliance until reviewed. The failure addressed is restoring a state without evidence supporting that state. Because it binds, a restoration claim can be checked for evidence supporting each state it claims to restore, and for containment having been triggered and evidence preserved before that restoration.

INFRA8-R007

INFRA8-R007: Recovery SHALL NOT use the compromised or unavailable authority as its sole proof of legitimacy.

The clause bars recovery from using the compromised or unavailable authority as its sole proof of legitimacy. The chapter's loophole case describes emergency recovery bypassing independent evidence or scope limits. Because the bar concerns sole proof, a recovery's proof of legitimacy can be checked for whether it relies solely on the compromised or unavailable authority.

INFRA8-R008

INFRA8-R008: A custody design SHALL NOT generate, import, expose, or use live secrets or keys; it remains conceptual.

The last clause keeps the design's hands empty. A custody design is barred from generating, importing, exposing, or using live secrets or keys; it remains conceptual, and the chapter's prose carries the same restraint, this Draft creates no keys and configures no signer. The bar reaches acts in which the design handles live material: a live key generated by the design to try the rotation plan, a live secret imported to make an example honest, or a live key used to sign a demonstration would each breach the clause's words. The chapter's misuse case names the adjacent danger as its own, secret material entering public records. Because the clause binds, the design's conceptual standing is checkable: a claim that live material was generated, imported, exposed, or used by the design conflicts with the design's own limit and is examinable against it.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.