DP15 — Security & Provenance
| ID: | ML-Draft-019 |
| Title: | DP15 — Security & Provenance |
| Status: | approved |
| Authors: | The Meta-Layer Initiative |
| Group: | N/A |
| Date: | 2026-05-04 |
| Revision: | 00 |
| Pages: | 6 |
| Words: | 2630 |
DP15 establishes security as continuous verification and provenance as default infrastructure, ensuring that actions, artifacts, and AI outputs are integrity-protected and traceable. It requires systems to provide verifiable chains of custody—who did what, when, under which conditions—across creation, distribution, and use. The draft addresses failures like tampered content, opaque supply chains, and unverifiable AI outputs, introducing mechanisms such as signed artifacts, tamper-evident logs, runtime attestation, and provenance envelopes. Without these guarantees, systems devolve into environments where anything can look real—and nothing can be proven.
This draft articulates Desirable Property 15 (DP15) as the condition under which security is structural and provenance is inspectable, so participants and communities can verify what happened, who did it, under which policy, and whether artifact integrity holds.
DP15 connects DP1 (accountability), DP4 (data handling evidence), DP11–DP13 (AI disclosure and containment), DP14 (trust and transparency), DP7 (interoperability of signed exports), and DP16 (roadmap honesty about security posture).
If DP15 is weak, predictable failures follow: silent breaches, undetected tampering, unverifiable AI outputs, supply-chain compromise, and governance decisions without evidence chains.
DP15 does not require every participant to understand cryptography. It defines the minimum conditions under which strong claims are backed by strong, accessible evidence.
In today’s web, security is often reactive and provenance is optional.
Systems are patched after breaches, logs are controlled by operators, and downstream tools discard evidence needed to verify origin or integrity. Participants are asked to trust without meaningful ways to verify.
This produces recurring failures:
These failures are structural. Trust without verification scales fraud.
DP15 reframes security as continuous assurance and provenance as default metadata carried across systems.
A single operator controls signing keys.
Example: A platform can forge logs or artifacts without independent verification.
Why this matters: High-stakes systems require distributed trust or independent witnessing.
Synthetic or altered media appears authentic without verifiable origin.
Example: A fake executive video triggers financial action.
Why this matters: Provenance must bind claims to verifiable evidence.
Dependencies and build processes are not visible or verifiable.
Example: A compromised package leaks secrets undetected.
Why this matters: Supply-chain integrity is a systemic dependency.
Security claims do not match actual system behavior.
Example: Promised encryption is disabled or bypassed in support workflows.
Why this matters: Security must be verifiable, not declarative.
Logs can be edited or selectively disclosed.
Example: Appeals fail because events cannot be independently verified.
Why this matters: Accountability requires tamper-evident records.
AI-generated outputs lack traceability.
Example: A model produces authoritative-seeming content with no source or version context.
Why this matters: AI outputs must be bound to retrievable evidence where claims are made.
Attackers combine multiple weaknesses across identity, content, and infrastructure to create convincing but false realities.
Example: A coordinated campaign introduces a malicious dependency (supply chain), uses AI to generate plausible documentation and endorsements, and distributes signed-looking artifacts through compromised or misrepresented keys.
Why this matters: Individual protections (signatures, logs, provenance) can appear valid in isolation but fail when combined in adversarial scenarios.
Failure mode: composed deception, where multiple weak signals reinforce each other into a credible but false system state.
Trusted insiders or compromised accounts introduce changes that appear legitimate, amplified by AI-generated artifacts and opaque dependencies.
Example: An insider approves a malicious update, AI generates supporting documentation and changelogs, and downstream systems accept the update because provenance appears complete but is internally compromised.
Why this matters: Trust anchored only in roles or signatures is insufficient without independent verification, multi-party validation, and anomaly detection.
Failure mode: trusted-path compromise, where legitimate authority is used to introduce unverifiable or malicious changes.
Old but valid artifacts, logs, or attestations are reused to mask current compromise or regress system state.
Example: A previously signed and valid build is redeployed after a security patch, bypassing protections while appearing authentic.
Why this matters: Provenance must include temporal context and revocation awareness.
Failure mode: temporal deception, where authenticity is preserved but relevance is not.
Integrity and provenance are lost or weakened as artifacts move across systems, enabling tampering without detection.
Example: A signed artifact is exported into a system that strips signatures, then modified and reintroduced without clear indication of lost provenance.
Why this matters: Cross-system integrity must be preserved or explicitly degraded with visible signaling.
Failure mode: silent degradation, where users assume guarantees that no longer hold.
Security and provenance in the meta-layer mean that critical actions, artifacts, and automated behaviors are integrity-protected, attributable, and explainable at useful depth.
Participants and auditors must be able to verify chains of custody for data, software, and AI outputs.
Example: A document includes content hash, signing keys, model version, and policy state at time of generation.
What this feels like: Serious claims carry verifiable receipts.
Without this: Trust collapses into presentation rather than evidence.
Critical artifacts are signed, hashed, and versioned where feasible, with clear trust anchors (DP1) and verifier pathways.
Systems MUST define:
- which artifacts require signatures (high-stakes vs low-stakes)
- accepted signature schemes and key provenance
- how verification is performed at read time and export time
Verification UX should surface: valid, invalid, unknown signer, or unverifiable.
Failure modes:
- implicit trust (unsigned artifacts treated as authoritative)
- verification bypass (signatures present but not checked)
Systems publish dependency inventories and build provenance (e.g., SBOMs) with linkage to build outputs and runtime artifacts.
This includes:
- dependency versions, sources, and integrity hashes
- build pipelines with reproducibility or attestations
- mapping from source → build → deployable artifact
Verification MUST allow independent parties to confirm that shipped artifacts correspond to declared inputs.
Failure modes:
- opaque dependencies
- non-reproducible builds that cannot be audited
Execution environments provide attestations that policies are enforced as declared, including configuration state, policy versions, and integrity measurements.
Systems SHOULD support:
- remote attestation for critical services
- linkage between attestation and policy claims (DP8)
Verification MUST allow participants to detect divergence between declared and actual runtime state.
Failure modes:
- policy–execution gap
- stale attestations reused beyond validity
AI outputs include model identifiers, relevant inputs or retrieval sources, and policy context, bounded by privacy constraints.
This includes:
- model/version identifiers and evaluation context
- prompt/retrieval lineage where claims are made
- safety/policy configuration at generation time (DP12 linkage)
Verification MUST distinguish:
- attributable outputs vs. non-attributable outputs
- grounded claims vs. ungrounded generation
Failure modes:
- attribution ambiguity
- capability inflation via unverifiable claims
Moderation, governance, and system events are recorded in append-only or verifiable logs with ordering guarantees and witnessability.
Systems SHOULD support:
- append-only structures (e.g., Merkle trees)
- external witnesses or checkpoints
- inclusion proofs for specific events
Verification MUST allow participants to confirm that events were not removed or altered.
Failure modes:
- log laundering
- selective disclosure of events
Systems implement key rotation, compromise handling, and transparent custody models with documented ownership and recovery pathways.
This includes:
- rotation schedules and revocation mechanisms
- multi-party custody for high-risk keys
- recovery procedures with audit trails
Verification MUST surface key status (active, rotated, revoked) at use time.
Failure modes:
- stale keys used after compromise
- opaque custody enabling unilateral control
Security issues are surfaced through coordinated disclosure, bug bounties, and public postmortems with remediation evidence and timelines.
Systems SHOULD maintain:
- disclosure policies with response SLAs
- postmortems linking vulnerabilities → fixes → verification
Verification MUST allow participants to see whether issues were resolved and how.
Failure modes:
- silent remediation without accountability
- recurring vulnerabilities without learning
Artifacts carry structured metadata describing origin, transformations, and policy context across systems.
Envelopes SHOULD include:
- origin identity and signatures (DP1)
- transformation steps and handlers
- policy and consent context (DP4)
Verification MUST preserve envelopes across export/import and signal degradation when fields are lost.
Failure modes:
- provenance stripping across systems
- semantic drift of metadata
Verification tools are accessible without requiring expert knowledge, with progressive disclosure for advanced users.
Systems MUST provide:
- simple indicators for common cases (valid/invalid/unknown)
- drill-down views for signatures, chains, and evidence
- clear explanations of limits of verification
Failure modes:
- expert-only verification (users cannot act on signals)
- misleading indicators that overstate certainty
Provenance and signatures remain valid and interpretable across platforms and tools (DP7 alignment), with explicit degradation signaling.
This requires:
- standard formats for signatures and provenance
- mapping rules when systems differ
- signaling when verification cannot be preserved
Verification MUST not silently drop integrity guarantees during transfer.
Failure modes:
- silent degradation of verification across boundaries
- incompatible formats preventing validation
DP15 requires a coherent system layer that binds identity (DP1), data (DP4), governance (DP8), and AI (DP12) into a continuous verification lifecycle.
Core properties:
- Trust anchoring: identities and keys are attributable, with clear custody and revocation states
- End-to-end verification flow: artifacts can be verified at creation, storage, transmission, and use
- Propagation: provenance travels with artifacts; loss is explicitly signaled
- Auditability: logs, receipts, and attestations allow reconstruction of events
- Adversarial resilience: the system detects and contains tampering, forgery, and replay
Verification lifecycle:
1. Creation: artifact is signed/hashed with provenance envelope
2. Distribution: integrity preserved; intermediaries cannot alter without detection
3. Consumption: client verifies signatures, keys, and policy context
4. Audit: logs and receipts enable retrospective verification and dispute
Failure modes:
- broken chain of custody between stages
- replay/rollback attacks using old but valid artifacts
- cross-system loss of provenance without signaling
This layer ensures security claims are not merely present but continuously checkable under real conditions.
DP15 requires that security and provenance are not only visible but actionable within governance and participant agency systems (DP8, DP2).
Participants must be able to:
When verification fails, systems MUST:
Communities and governance bodies must be able to:
Systems SHOULD support:
Failure modes include:
Security and provenance exist within strong incentive gradients that often discourage their full implementation.
Key structural tensions include:
Adversarial actors exploit these tensions:
DP15 requires realignment of incentives such that:
Systems SHOULD incorporate:
Failure modes include:
DP15 does not:
Minimum alignment defines the threshold at which security and provenance become reliable verification infrastructure rather than optional features.
A system claiming DP15 alignment MUST satisfy the following conditions:
Failure mode: implicit trust of unverified artifacts
Failure mode: provenance absence or stripping
Failure mode: unusable verification systems
Failure mode: log manipulation or selective disclosure
Failure mode: undetected key compromise
Failure mode: silent integrity loss across systems
Failure mode: AI attribution ambiguity
Failure mode: evidence opacity or loss
Systems that omit verification, provenance, or auditability MUST NOT be considered aligned with DP15.
DP15 assumes breach, key compromise, and manipulation attempts will occur.
Systems must predefine response pathways, including key rotation, participant notification, and audit procedures.
DP15 is where the meta-layer moves from claims to evidence.
Security without provenance is performative. Provenance without security is unreliable.
Together, they create a system where shared reality can be verified, contested, and trusted.
Related documents would appear here in the real datatracker.