DP15 — Security & Provenance
Patches are passage-level only – each one is tied to selected text in the reader. There are no document-wide patches. Use comments for general feedback on the whole document.
Integrity and provenance are lost or weakened as artifacts move across systems, enabling tampering without detection.
Daveed
Integrity and provenance are lost or weakened as artifacts move across systems, enabling tampering without detection. **3.11 Capable AI as a direct adversary.** DP15 assumes that AI systems with capabilities at or above human-expert level in security, social engineering, code generation, and protocol exploitation will be present in the threat environment. Such systems may attempt to hack, deceive, break in: compromising signing keys and attestation roots; fabricating or socially engineering the disclosure of credentials; exploiting software supply chains to insert or replay malicious artifacts; synthesizing policy artifacts and audit trails that appear authentic; and coordinating across many endpoints to overwhelm verification witnesses. DP15 does not require AI to be the threat. It requires that verification primitives and operational practices remain sound against a capable AI adversary acting alone, in coordination with other AI systems, or in combination with insider, criminal, or state actors. **Failure mode: human-baseline verification**, where keys, attestation chains, and disclosure rituals are designed for a slower, less capable, less coordinated adversary.
Why it fits: The contributor's verbatim capability statement ('may have the capability to hack, deceive, break in') belongs at the threat-modeling layer of DP15, and the existing §3 entries already enumerate named adversaries, so inserting §3.11 as a new numbered sibling preserves the document's threat-statement structure rather than burying capability in Security Core. Opening the new section above the §6 / §12 alignment insertions also gives readers the threat premise before they meet the conditions that must hold against it. Pre-flight checks against the graph: The opening clause is the exact wording attributed to the contributor and the failure mode ('human-baseline verification') does not collide with any existing failure-mode label retrieved from the DP15 graph neighborhood. Anchoring above an existing §3 sentence (rather than at the chapter heading) keeps the new subsection inside the threat-modeling list. Filed from Canopi book insert efc4fe37-43e3-4b65-974a-612760b3e7b4 (insert below the anchor, encoded as replace).
Daveed
Integrity and provenance are lost or weakened as artifacts move across systems, enabling tampering without detection. **3.12 Verification monoculture.** When participants, communities, and systems rely on the same attestation provider, identity registry, log witness, or provenance service, concentration creates a single point of failure that a capability-asymmetric adversary can exploit. DP15 treats verification monoculture as a structural risk distinct from implementation bugs: even correct cryptography fails closed if every verifier derives trust from one root, one identity provider, or one operator. **Failure mode: monoculture breach**, where a single attestation or identity compromise yields system-wide loss of provenance integrity rather than bounded blast radius.
Why it fits: §3.11 names the *adversary*; §3.12 names the *structural condition* that adversary exploits, so they belong as consecutive threat-modeling entries rather than merged. Using insert_after the new §3.11 keeps numerical order tight and avoids skipping ahead to §3.13, which the style guidance explicitly forbids. Pre-flight checks against the graph: 'monoculture breach' is a new failure-mode label with no collision in retrieved DP15 graph terms, and 'structural risk distinct from implementation bugs' aligns with the DP15 §5.11 adversarial-resilience language already present. Placing it directly after §3.11 avoids any mid-prose cuts and respects the numbered-list rule. Filed from Canopi book insert 1e2c9ab5-d5f0-436a-8acc-d60ec10e9639 (insert below the anchor, encoded as replace).
Detection, disclosure, rotation, notification, and rollback pathways are defined and rehearsed before they are needed, with predefined authority and communication duties.
Daveed
Detection, disclosure, rotation, notification, and rollback pathways are defined and rehearsed before they are needed, with predefined authority and communication duties. **6.6 Adversarial-AI verification.** Human-only authentication, human-only disclosure review, and key custodianship MUST be paired with machine-verifiable cryptographic bindings and rate or coordination limits inherited from DP13 (AI Containment) §3.5 and §5. Verification routes that depend solely on human vigilance or human-speed response do not satisfy DP15 under a capable-AI threat environment. **Failure mode: drift back to human baseline**, where rituals that pre-date capable AI adversaries are left in place and human operators become the rate-limiting step an adversary can predict and outlast.
Why it fits: §6 is the Security Core, and the new condition operationalizes §3.11 by forbidding the failure mode §3.11 just warned about, which is the right place for a MUST-level obligation rather than further threat description. Numbering as §6.6 (not §6.8) keeps the list sequential immediately after the last existing §6 entry, satisfying the no-skip rule. Pre-flight checks against the graph: The DP13 §3.5 / §5 reference is consistent with the DEPENDS_ON edge DP15 → DP13 already proposed in the post draft, so the citation graph stays internally aligned. The phrasing 'do not satisfy DP15 under a capable-AI threat environment' echoes the §3.11 framing without duplicating it verbatim. Filed from Canopi book insert 8c699edb-08a7-4d08-b648-ac172325dc33 (insert below the anchor, encoded as replace).
Daveed
Detection, disclosure, rotation, notification, and rollback pathways are defined and rehearsed before they are needed, with predefined authority and communication duties. **6.7 Verification independence.** High-stakes verification MUST be distributable across independent operators or roots, with an explicit fail-closed posture when a sole provider is compromised, silent, or otherwise unavailable. A system whose verification collapses because one attestation, identity, or witnessing service fails does not satisfy DP15. **Failure mode: single-witness systemic failure**, where independence is asserted architecturally but not enforced operationally, so a single outage or compromise propagates loss of provenance integrity to every dependent participant.
Why it fits: §6.7 handles 'human baseline drift'; §6.7 handles 'monoculture' by requiring independent operators, so the two Security Core conditions address the two failure modes named in the new §3 entries without overlap. As the next unused sibling, §6.7 is the correct number rather than jumping to §6.10 or later. Pre-flight checks against the graph: 'single-witness systemic failure' is a fresh failure-mode label that does not collide with existing graph terms, and the fail-closed language matches the wider DP15 lifecycle framing in §5. Anchoring as insert_after the new §6.7 satisfies the no-skip numbering rule. Filed from Canopi book insert 2f4c023a-c4aa-4ad7-aa9e-d553a174cb45 (insert below the anchor, encoded as replace).
Systems MUST preserve records necessary for dispute resolution
Daveed
Systems MUST preserve records necessary for dispute resolution **12.9 Adversarial-AI Robustness (minimum alignment).** Systems MUST document, for each verification primitive they rely on, how that primitive is expected to fail under capable-AI conditions and what observable signal the system emits when such failure is detected. A primitive that can degrade silently does not satisfy DP15. **Failure mode: verification collapse against capable AI**, where attestation, identity, or witnessing appears to succeed while the underlying primitive has already been subverted, and no signal surfaces for operators or participants.
Why it fits: §12 is the minimum-alignment layer where MUST-level obligations live alongside the rest of the DP15 alignment conditions, so the 'signal on failure' requirement belongs there rather than in §6 (which is about composition with humans) or §15 (forward-horizon posture). Numbering as §12.9 immediately follows the last existing §12 sibling, with no skips. Pre-flight checks against the graph: The 'observable signal on failure' language is consistent with the DP15 §5.11 adversarial-resilience tone already in the draft, and 'verification collapse against capable AI' does not duplicate any existing failure-mode label retrieved from the graph. The patch preserves the contributor's capability framing without paraphrasing the verbatim quote a second time. Filed from Canopi book insert 2e81bc80-9147-44d3-8932-0fca0fe7f6d9 (insert below the anchor, encoded as replace).
Daveed
Systems MUST preserve records necessary for dispute resolution **12.10 Independence (minimum alignment).** Systems MUST NOT depend on a single attestation root, identity provider, or witness service for verification of high-stakes claims. Where independence is not yet achievable, the resulting dependency MUST be disclosed together with a documented migration path and a bounded blast-radius statement. **Failure mode: verification monoculture**, the same structural condition named in §3.12, manifesting here as a minimum-alignment obligation that any system claiming DP15 conformance must meet or explicitly disclaim.
Why it fits: §12.10 handles 'robustness under capable AI'; §12.10 handles 'independence from a single root', so they read as a paired minimum-alignment obligation set analogous to the §6.7 / §6.8 pairing at the Security Core layer. Using §12.10 as the next unused number after §12.10 respects the no-skip rule. Pre-flight checks against the graph: Cross-referencing §3.12 reuses the 'verification monoculture' term in a defined way rather than introducing a synonym, which keeps the failure-mode vocabulary consistent across the document. The 'disclosed with a migration path' phrasing aligns with the DP15 disclosure-tone already present around open questions in §13. Filed from Canopi book insert 26d29544-a5c9-4e9a-ac05-f89d7b698c22 (insert below the anchor, encoded as replace).
DP15 assumes breach, key compromise, and manipulation attempts will occur.
Daveed
DP15 assumes breach, key compromise, and manipulation attempts will occur. **15.1 Anticipatory threat-model posture.** Verification design under DP15 MUST signal degradation rather than silently fail, and MUST assume, at minimum, the following forward-horizon conditions: (a) quantum-capable adversaries able to break currently deployed signature and hash primitives; (b) AI systems capable of forging, deceiving, and breaking in at human-expert level across security, social engineering, code generation, and protocol exploitation; (c) concentration of attestation, identity, or data infrastructure that creates monoculture risk. These assumptions apply unless and until a successor threat-model revision explicitly supersedes them.
Why it fits: §15 is the forward-horizon section of the DP15 draft (per the earlier table that lists §13 and surrounding sections as future-work territory), so the anticipatory-posture statement belongs as a new §15.1 entry rather than as a §13 bullet. Anchoring with insert (above an existing §15 sentence) lets the posture statement lead the section instead of being appended. Pre-flight checks against the graph: Clause (b) reuses the contributor's verbatim capability verb set ('forging, deceiving, breaking in') without re-quoting the 'hack, deceive, break in' formulation used in §3.11, so the document does not duplicate the exact quote. Clause (c) ties forward-horizon posture back to the §3.12 monoculture failure mode, preserving graph consistency. As a forward-horizon statement, §15.1 does not need its own failure-mode label because its job is to set assumptions, which matches the role other §15 entries play in the draft. Filed from Canopi book insert bf376ddc-d383-490a-8e99-c0edc6eef3c0 (insert below the anchor, encoded as replace).
Open the reader, select the sentence(s) you want to change, and submit a patch.
Open ReaderTitle: DP15 — Security & Provenance
Authors: The Meta-Layer Initiative
Status: approved
Last Updated: 2026-09-28