diff --git a/README.md b/README.md
index d38ad48..13626d6 100644
--- a/README.md
+++ b/README.md
@@ -36,17 +36,23 @@ Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
 
 ## Status
 
-Draft. The Mode of Authority vocabulary is published as a canon artifact with
-machine-readable modes and dimensions; the v0.1 research draft is retained in
-`research/` as provenance. Stable promotion needs reviewed mappings and concrete
-consumer evidence. See
+Draft vocabulary, stable secrets standard. The Mode of Authority vocabulary is
+published as a canon artifact with machine-readable modes and dimensions; the
+v0.1 research draft is retained in `research/` as provenance. Stable promotion
+of that vocabulary needs reviewed mappings and concrete consumer evidence. See
 [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md).
 
+The [DevOps Secrets Management Standard](infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md)
+(`SEC-DSM` 1.0.0) is the normative secrets-practice guide. Gate House teaches it;
+ops-mason and ops-warden follow it. See
+[SECURITY-WP-0002](workplans/SECURITY-WP-0002-devops-secrets-management-standard.md).
+
 ## Orientation
 
 | Start here | For |
 | --- | --- |
 | [Vocabulary card](docs/vocabulary-card.md) | the seven modes and the notation, on one page |
 | [Mode of Authority](infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md) | the canon artifact |
+| [DevOps Secrets Management Standard](infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md) | the secrets-practice standard (`SEC-DSM` v1.0) |
 | [Disambiguation](docs/disambiguation.md) | *operator* or `OPERATE`? role, plane, or mode? |
 | [Mapping to InfoTechCanon](infospace/mappings/mode-of-authority-to-infotechcanon.md) | how it relates to the access-control model and CARING |
diff --git a/SCOPE.md b/SCOPE.md
index bff4ca5..aa9ba01 100644
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -10,6 +10,11 @@ mappings and orientation surfaces. SECURITY-WP-0001 is finished. The retained
 v0.1 research draft is historical, not the current orientation artifact. There
 is no service code; SEC-ADR-001 keeps validation in InfoTechCanon's service.
 
+It also publishes the DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) at
+`infospace/standards/devops-secrets-management/`. That standard states the
+normative secrets-management practice. It does not operate custody, issue
+credentials, or decide authorization. SECURITY-WP-0002 records the insertion.
+
 ## Ownership and boundaries
 
 Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and
@@ -26,8 +31,9 @@ Out of scope, with the owner named:
 - security architecture and standards of record for the estate — NetKingdom
 - authorization decisions — access-engine (runtime/product flex-auth)
 - login, OIDC, MFA — key-cape / Keycloak
-- credential lifecycle — secrets-engine over OpenBao custody; operational
-  routing and SSH certificates — ops-warden
+- credential custody and issuance — secrets-engine over OpenBao; operational
+  routing and SSH certificates — ops-warden. The practice those systems follow
+  is this canon's DevOps Secrets Management Standard; the operation stays theirs
 - adversarial evidence and findings practice — whitehat-security
 - shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
 - consumer runtime state, enforcement, observation, and adoption evidence — the consumers
@@ -42,6 +48,7 @@ The near-term deliverable is the architecture-layer vocabulary, not a migration.
 | Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` |
 | Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` |
 | Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` |
+| DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) | `SECURITY-WP-0002` |
 
 InfoTechCanon artifacts this canon **references rather than absorbs**:
 
diff --git a/decisions/decisions.md b/decisions/decisions.md
index 97309ca..0178b20 100644
--- a/decisions/decisions.md
+++ b/decisions/decisions.md
@@ -39,3 +39,28 @@ updated: '2026-09-20T20:20:00.000000Z'
 state_hub_decision_id: "054e60cc-c8df-4335-83d4-28fd438bb0a8"
 ```
 
+## SECURITY-DEC-2026-004 — Adopt the DevOps Secrets Management Canon v1.0 as SEC-DSM
+
+```yaml
+id: SECURITY-DEC-2026-004
+kind: decision
+title: 'Adopt DevOps Secrets Management Canon v1.0 as the SEC-DSM standard'
+status: accepted
+created: '2026-10-11T00:00:00.000000Z'
+updated: '2026-10-11T00:00:00.000000Z'
+```
+
+The repository owner supplied `DevOpsSecretsManagementCanon-v1.0.md` and asked
+that it be inserted as a standard. The body is stored unchanged at
+`infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md`,
+with a placement preface. Source SHA-256
+`ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f`.
+
+The standard is the secrets best-practice guide. It does not take custody,
+issuance, authorization, route construction, or lane operation away from their
+owners. Section 4 terms that InfoTechCanon already owns are practice language,
+not a second definition. Gate House, ops-mason, and ops-warden adopt it as
+their guide for secrets practice. Gate House's Active Secrets Management Canon
+v0.3 remains the estate doctrine for invariants, operating modes, and assurance
+tests that this standard does not replace.
+
diff --git a/infospace/interfaces/README.md b/infospace/interfaces/README.md
index 28bc92e..86c1715 100644
--- a/infospace/interfaces/README.md
+++ b/infospace/interfaces/README.md
@@ -11,11 +11,13 @@ under [accepted ADR-006](../../../the-custodian/canon/architecture/adr-006-canon
 - [commerce-canon interface](../../../commerce-canon/infospace/interfaces/federation.yaml)
 - [the-custodian interface](../../../the-custodian/canon/interfaces/federation.yaml)
 
-SecurityCanon exports one surface, `sec-authority`: the architecture-layer
+SecurityCanon exports two surfaces. `sec-authority` is the architecture-layer
 [Mode of Authority](../vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
-vocabulary. It imports shared roots from InfoTechCanon and redefines none of
+vocabulary. `sec-dsm` is the
+[DevOps Secrets Management Standard](../standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md).
+It imports shared roots from InfoTechCanon and redefines none of
 them; the [pinned manifest](../vocabulary/mode-of-authority/imports.json) records
-each source path and content hash at the declared commit.
+each vocabulary source path and content hash at the declared commit.
 
 Reciprocal navigation does not imply reciprocal semantic imports. InfoTechCanon
 retains the shared roots, CARING, the access-control model and the identity
diff --git a/infospace/interfaces/concept-placement.md b/infospace/interfaces/concept-placement.md
index 30b0600..d9ddef8 100644
--- a/infospace/interfaces/concept-placement.md
+++ b/infospace/interfaces/concept-placement.md
@@ -143,3 +143,13 @@ No concept is contested and no semantic disposition changes.
   and non-breaking; no SecurityCanon declaration changes. The blank cell in the
   mapping table stands — InfoTechCanon's access-control model still has no
   on-behalf-of relation.
+
+### Amendment — 2026-10-11, SEC-DSM insertion (SECURITY-DEC-2026-004)
+
+`sec-dsm:DevOpsSecretsManagementStandard` is a SecurityCanon-owned standard. It
+owns the secrets-practice requirements, the preference hierarchy, and the
+decision procedure. It does not add Principal, Authority, Capability, or Scope
+to SecurityCanon's owned concepts. The body's section 4 uses those words as
+practice language; the standard's preface records the reading. Secret and
+Credential remain practice terms until an upstream artifact owns them. No row
+in the placement table changes.
diff --git a/infospace/interfaces/federation.yaml b/infospace/interfaces/federation.yaml
index 1cb2808..a4fbedf 100644
--- a/infospace/interfaces/federation.yaml
+++ b/infospace/interfaces/federation.yaml
@@ -1,9 +1,9 @@
 id: security-canon/federation-interface
 title: SecurityCanon Federation Interface Card
 consumer: security-canon
-canon_surfaces: [sec-authority]
+canon_surfaces: [sec-authority, sec-dsm]
 status: draft
-version: 0.1.0
+version: 0.2.0
 owner: security-canon
 scope: >-
   SECURITY-WP-0001-T04 federation boundary. Publishes the architecture-layer
@@ -54,6 +54,23 @@ exports:
     availability: >-
       draft reference; adoption requires consumer review. No consumer adoption
       is recorded.
+  - artifact: sec-dsm
+    ledger_model: sec-dsm
+    kind: standard
+    path: infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
+    status: stable
+    version: 1.0.0
+    concepts:
+      - SecretsPreferenceHierarchy
+      - DynamicCredential
+      - ProducerCredential
+      - SecretsDecisionProcedure
+      - SecretsException
+    availability: >-
+      Stable practice standard. Gate House adopts it as the secrets best-practice
+      guide. ops-mason and ops-warden follow it. Custody and issuance stay with
+      secrets-engine; lane operation stays with ops-warden; route construction
+      stays with ops-mason.
 imports:
   - repository: info-tech-canon
     artifacts: [itc-core, itc-access, itc-ident, itc-org, itc-purposes]
@@ -62,8 +79,13 @@ imports:
     concepts: [Actor, Subject, Principal, Scope, AccessOperations, PrincipalType, Purpose]
 source_of_truth:
   vocabulary: security-canon
+  secrets_practice: security-canon (SEC-DSM)
   shared_roots: info-tech-canon
   implementation_layer: info-tech-canon (CARING)
+  estate_doctrine: gate-house
+  credential_custody: secrets-engine
+  route_construction: ops-mason
+  lane_operation: ops-warden
 mapping_rules:
   - Shared concepts retain their InfoTechCanon owner and are imported, never redefined.
   - Where concepts genuinely differ across layers, the names must visibly differ.
@@ -84,6 +106,10 @@ known_deviations:
     The G7 validator in prj-canon-federation pins card paths for info-tech-canon,
     commerce-canon and the-custodian only. Registering this card there is
     prj-canon-federation's change to make.
+  - >-
+    Section 4 of SEC-DSM uses Principal, Capability, and Authority as practice
+    language. Those concepts stay owned upstream. The standard's preface records
+    the reading. It does not add them to owned_concepts.
 expectations:
   - Review source changes and retain commit and content-hash provenance.
   - >-
diff --git a/infospace/standards/README.md b/infospace/standards/README.md
new file mode 100644
index 0000000..808dde9
--- /dev/null
+++ b/infospace/standards/README.md
@@ -0,0 +1,9 @@
+# Standards
+
+Tier-3 artifacts. A standard states what a practice must do. It imports shared
+roots and does not redefine them. See
+[SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md).
+
+| Standard | Path | Status |
+| --- | --- | --- |
+| DevOps Secrets Management (`SEC-DSM`) | [SecurityCanonDevOpsSecretsManagementStandard.md](devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md) | stable 1.0.0 |
diff --git a/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md b/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
new file mode 100644
index 0000000..11a1b5b
--- /dev/null
+++ b/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
@@ -0,0 +1,2165 @@
+---
+id: sec-dsm:DevOpsSecretsManagementStandard
+title: SecurityCanon DevOps Secrets Management Standard
+short_name: SEC-DSM
+type: standard
+standard_family: SecurityCanon
+repository_context: security-canon
+recommended_path: standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
+status: stable
+version: 1.0.0
+canonical_owner: SecurityCanonDevOpsSecretsManagementStandard
+namespace: sec-dsm
+classification: standard
+abstraction_layer: standard
+primary_cluster: secrets-management
+conformance_posture: normative
+imports:
+  - InfoTechCanonCore
+  - InfoTechCanonAccessControlModel
+  - InfoTechCanonIdentityModel
+  - InfoTechCanonOrganizationModel
+  - sec-authority:ModeOfAuthority
+related:
+  - sec-authority:ModeOfAuthority
+  - InfoTechCanonCaringAccessGovernanceStandard
+owned_concepts:
+  - SecretsPreferenceHierarchy
+  - DynamicCredential
+  - ProducerCredential
+  - SecretsDecisionProcedure
+  - SecretsException
+provenance:
+  source_file: DevOpsSecretsManagementCanon-v1.0.md
+  source_sha256: ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f
+  inserted: "2026-10-11"
+  insertion_decision: SECURITY-DEC-2026-004
+---
+
+# SecurityCanon DevOps Secrets Management Standard
+
+**Short name:** `SEC-DSM`
+**Document status:** Stable standard
+**Version:** 1.0.0
+**Repository context:** `security-canon`
+**Document type:** SecurityCanon domain standard
+**Conformance posture:** Normative (RFC 2119, as stated in the body)
+
+## Position in SecurityCanon
+
+This artifact is a Tier-3 standard. It states what a secrets-management practice must do. It does not operate custody, issue credentials, or render an authorization decision.
+
+SecurityCanon owns the practice requirements in the body (`DSM-*`), the preference hierarchy, and the decision procedure. Shared roots stay where [SEC-ADR-001](../../../docs/adr-001-securitycanon-boundary.md) and [concept placement](../../interfaces/concept-placement.md) put them. Section 4 of the inserted text uses Principal, Secret, Credential, and Capability as working language for this practice. That use does not transfer ownership and does not redefine the upstream concept:
+
+| Term in the body | How to read it here |
+| --- | --- |
+| Principal | The InfoTechCanon access-control Principal. This standard does not define a second one. |
+| Authority | The InfoTechCanon organization-model Authority. Auth Mode qualifies how it is exercised. |
+| Capability | The InfoTechCanon capability, used here as authority to perform an operation. Not a second Capability concept. |
+| Scope | The InfoTechCanon identity-model Scope, when the body means a boundary. A credential's "scope" in the ordinary engineering sense is the authority it grants, and the body says so in place. |
+| Secret, Credential | Practice terms for material whose disclosure grants or enables authority. No upstream artifact currently owns a competing definition. If one is later declared, this standard imports it. |
+| Identity Assertion | Practice term for short-lived evidence of identity. Identity itself stays in InfoTechCanon. |
+
+Estate application belongs to the consumers. Gate House teaches and supervises. secrets-engine materializes credentials. ops-mason builds routes. ops-warden operates lanes. A NetKingdom obligation that is stricter than this standard is the estate's to record. This standard is not edited to fit one estate.
+
+The body below is the inserted source, unchanged. Provenance file `DevOpsSecretsManagementCanon-v1.0.md`, SHA-256 `ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f`, adopted by SECURITY-DEC-2026-004 on 2026-10-11.
+
+---
+
+# DevOps Secrets Management Canon
+
+**Version:** 1.0  
+**Status:** Stable Canon  
+**Domain:** DevOps, Platform Engineering, Identity, Security, CI/CD, Runtime Operations
+
+---
+
+# 1. Purpose
+
+The DevOps Secrets Management Canon defines a technology-independent model and normative practices for managing credentials, cryptographic material, workload authentication, and secret-bearing capabilities across software-development and production environments.
+
+Its strategic objective is:
+
+> **Reduce persistent secrets to governed exceptions and prefer identity-mediated, short-lived capabilities wherever possible.**
+
+Secrets management is therefore not primarily a storage problem.
+
+It is the discipline of controlling an authority lifecycle:
+
+```text
+avoid
+  ↓
+identify
+  ↓
+authorize
+  ↓
+issue
+  ↓
+deliver
+  ↓
+consume
+  ↓
+renew / rotate
+  ↓
+expire / revoke
+  ↓
+detect
+  ↓
+recover
+  ↓
+audit
+```
+
+The desired end state is not a better collection of passwords.
+
+It is an environment in which principals authenticate through identity and receive narrowly scoped capabilities only for the time they require them.
+
+When a target can authorize a principal directly through trustworthy native or federated identity, that direct path is generally preferable to introducing an additional secret or credential broker.
+
+---
+
+# 2. Normative Language
+
+The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, **SHOULD NOT**, **MAY**, and **OPTIONAL** are to be interpreted according to BCP 14 / RFC 2119 and RFC 8174 when, and only when, they appear in uppercase.
+
+A **MUST** expresses a requirement necessary for full conformance unless an explicitly governed exception exists.
+
+A **SHOULD** expresses a strong recommendation that may be violated when the trade-off has been consciously evaluated and documented.
+
+A **MAY** expresses a legitimate implementation choice.
+
+---
+
+# 3. Scope and Intended Audience
+
+The canon applies to secrets and credential-like capabilities used by:
+
+- humans;
+- CI/CD pipelines;
+- build systems;
+- deployment systems;
+- applications;
+- containers;
+- Kubernetes workloads;
+- infrastructure automation;
+- autonomous or semi-autonomous agents;
+- service-to-service communication;
+- databases;
+- cloud providers;
+- third-party APIs;
+- signing systems;
+- certificate authorities;
+- recovery procedures.
+
+The canon is primarily intended for **production environments and non-trivial engineering organizations**.
+
+Smaller teams and early-stage systems SHOULD use the preference hierarchy, decision procedure, and Minimum Viable Adoption Profile without assuming they must immediately operate a full capability-broker architecture.
+
+The canon describes a **direction of travel**, not a requirement to maximize architectural sophistication regardless of cost.
+
+---
+
+# 4. Core Concepts
+
+## 4.1 Principal
+
+A **Principal** is an entity that may be authenticated.
+
+Examples include:
+
+- human;
+- CI job;
+- Kubernetes workload;
+- service;
+- repository;
+- deployment;
+- build agent;
+- autonomous agent.
+
+Principals SHOULD have individual identities rather than inheriting shared credentials.
+
+---
+
+## 4.2 Identity Assertion
+
+An **Identity Assertion** is short-lived evidence establishing the identity or relevant attributes of a principal.
+
+Examples include:
+
+- OIDC token;
+- projected Kubernetes ServiceAccount token;
+- SPIFFE SVID;
+- cloud workload-identity assertion;
+- hardware-backed human authentication.
+
+An identity assertion is not equivalent to an ordinary application secret.
+
+---
+
+## 4.3 Secret
+
+A **Secret** is information whose unauthorized disclosure grants, contributes to, or meaningfully enables authority not intended for the observer.
+
+Examples include:
+
+- password;
+- API token;
+- private key;
+- symmetric encryption key;
+- OAuth client secret.
+
+---
+
+## 4.4 Credential
+
+A **Credential** is material presented to establish identity or exercise authority.
+
+A credential MAY itself be secret.
+
+Credentials may be:
+
+```text
+static
+rotated
+leased
+ephemeral
+derived
+federated
+```
+
+---
+
+## 4.5 Capability
+
+A **Capability** is authority to perform a particular operation against a resource.
+
+Examples:
+
+```text
+read bucket X
+write table Y
+deploy service Z
+sign artifact A
+publish image B
+```
+
+A capability does not necessarily require possession of a persistent secret.
+
+---
+
+## 4.6 Dynamic Credential
+
+A **Dynamic Credential** is generated on demand for a particular consumer or execution and possesses a defined lifetime.
+
+Examples include:
+
+- temporary database account;
+- cloud STS credential;
+- SSH certificate;
+- short-lived X.509 certificate;
+- temporary access token.
+
+---
+
+## 4.7 Producer Credential
+
+A **Producer Credential** authorizes creation or issuance of other credentials.
+
+Examples include:
+
+- database administrator authority used by a broker to create temporary users;
+- CA signing authority;
+- cloud role capable of issuing temporary credentials.
+
+Producer credentials are intrinsically high-value assets.
+
+---
+
+## 4.8 Secrets Authority
+
+The **Secrets Authority** is the authoritative control plane responsible for one or more secret or credential lifecycles.
+
+A Secrets Authority MAY:
+
+- store secrets;
+- issue credentials;
+- broker capabilities;
+- rotate credentials;
+- revoke credentials;
+- enforce policy;
+- record audits.
+
+---
+
+## 4.9 Issuer
+
+An **Issuer** creates a credential or identity assertion.
+
+The issuer MAY differ from the Secrets Authority.
+
+For example:
+
+```text
+Secrets Authority → requests database credential
+Database          → creates database principal
+```
+
+or:
+
+```text
+CI platform → issues OIDC assertion
+Cloud STS   → issues temporary cloud credential
+```
+
+---
+
+## 4.10 Delivery Adapter
+
+A **Delivery Adapter** transports secret material from an authority to a consumer.
+
+Examples include:
+
+- direct API;
+- secrets agent;
+- CSI driver;
+- External Secrets Operator;
+- temporary filesystem;
+- injected environment variable.
+
+A delivery adapter MUST NOT implicitly be considered the authoritative source of the secret.
+
+---
+
+## 4.11 Root of Trust
+
+A **Root of Trust** is authority that cannot itself depend entirely upon the normal secrets-management hierarchy.
+
+Examples include:
+
+- HSM root key;
+- root CA;
+- recovery key;
+- bootstrap key;
+- platform-root authority.
+
+Roots of trust SHOULD be few, explicit, and exceptionally protected.
+
+---
+
+## 4.12 Standing Authority
+
+**Standing Authority** is authority available to a principal independently of an immediate task.
+
+Examples include:
+
+- long-lived API tokens;
+- persistent administrative accounts;
+- permanent cloud access keys;
+- broad agent credentials.
+
+Reducing standing authority is a primary objective of the canon.
+
+The preference hierarchy, maturity model, and exposure model should all be interpreted partly as mechanisms for reducing standing authority.
+
+---
+
+# 5. Preference Hierarchy
+
+Implementations SHOULD prefer mechanisms in the following order:
+
+```text
+1. Native identity with no transferable secret
+2. Federated / workload identity
+3. Ephemeral dynamically issued credential
+4. Automatically rotated credential
+5. Centrally managed static secret
+6. Manually managed static secret
+```
+
+Moving downward SHOULD require increasing justification.
+
+Moving upward generally reduces one or more of:
+
+- standing authority;
+- credential lifetime;
+- credential replication;
+- number of eligible consumers.
+
+This hierarchy is not absolute.
+
+The correct architecture is the **highest practical level that provides acceptable reliability, operational cost, compatibility, and security for the system concerned**.
+
+---
+
+# 6. Transitional and Constrained Environments
+
+Not every target supports federation, dynamic credentials, or modern workload identity.
+
+Typical constraints include:
+
+- legacy databases;
+- appliances;
+- old protocols;
+- third-party APIs exposing only static tokens;
+- SaaS platforms with manually generated API keys;
+- network devices;
+- software that reads credentials only during startup;
+- rate-limited or unavailable credential issuers.
+
+The canon does not require constructing elaborate intermediary systems merely to simulate ephemeral credentials where doing so creates more operational risk than it removes.
+
+## DSM-TRANS-001 — Highest Practical Mechanism
+
+A system **SHOULD** use the highest mechanism in the preference hierarchy that the target and operating environment can reliably support.
+
+## DSM-TRANS-002 — Govern the Residual Secret
+
+When a static credential cannot reasonably be eliminated, it **MUST** receive:
+
+- explicit ownership;
+- central authoritative storage;
+- minimum feasible scope;
+- rotation policy;
+- revocation procedure;
+- inventory coverage;
+- leak detection where practical.
+
+## DSM-TRANS-003 — Do Not Fake Dynamism
+
+A platform **SHOULD NOT** add complex credential issuance layers merely to claim dynamic-secret maturity when the resulting architecture increases failure probability without materially reducing authority, lifetime, or exposure.
+
+## DSM-TRANS-004 — Record Elimination Potential
+
+Persistent credentials **SHOULD** record whether elimination depends on:
+
+- target-system modernization;
+- vendor capability;
+- protocol migration;
+- platform work;
+- contract change;
+- application redesign.
+
+This turns persistent secrets into visible engineering debt.
+
+## DSM-TRANS-005 — Account for Issuer Dependency
+
+Systems using dynamic credentials **MUST** consider failure of the credential issuer.
+
+Relevant design concerns include:
+
+- issuer availability;
+- issuance latency;
+- rate limits;
+- lease renewal failure;
+- clock skew;
+- transient identity-provider failure;
+- dependency during disaster recovery.
+
+## DSM-TRANS-006 — Degraded Operation
+
+Where continued operation during issuer outage is necessary, the system **SHOULD** define a deliberate degraded-operation strategy.
+
+Examples include:
+
+- use of an already valid lease until expiry;
+- local credential-agent caching within bounded TTL;
+- fail-closed behavior;
+- tightly governed emergency credentials.
+
+Indefinite caching **MUST NOT** silently convert ephemeral credentials into persistent credentials.
+
+---
+
+# 7. Fundamental Requirements
+
+## DSM-ARCH-001 — Minimize Persistent Secrets
+
+Systems **MUST** attempt to eliminate persistent credentials when equivalent authority can be provided using native or federated identity.
+
+## DSM-ARCH-002 — Static Secrets Are Exceptions
+
+Long-lived static credentials **MUST** be treated as managed exceptions rather than the preferred authentication mechanism.
+
+Each material static production secret **MUST** have:
+
+- owner;
+- purpose;
+- consumers;
+- authority;
+- rotation policy;
+- revocation procedure.
+
+## DSM-ARCH-003 — Separate Identity From Authority
+
+Authentication and authorization **MUST** be treated as separate decisions.
+
+Proof that a workload is `service-A` **MUST NOT** by itself imply unrestricted access to resources associated with `service-A`.
+
+## DSM-ARCH-004 — Separate Control Plane From Delivery
+
+The authoritative secrets-management system **SHOULD** be distinguishable from delivery mechanisms.
+
+Kubernetes Secrets, CI variables, mounted files, and environment variables **SHOULD NOT** be considered canonical sources when another authoritative system exists.
+
+## DSM-ARCH-005 — Optimize for Operability
+
+Security architecture **MUST** account for availability and operational failure.
+
+A theoretically stronger credential model **SHOULD NOT** be adopted without considering whether failures will cause teams to bypass it.
+
+---
+
+# 8. Developer Experience and Adoption
+
+Security mechanisms that are difficult to use create incentives for unmanaged credentials.
+
+The preferred mechanism SHOULD therefore also become the normal engineering path.
+
+## DSM-DX-001 — Secure Path of Least Resistance
+
+Platform teams **SHOULD** make the preferred identity and credential mechanism easier to adopt than unmanaged static secrets.
+
+## DSM-DX-002 — Golden Paths
+
+Organizations operating shared platforms **SHOULD** provide reusable integrations such as:
+
+- CI templates;
+- deployment templates;
+- workload-identity modules;
+- Terraform modules;
+- Helm components;
+- SDK helpers;
+- secrets-policy templates.
+
+## DSM-DX-003 — Self-Service
+
+Routine credential and identity provisioning **SHOULD** be self-service where policy permits.
+
+Security teams SHOULD NOT become a manual transport layer for ordinary application credentials.
+
+## DSM-DX-004 — Local Development
+
+The secrets architecture **SHOULD** define an explicit development workflow.
+
+Local development SHOULD prefer:
+
+- developer identity;
+- development-only authority;
+- temporary credentials;
+- local emulation.
+
+Production credentials SHOULD NOT be required for normal development.
+
+### Non-normative implementation note
+
+Where integration testing requires real external services, useful patterns include:
+
+- developer-scoped cloud roles;
+- short-lived developer credentials;
+- isolated test tenants;
+- sandbox APIs;
+- contract testing;
+- service emulation;
+- explicitly time-bounded and audited exceptional production access for debugging.
+
+Such mechanisms should preserve the separation between routine development and production authority.
+
+## DSM-DX-005 — Debuggability
+
+Identity and federation failures **SHOULD** be diagnosable without revealing secret values.
+
+Useful diagnostics include:
+
+- authenticated principal;
+- token issuer;
+- intended audience;
+- policy decision;
+- requested capability;
+- denial reason;
+- credential expiry.
+
+## DSM-DX-006 — Avoid Security Escape Hatches Becoming Defaults
+
+Break-glass tokens, personal access tokens, manually copied credentials, and similar compatibility paths **MUST NOT** become undocumented normal workflows.
+
+---
+
+# 9. Identity Practices
+
+## DSM-ID-001 — Unique Workload Identity
+
+Every security-relevant workload **SHOULD** possess its own identifiable runtime identity.
+
+Production workloads **MUST NOT** depend upon a shared generic credential where individual workload identity is technically practical.
+
+For systems claiming maturity level M3 or higher, unique workload identity is expected for applicable new production workloads unless an explicit exception exists.
+
+## DSM-ID-002 — Federated Authentication
+
+Workloads **SHOULD** authenticate using environmental or federated identity.
+
+Preferred mechanisms include:
+
+- OIDC;
+- cloud workload identity;
+- Kubernetes workload identity;
+- SPIFFE;
+- equivalent cryptographically verifiable identities.
+
+For systems claiming maturity level M3 or higher, federation or an equivalent non-static identity mechanism is expected for new integrations where supported by the target.
+
+## DSM-ID-003 — Eliminate Secret Zero
+
+A workload **SHOULD NOT** require a long-lived bootstrap secret merely to authenticate to the secrets-management system.
+
+## DSM-ID-004 — Human and Machine Identity Separation
+
+Human credentials and workload credentials **MUST** be distinguishable.
+
+Human credentials **MUST NOT** be embedded into automated workloads.
+
+Machine credentials **SHOULD NOT** routinely be used interactively by humans.
+
+---
+
+# 10. Authorization Practices
+
+## DSM-AUTH-001 — Least Authority
+
+Credentials and capabilities **MUST** provide only the authority required for their intended operation.
+
+## DSM-AUTH-002 — Contextual Scope
+
+Where supported, authorization **SHOULD** constrain:
+
+```text
+principal
+resource
+operation
+environment
+time
+```
+
+Additional useful attributes include:
+
+```text
+repository
+branch
+namespace
+deployment
+tenant
+runtime
+job
+commit
+```
+
+## DSM-AUTH-003 — Environment Isolation
+
+Development, staging, and production authority **MUST** be independently scoped.
+
+Compromise of a development credential **MUST NOT** inherently provide production authority.
+
+## DSM-AUTH-004 — Tenant Isolation
+
+Credentials crossing tenant security boundaries **MUST** be explicitly modeled and authorized.
+
+Shared credentials between independent tenants **MUST NOT** be used.
+
+---
+
+# 11. Issuance Practices
+
+## DSM-ISSUE-001 — Prefer Dynamic Issuance
+
+When a target permits credentials to be issued dynamically, dynamic issuance **SHOULD** be preferred over retrieval of persistent credentials.
+
+## DSM-ISSUE-002 — Shortest Practical Lifetime
+
+Dynamically issued credentials **MUST** have a bounded lifetime.
+
+TTL **SHOULD** approximate the expected duration of the task plus reasonable operational margin.
+
+## DSM-ISSUE-003 — Per-Execution Credentials
+
+Build jobs, deployment jobs, and autonomous-agent executions **SHOULD** receive credentials unique to the execution where supported.
+
+## DSM-ISSUE-004 — Producer Credential Protection
+
+Producer credentials **MUST** receive stronger protection than ordinary consumer credentials.
+
+They **SHOULD** use, where practical:
+
+- workload identity;
+- hardware protection;
+- automated rotation;
+- constrained network access;
+- highly restrictive policy.
+
+---
+
+# 12. Storage Practices
+
+## DSM-STORE-001 — Authoritative Storage
+
+Every persistent secret **MUST** have one identifiable authoritative source.
+
+## DSM-STORE-002 — Minimize Copies
+
+Secret replication **SHOULD** be minimized.
+
+Each additional persisted copy SHOULD be regarded as increased exposure surface.
+
+## DSM-STORE-003 — Encrypt at Rest
+
+Persisted secrets **MUST** be cryptographically protected at rest.
+
+Encryption keys **SHOULD** be governed independently from ordinary application access.
+
+## DSM-STORE-004 — No Plaintext Source Control
+
+Plaintext credentials **MUST NOT** be committed to version-control systems.
+
+## DSM-STORE-005 — Git-Encrypted Secrets
+
+Encrypted secrets **MAY** be stored in Git when declarative state provides a deliberate operational benefit.
+
+Such storage:
+
+- **MUST** use independently controlled encryption keys;
+- **MUST** support key rotation;
+- **SHOULD** restrict decryption to intended environments;
+- **MUST NOT** be confused with dynamic secrets management.
+
+---
+
+# 13. Delivery Practices
+
+## DSM-DELIV-001 — Prefer Direct Consumption
+
+Consumers **SHOULD** obtain capabilities directly from their authority or issuer when practical.
+
+## DSM-DELIV-002 — Minimize Persistence During Delivery
+
+Credentials **SHOULD** remain resident for the minimum practical duration.
+
+Preferred mechanisms include:
+
+```text
+memory
+ephemeral filesystem
+short-lived local agent
+direct request
+```
+
+## DSM-DELIV-003 — Environment Variables
+
+Environment variables containing high-value secrets **SHOULD** be avoided where safer delivery mechanisms exist.
+
+They **MAY** be used for compatibility with software requiring them.
+
+## DSM-DELIV-004 — Kubernetes Secret Replication
+
+Replication into Kubernetes Secret objects **SHOULD** occur only when required by the consuming workload or ecosystem.
+
+## DSM-DELIV-005 — Delivery Policy
+
+Delivery adapters **MUST NOT** broaden authority beyond the policy of the authoritative system.
+
+---
+
+# 14. Rotation Practices
+
+## DSM-ROT-001 — Rotation Policy
+
+Every persistent production credential **MUST** have a rotation policy.
+
+## DSM-ROT-002 — Automatic Rotation
+
+Credentials that can reliably be rotated automatically **SHOULD** be rotated automatically.
+
+## DSM-ROT-003 — Rotation Includes Adoption
+
+Rotation **MUST NOT** be considered complete merely because the authoritative value changed.
+
+Complete rotation consists of:
+
+```text
+issue
+→ distribute
+→ adopt
+→ validate
+→ revoke old
+```
+
+## DSM-ROT-004 — Zero/Low-Downtime Rotation
+
+Systems requiring continuous availability **SHOULD** support overlapping validity, dual credentials, or equivalent safe transition mechanisms.
+
+## DSM-ROT-005 — Dynamic Issuance Preferred
+
+Where practical, dynamic issuance **SHOULD** replace periodic static-secret rotation.
+
+---
+
+# 15. Expiry and Revocation
+
+## DSM-REV-001 — Bounded Validity
+
+Temporary credentials **MUST** expire automatically.
+
+## DSM-REV-002 — Explicit Revocation
+
+Security-significant credentials **SHOULD** support explicit revocation in addition to expiry.
+
+## DSM-REV-003 — Known Revocation Procedure
+
+Every persistent production credential **MUST** have a known method of revocation.
+
+## DSM-REV-004 — Compromise Response
+
+A credential suspected of disclosure **MUST** be considered compromised.
+
+Removing the exposed value from source code, logs, or configuration **MUST NOT** constitute sufficient remediation.
+
+The credential **MUST** be revoked or replaced.
+
+---
+
+# 16. Detection Practices
+
+## DSM-DETECT-001 — Secret Detection
+
+Repositories containing production software **MUST** use automated secret detection.
+
+## DSM-DETECT-002 — Layered Detection
+
+Secret detection **SHOULD** occur at multiple boundaries where practical:
+
+```text
+developer environment
+push
+repository
+CI pipeline
+logs
+artifacts
+runtime
+```
+
+## DSM-DETECT-003 — Push Prevention
+
+Organizations **SHOULD** prevent recognized credentials from entering source-control history where tooling can do so reliably.
+
+## DSM-DETECT-004 — Detection-to-Revocation
+
+Detection mechanisms **SHOULD** integrate with automated or semi-automated revocation procedures.
+
+A finding without a response mechanism is incomplete control.
+
+---
+
+# 17. CI/CD Practices
+
+## DSM-CI-001 — CI/CD Is Production Security Infrastructure
+
+Any CI/CD system able to modify production **MUST** be treated as production-grade security infrastructure.
+
+## DSM-CI-002 — OIDC/Federation
+
+CI jobs **SHOULD** exchange short-lived execution identity for external capabilities rather than use stored infrastructure credentials.
+
+This requirement is platform-independent and applies to systems such as GitLab CI, GitHub Actions, cloud-native build services, and other CI platforms capable of workload federation.
+
+## DSM-CI-003 — Pipeline Change Authority
+
+Authorization to modify security-relevant pipeline code **MUST** be considered capable of affecting the credentials obtainable through that pipeline.
+
+## DSM-CI-004 — Secret Masking Is Not Protection
+
+CI log masking **MUST NOT** be treated as sufficient protection of credentials.
+
+## DSM-CI-005 — Job-Scoped Credentials
+
+CI credentials **SHOULD** be scoped to individual jobs or executions and expire after execution completes.
+
+---
+
+# 18. Kubernetes Practices
+
+## DSM-K8S-001 — ServiceAccount Identity
+
+Kubernetes workloads **SHOULD** use workload identity rather than static application credentials wherever supported.
+
+## DSM-K8S-002 — Projected ServiceAccount Tokens
+
+Workloads requiring Kubernetes ServiceAccount tokens **SHOULD** use short-lived projected tokens obtained through the TokenRequest mechanism rather than legacy indefinitely valid ServiceAccount token Secrets.
+
+Tokens **SHOULD** be:
+
+- expiration-bound;
+- audience-bound where supported;
+- associated with the intended workload context.
+
+## DSM-K8S-003 — External Authority
+
+Kubernetes **SHOULD NOT** become the default authoritative store for organization-wide high-value secrets when a dedicated authority exists.
+
+## DSM-K8S-004 — Native Cloud Identity Before Secret Brokerage
+
+When the cloud platform can authorize a Kubernetes workload directly through native workload identity, that path **SHOULD** generally be preferred over routing the request through a secrets broker solely for credential issuance.
+
+For example:
+
+```text
+Pod identity
+   ↓
+cloud workload federation
+   ↓
+cloud API
+```
+
+may be preferable to:
+
+```text
+Pod
+ ↓
+secrets authority
+ ↓
+temporary cloud credential
+ ↓
+cloud API
+```
+
+when both provide equivalent policy and audit guarantees.
+
+## DSM-K8S-005 — External Secrets Operator
+
+External Secrets Operator **MAY** be used as synchronization and reconciliation infrastructure.
+
+Its use **MUST** deliberately define:
+
+- refresh behavior;
+- ownership;
+- deletion semantics;
+- target namespace;
+- access scope.
+
+## DSM-K8S-006 — Secrets Store CSI
+
+Secrets Store CSI or equivalent runtime mounting **SHOULD** be considered when applications can consume file-mounted credentials.
+
+Synchronization into Kubernetes Secret objects **SHOULD** remain disabled when unnecessary.
+
+## DSM-K8S-007 — Namespace Isolation
+
+Access to secret material **MUST** be scoped according to workload and namespace boundaries rather than assuming namespace membership alone implies authority.
+
+---
+
+# 19. Cryptographic Key Practices
+
+Credentials and data-encryption keys are related but distinct security objects.
+
+A typical envelope-encryption hierarchy may contain:
+
+```text
+KEK — Key Encryption Key
+ ↓
+DEK — Data Encryption Key
+ ↓
+encrypted application data
+```
+
+## DSM-KEY-001 — Non-Exportability
+
+High-value root keys, signing keys, and KEKs **SHOULD** be non-exportable where the workflow permits it.
+
+## DSM-KEY-002 — KMS/HSM
+
+Root signing, encryption, wrapping, and similar high-value keys **SHOULD** use dedicated KMS or HSM facilities appropriate to their risk.
+
+## DSM-KEY-003 — Cryptographic Operations Instead of Key Retrieval
+
+Applications **SHOULD** request cryptographic operations from trusted services rather than retrieve master keys when practical.
+
+For example:
+
+```text
+sign(data)
+unwrap(DEK)
+decrypt(small_payload)
+```
+
+is preferable to:
+
+```text
+get_root_private_key()
+get_KEK()
+```
+
+## DSM-KEY-004 — Local Key Material
+
+Applications **MAY** require temporary possession of key material such as DEKs when performing local high-volume encryption.
+
+Such key material **SHOULD**:
+
+- be narrowly scoped;
+- have bounded lifetime where practical;
+- avoid persistence;
+- be wrapped by independently controlled KEKs.
+
+## DSM-KEY-005 — Keyless Signing
+
+Software build and artifact-signing workflows **SHOULD** prefer ephemeral or keyless signing schemes where ecosystem compatibility permits.
+
+---
+
+# 20. Human Handling
+
+## DSM-HUM-001 — No Human Transport
+
+Humans **SHOULD NOT** normally act as the transport mechanism for production secrets.
+
+Examples include:
+
+```text
+password manager → CI variable
+chat → terminal
+ticket → Kubernetes Secret
+vault UI → .env
+```
+
+## DSM-HUM-002 — Human Readability
+
+Production credentials **SHOULD NOT** routinely require humans to view their plaintext value.
+
+## DSM-HUM-003 — Break Glass
+
+Emergency human access **MUST** use explicitly identified break-glass procedures.
+
+Break-glass activity **MUST** be:
+
+- exceptional;
+- attributable;
+- auditable;
+- time-bounded where practical.
+
+---
+
+# 21. Agents and Automated Systems
+
+## DSM-AGENT-001 — Agent Identity
+
+Autonomous and semi-autonomous agents **MUST** authenticate using distinguishable workload identities.
+
+## DSM-AGENT-002 — Per-Run Identity
+
+Where practical, agent executions **SHOULD** receive execution-specific identity.
+
+Agent identity **SHOULD** be distinguishable at least by:
+
+```text
+agent
+run/task
+environment
+authority context
+```
+
+## DSM-AGENT-003 — Short Agent Identity Lifetime
+
+Agent identity and derived capabilities **SHOULD** have short bounded lifetimes related to task execution.
+
+Capabilities **SHOULD** expire or be revoked when the task:
+
+- completes;
+- fails;
+- is cancelled;
+- loses authorization.
+
+## DSM-AGENT-004 — No Embedded Master Credential
+
+Agents **MUST NOT** receive persistent platform-wide master credentials merely because their behavior is dynamic.
+
+## DSM-AGENT-005 — Capability Brokerage
+
+Agents **SHOULD** request narrowly scoped capabilities when required rather than maintaining broad standing authority.
+
+## DSM-AGENT-006 — Deterministic Enforcement
+
+Security boundaries controlling agent access to secret-bearing capabilities **MUST** use deterministic policy enforcement.
+
+LLM reasoning **MUST NOT** constitute the sole authorization mechanism.
+
+## DSM-AGENT-007 — Prevent Credential Accumulation
+
+Agent frameworks **MUST NOT** silently accumulate credentials across tasks.
+
+Credential caches, tool contexts, memory stores, workspaces, and execution sandboxes **SHOULD** be cleared or invalidated according to task lifecycle.
+
+## DSM-AGENT-008 — Tool Authority Is Agent Authority
+
+Authority reachable through an agent's tools **MUST** be included when evaluating the agent's effective security authority.
+
+This includes intermediate tool and service credentials that the model itself cannot inspect or retrieve.
+
+For example:
+
+```text
+agent
+  ↓
+tool A
+  ↓
+service B
+  ↓
+credential C
+  ↓
+system D
+```
+
+If use of tool A allows the agent to cause actions in system D through credential C, the resulting authority is part of the agent's effective authority.
+
+A hidden credential is not outside the security boundary merely because the model never sees its bytes.
+
+---
+
+# 22. Audit and Observability
+
+## DSM-AUDIT-001 — Audit Security-Relevant Operations
+
+The secrets or capability authority **MUST** record applicable:
+
+- authentication;
+- authorization;
+- retrieval;
+- issuance;
+- renewal;
+- rotation;
+- revocation;
+- administrative changes.
+
+## DSM-AUDIT-002 — Never Audit Plaintext Secrets
+
+Audit records **MUST NOT** contain plaintext secret values.
+
+## DSM-AUDIT-003 — Attribution
+
+Audit records **SHOULD** identify:
+
+```text
+principal
+resource
+operation
+policy context
+time
+result
+execution identity
+```
+
+## DSM-AUDIT-004 — Audit Integrity
+
+Security audit records **SHOULD** be protected from modification by systems and actors whose activity they record.
+
+High-assurance environments **SHOULD** export audit evidence to an independent security domain.
+
+## DSM-AUDIT-005 — Identity Failure Observability
+
+Authentication and federation failures **SHOULD** emit sufficient structured telemetry to diagnose:
+
+- issuer mismatch;
+- audience mismatch;
+- token expiration;
+- policy denial;
+- trust-chain failure;
+- lease failure;
+
+without disclosing credentials.
+
+---
+
+# 23. Roots of Trust and Recovery
+
+## DSM-ROOT-001 — Enumerate Roots
+
+Every deployment **MUST** identify its roots of trust.
+
+Unknown roots constitute an architecture defect.
+
+## DSM-ROOT-002 — Minimize Roots
+
+The number of roots of trust **SHOULD** be minimized.
+
+## DSM-ROOT-003 — Root Isolation
+
+Root credentials **MUST NOT** be handled through ordinary application secret-delivery mechanisms unless the mechanism is explicitly designed for that assurance level.
+
+## DSM-ROOT-004 — Recovery
+
+Recovery procedures **MUST** be documented and periodically tested.
+
+## DSM-ROOT-005 — Quorum for Extreme Authority
+
+Where feasible, operations capable of compromising the entire secrets hierarchy **SHOULD** require multi-party authorization.
+
+### Non-normative topology note
+
+High-assurance multi-region, multi-account, or multi-cluster deployments should explicitly model:
+
+- which roots are shared and which are independent;
+- cross-region or cross-account trust relationships;
+- issuer failure boundaries;
+- disaster-recovery trust bootstrap;
+- audit paths crossing administrative boundaries;
+- whether compromise of one cluster or account can mint authority in another.
+
+Replication should not accidentally turn one regional or cluster root into an undocumented global root.
+
+Independent audit sinks can be especially important where the same administrative plane controls several trust domains.
+
+---
+
+# 24. Inventory and Discovery
+
+## DSM-INV-001 — Secret Inventory
+
+Organizations **MUST** maintain an inventory of security-significant persistent credentials.
+
+## DSM-INV-002 — Inventory Attributes
+
+An inventory entry **SHOULD** contain:
+
+```yaml
+id:
+kind:
+authority:
+issuer:
+owner:
+consumers:
+environment:
+resources:
+operations:
+created_at:
+expires_at:
+rotation_policy:
+revocation_method:
+delivery_method:
+classification:
+maturity_level:
+discovery_source:
+verification_state:
+```
+
+## DSM-INV-003 — Ownership
+
+Every material production credential **MUST** have an accountable owner.
+
+## DSM-INV-004 — Automated Discovery
+
+Inventory **SHOULD** combine declared information with automated discovery where practical.
+
+Discovery sources MAY include:
+
+- secrets authorities;
+- CI variables;
+- cloud IAM;
+- Kubernetes;
+- repositories;
+- secret scanners;
+- runtime telemetry;
+- configuration systems.
+
+## DSM-INV-005 — Evidence State
+
+Inventory systems **SHOULD** distinguish between:
+
+```text
+declared
+discovered
+verified
+inferred
+unknown
+```
+
+information.
+
+Discovery MUST NOT silently be treated as complete inventory.
+
+## DSM-INV-006 — Discovered but Unowned
+
+A discovered production credential without a known owner **MUST** be treated as a security finding.
+
+It SHOULD be:
+
+1. contained if necessary;
+2. attributed;
+3. assigned an owner;
+4. revoked if no legitimate use is established.
+
+## DSM-INV-007 — Orphan Detection
+
+Secrets without known consumers **SHOULD** be investigated and revoked where legitimate use cannot be established.
+
+---
+
+# 25. Exception Management
+
+## DSM-EXC-001 — Explicit Exceptions
+
+Violation of a **MUST** requirement **MUST** be represented as an explicit exception.
+
+## DSM-EXC-002 — Exception Record
+
+An exception **MUST** record:
+
+```text
+requirement
+affected system
+reason
+owner
+risk
+compensating controls
+approval
+review/expiry date
+elimination path or review trigger
+```
+
+## DSM-EXC-003 — Exceptions Expire or Revalidate
+
+Security exceptions **SHOULD** have an expiration date or mandatory revalidation trigger.
+
+Permanent silent exceptions are prohibited.
+
+## DSM-EXC-004 — Elimination Path
+
+Where an exception represents technical debt, the record **SHOULD** state what event could remove it.
+
+Examples:
+
+```text
+vendor adds OIDC
+legacy database upgraded
+application migrated
+protocol retired
+new platform capability delivered
+```
+
+---
+
+# 26. Anti-Pattern Catalogue
+
+## DSM-AP-001 — Secrets in Git
+
+Plaintext credentials committed to source control.
+
+## DSM-AP-002 — CI Variable as Universal Vault
+
+The CI system becomes the indefinite organization-wide credential database.
+
+## DSM-AP-003 — Shared Production Account
+
+Unrelated workloads share a single production identity.
+
+## DSM-AP-004 — Vault Token Beside Application
+
+A permanent vault token is distributed to workloads to obtain other secrets.
+
+The secret-zero problem has merely moved.
+
+## DSM-AP-005 — Eternal API Token
+
+A third-party token has no owner, expiry expectation, rotation process, or revocation procedure.
+
+## DSM-AP-006 — Kubernetes as Universal Vault
+
+All organizational credentials are replicated into Kubernetes regardless of need.
+
+## DSM-AP-007 — Human Rotation Ritual
+
+Operators copy replacement credentials manually between multiple systems.
+
+## DSM-AP-008 — Rotation Without Adoption
+
+The authority changes the credential but consumers retain the previous value.
+
+## DSM-AP-009 — Deleting the Leak
+
+A credential is removed from Git or logs and considered trustworthy again without revocation.
+
+## DSM-AP-010 — Secret Scanning Without Response
+
+Secret detection creates findings but no response mechanism exists.
+
+## DSM-AP-011 — Masked Means Safe
+
+A credential is considered secure because CI log masking is enabled.
+
+## DSM-AP-012 — Developer Production Secret
+
+Developers routinely retain production credentials locally.
+
+## DSM-AP-013 — Root Everywhere
+
+The secrets broker uses broad producer authority where narrower delegation is practical.
+
+## DSM-AP-014 — One Credential Per Environment
+
+All workloads in an environment receive the same shared secret.
+
+## DSM-AP-015 — Secrets Manager as Generic Database
+
+The secrets platform becomes a generic configuration store, obscuring authority boundaries.
+
+## DSM-AP-016 — LLM Gatekeeper
+
+An LLM independently decides whether secret-bearing authority may be issued.
+
+## DSM-AP-017 — Permanent Agent Authority
+
+An autonomous agent receives broad standing credentials because future actions cannot be predicted.
+
+## DSM-AP-018 — Dynamic at Any Cost
+
+A complex dynamic-credential architecture is introduced despite low-value credentials, poor target support, severe reliability issues, and no meaningful reduction in standing authority.
+
+## DSM-AP-019 — Undebuggable Federation
+
+Identity failures are opaque, causing engineers to bypass workload identity using personal or static credentials.
+
+## DSM-AP-020 — Hidden Credential Through Tooling
+
+An agent, script, or platform appears credentialless while one of its tools or intermediate services exercises broad persistent credentials on its behalf.
+
+---
+
+# 27. Maturity Model
+
+Maturity SHOULD be assessed independently for:
+
+1. individual credentials;
+2. applications;
+3. platforms;
+4. organizational portfolios.
+
+An organizational maturity level **MUST NOT** conceal lower-level exceptions.
+
+Maturity levels describe dominant architectural practice, not the complete absence of lower-level mechanisms.
+
+---
+
+## DSM-M0 — Scattered
+
+Characteristics:
+
+- credentials in source trees;
+- local `.env` files;
+- manually managed CI variables;
+- shared accounts;
+- unclear owners;
+- inconsistent rotation.
+
+M0 is non-conformant for security-significant production credentials.
+
+---
+
+## DSM-M1 — Vaulted
+
+Characteristics:
+
+- secrets centralized;
+- encrypted at rest;
+- authenticated access;
+- basic access control;
+- reduced plaintext distribution.
+
+The organization has solved primarily **where secrets live**.
+
+---
+
+## DSM-M2 — Managed
+
+Characteristics:
+
+- documented lifecycle;
+- rotation;
+- secret detection;
+- defined revocation;
+- audit trails;
+- break-glass procedures;
+- orphan detection.
+
+The organization manages **secrets as governed assets**.
+
+---
+
+## DSM-M3 — Federated
+
+Characteristics:
+
+- workload identity established;
+- OIDC/workload federation common;
+- secret-zero patterns reduced;
+- human and machine identities separated;
+- new compatible workloads normally receive distinct machine identity.
+
+The organization increasingly manages **identities rather than passwords**.
+
+---
+
+## DSM-M4 — Ephemeral
+
+Characteristics:
+
+- dynamic database credentials;
+- short-lived certificates;
+- temporary cloud authorization;
+- job-specific capabilities;
+- automatic expiry;
+- explicit leasing and revocation.
+
+The organization manages **temporary authority**.
+
+---
+
+## DSM-M5 — Capability Brokered
+
+Characteristics:
+
+- standing credentials minimized;
+- workloads request capabilities rather than bags of secrets;
+- authorization uses identity and context;
+- high-value keys remain non-exportable where practical;
+- agents receive per-operation or per-task authority;
+- root credentials are highly isolated.
+
+The organization primarily manages **authority rather than secret material**.
+
+---
+
+# 28. Minimum Viable Adoption Profile
+
+The maturity model describes architectural evolution.
+
+It is not necessary to reach M3–M5 before gaining substantial security value.
+
+A team beginning at M0/M1 SHOULD first establish the following baseline.
+
+## DSM-CORE-1 — Minimum Viable Adoption
+
+For security-significant production systems:
+
+- no plaintext secrets in Git;
+- one identifiable authority for each persistent secret;
+- known owner;
+- known consumers where practical;
+- environment separation;
+- defined revocation method;
+- rotation policy;
+- automated secret scanning;
+- CI masking treated only as defense in depth;
+- development credentials separated from production;
+- explicit exceptions;
+- workload federation preferred for new integrations when readily available.
+
+This typically corresponds to a healthy **M2 trajectory**.
+
+## DSM-CORE-2 — Next Best Investment
+
+After DSM-CORE-1, teams SHOULD prioritize elimination of the credentials with the highest combination of:
+
+```text
+authority × lifetime × exposure × operational frequency
+```
+
+rather than attempting indiscriminate migration of every secret at once.
+
+---
+
+# 29. Measurement Model
+
+Metrics SHOULD distinguish what can be measured directly from what requires cross-system inference.
+
+## 29.1 Tier A — Authority-Native Metrics
+
+Usually straightforward to instrument:
+
+| Metric | Target |
+|---|---:|
+| Credentials with known owner | 100% |
+| Credentials with expiry metadata | ↑ |
+| Rotation success rate | → 100% |
+| Credentials issued dynamically | ↑ |
+| Credential TTL distribution | ↓ |
+| Revocation events | observable |
+| Failed issuance/renewal rate | low |
+| Active leases | observable |
+| Authentication failures | observable |
+
+## 29.2 Tier B — Cross-System Inventory Metrics
+
+Require correlation between several systems:
+
+| Metric | Target |
+|---|---:|
+| Credentials with identified consumers | 100% |
+| Shared production credentials | → 0 |
+| Orphaned credentials | → 0 |
+| Workloads using federation | ↑ |
+| CI variables containing credentials | ↓ |
+| Kubernetes Secret copies | ↓ where avoidable |
+| Static-to-ephemeral ratio | ↓ |
+
+## 29.3 Tier C — Exposure and Runtime Metrics
+
+Often require advanced discovery or telemetry:
+
+| Metric | Target |
+|---|---:|
+| Physical/logical copies per credential | ↓ |
+| Effective standing authority | ↓ |
+| Detection-to-revocation time | ↓ |
+| Runtime credential exposure duration | ↓ |
+| Unknown/unmanaged credential rate | → 0 |
+
+Tier C metrics SHOULD carry an explicit **coverage or confidence indication**.
+
+A metric based on 60% discovery coverage MUST NOT be presented as complete estate knowledge.
+
+---
+
+# 30. Exposure Model
+
+A useful conceptual risk proxy is:
+
+```text
+Exposure Risk
+    ∝
+authority
+× lifetime
+× copies
+× accessibility
+```
+
+Security controls therefore have four fundamental levers:
+
+```text
+reduce authority
+reduce lifetime
+reduce copies
+reduce eligible access
+```
+
+Standing authority is a particularly important combination of the first two dimensions: significant authority that remains continuously available creates exposure even while it is not actively being used.
+
+The preference hierarchy in Section 5 is valuable precisely because movement upward usually reduces several exposure dimensions simultaneously.
+
+Replacing a shared permanent cloud key with federated job identity, for example, can simultaneously reduce:
+
+- scope;
+- lifetime;
+- copies;
+- number of eligible consumers;
+- standing authority.
+
+---
+
+# 31. Tool Mapping
+
+The canon deliberately does not prescribe individual products.
+
+Tools occupy architectural roles.
+
+| Tool / Class | Authority | Identity | Dynamic issuance | Rotation | Delivery | Detection | Crypto |
+|---|---:|---:|---:|---:|---:|---:|---:|
+| OpenBao | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
+| HashiCorp Vault | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
+| GitLab Secrets Manager | ✓ | GitLab-native | partial | ✓ | ✓ | GitLab ecosystem | — |
+| CI OIDC issuers | — | ✓ | via federation | — | — | — | — |
+| AWS Secrets Manager | ✓ | IAM | target-dependent | ✓ | ✓ | — | KMS |
+| AWS STS | — | ✓ | ✓ | n/a | ✓ | — | — |
+| GCP Secret Manager | ✓ | IAM/WIF | target-dependent | ✓ | ✓ | — | KMS |
+| GCP Workload Identity | — | ✓ | ✓ | n/a | ✓ | — | — |
+| Azure Key Vault | ✓ | Entra | target-dependent | ✓ | ✓ | — | ✓ |
+| SPIFFE/SPIRE | — | ✓ | identity issuance | automatic | ✓ | — | PKI |
+| External Secrets Operator | — | workload | — | sync | ✓ | — | — |
+| Secrets Store CSI | — | workload | — | refresh | ✓ | — | — |
+| SOPS + age/KMS | encrypted state | key identity | — | external | GitOps | — | ✓ |
+| Sealed Secrets | encrypted state | cluster | — | limited | GitOps | — | ✓ |
+| Sigstore/Cosign | — | OIDC | signing identity | n/a | — | transparency | ✓ |
+| HSM/KMS | key authority | IAM | operations | ✓ | API | audit | ✓ |
+| Infisical | ✓ | ✓ | ✓ | ✓ | ✓ | integrations | varies |
+| Akeyless | ✓ | ✓ | ✓ | ✓ | ✓ | integrations | ✓ |
+| Doppler | ✓ | ✓ | target-dependent | ✓ | ✓ | integrations | — |
+| CyberArk | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | integrations |
+
+Capability presence does not imply equivalent assurance, maturity, or suitability.
+
+Tool capabilities also evolve independently of the canon. A tool mapping therefore SHOULD be treated as implementation guidance rather than a normative property of the canon.
+
+---
+
+# 32. Reference Architecture
+
+A high-maturity implementation may resemble:
+
+```text
+                    ┌───────────────────────┐
+                    │ HUMAN IDENTITY        │
+                    │ SSO / MFA / Hardware  │
+                    └───────────┬───────────┘
+                                │
+                                ▼
+┌────────────────────────────────────────────────────┐
+│                 IDENTITY PLANE                     │
+│                                                    │
+│ CI OIDC │ Kubernetes │ SPIFFE │ Cloud Workload ID │
+└───────────────────────┬────────────────────────────┘
+                        │ identity assertion
+                        ▼
+┌────────────────────────────────────────────────────┐
+│          POLICY / CAPABILITY CONTROL               │
+│                                                    │
+│ policy │ context │ least authority │ leases        │
+└───────────────────────┬────────────────────────────┘
+                        │
+          ┌─────────────┴─────────────┐
+          ▼                           ▼
+┌──────────────────┐         ┌──────────────────────┐
+│ SECRETS / CRED.  │         │ NATIVE IDENTITY     │
+│ AUTHORITY        │         │ TARGET               │
+│                  │         │                      │
+│ KV / PKI / DB /  │         │ Cloud IAM / API     │
+│ transit / lease  │         │ accepting federation│
+└────────┬─────────┘         └──────────────────────┘
+         │
+         ▼
+┌────────────────────────────────────────────────────┐
+│ DELIVERY                                           │
+│ Direct API │ Agent │ CSI │ ESO │ ephemeral file   │
+└───────────────────────┬────────────────────────────┘
+                        ▼
+┌────────────────────────────────────────────────────┐
+│ CONSUMERS                                          │
+│ CI │ workloads │ services │ agents │ humans        │
+└────────────────────────────────────────────────────┘
+
+
+┌───────────────────────┐
+│ ROOT OF TRUST         │
+│ KMS │ HSM │ Root CA   │
+│ quorum/recovery       │
+└──────────┬────────────┘
+           │ protects / anchors
+           └──────────────► identity, policy and secret planes
+
+
+All security-significant planes
+            │
+            ▼
+┌────────────────────────────────────────────────────┐
+│ INDEPENDENT AUDIT / SECURITY TELEMETRY             │
+│ immutable or independently protected where needed  │
+└────────────────────────────────────────────────────┘
+```
+
+The architecture explicitly permits two high-quality paths:
+
+```text
+identity → native target
+```
+
+and:
+
+```text
+identity → broker → issued capability → target
+```
+
+A broker SHOULD NOT be inserted merely because one exists.
+
+In multi-region, multi-account, or multi-cluster environments, the boundaries between identity, authority, roots of trust, and independent audit SHOULD be modeled explicitly rather than assumed to be global.
+
+---
+
+# 33. CI Platform Mapping
+
+The principles are CI-platform independent.
+
+A modern CI environment SHOULD attempt:
+
+```text
+job
+ ↓
+short-lived CI identity
+ ↓
+OIDC / federation
+ ↓
+target policy
+ ↓
+temporary capability
+```
+
+This pattern applies to:
+
+- GitLab CI;
+- GitHub Actions;
+- cloud build platforms;
+- self-hosted CI systems supporting OIDC or equivalent federation.
+
+Stored CI variables remain appropriate for compatibility cases, but SHOULD be treated as the lower part of the preference hierarchy rather than the architectural default.
+
+---
+
+# 34. GitLab-Oriented Mapping
+
+GitLab SHOULD be used as appropriate as:
+
+- CI workload-identity issuer;
+- repository policy boundary;
+- workflow and deployment authority;
+- secret-detection surface;
+- project/group secret authority where useful.
+
+GitLab Secrets Manager MAY be useful for:
+
+- project-level static secrets;
+- group-level secrets;
+- credentials tightly coupled to GitLab authorization;
+- targets incapable of dynamic issuance.
+
+GitLab CI variables SHOULD NOT become:
+
+- the organization-wide vault;
+- the default location for cloud master credentials;
+- the normal bootstrap mechanism for external secrets systems.
+
+GitLab OIDC SHOULD be preferred where supported for:
+
+```text
+GitLab → secrets authority
+GitLab → cloud IAM
+GitLab → deployment platform
+GitLab → federated external service
+```
+
+---
+
+# 35. OpenBao/Vault-Oriented Mapping
+
+A general-purpose secrets authority can provide:
+
+```text
+Secrets Authority
+Credential Broker
+Dynamic Credential Issuance
+PKI
+Cryptographic Transit
+Lease Management
+Revocation
+Audit Source
+```
+
+It SHOULD NOT automatically become the location for every item of sensitive configuration merely because it can store arbitrary values.
+
+The desired pattern remains:
+
+```text
+identity
+   ↓
+policy
+   ↓
+specific capability
+```
+
+rather than:
+
+```text
+application
+   ↓
+large bag of persistent secrets
+```
+
+---
+
+# 36. Kubernetes-Oriented Mapping
+
+A preferred decision path is:
+
+```text
+Kubernetes workload
+       │
+       ▼
+projected workload identity
+       │
+       ├──────────────► cloud/native federation ──► target
+       │
+       └──────────────► secrets authority
+                               │
+                               ├── dynamic credential
+                               └── required static secret
+                                       │
+                                 ┌─────┴─────┐
+                                 ▼           ▼
+                             direct/CSI     ESO
+                                             │
+                                             ▼
+                                      Kubernetes Secret
+```
+
+The **shortest trustworthy path** SHOULD generally be preferred.
+
+---
+
+# 37. Decision Procedure
+
+Whenever a new credential is proposed, the designer SHOULD answer the following questions in order.
+
+### Q1 — Can the operation use identity directly?
+
+If yes:
+
+**do not create a secret.**
+
+### Q2 — Can the target accept federated identity?
+
+If yes:
+
+**federate.**
+
+### Q3 — Can the target issue an ephemeral credential?
+
+If yes and operationally viable:
+
+**issue dynamically.**
+
+### Q4 — Can an existing static credential be automatically rotated?
+
+If yes:
+
+**manage and rotate it centrally.**
+
+### Q5 — Must a persistent static credential exist?
+
+If yes:
+
+**vault it and manage it explicitly.**
+
+Then determine:
+
+```text
+Who owns it?
+Who consumes it?
+What authority does it grant?
+How is it delivered?
+How many known copies exist?
+How is it rotated?
+How is it revoked?
+How is leakage detected?
+How is use audited?
+What happens if the issuer is unavailable?
+When could this credential be eliminated?
+```
+
+This decision procedure is the minimum conceptual implementation of the canon.
+
+---
+
+# 38. Conformance
+
+A system is **Fully Canon Conformant** when:
+
+1. all applicable **MUST** requirements are satisfied; or
+2. violations exist only as explicit DSM-EXC exceptions.
+
+A declaration SHOULD take the form:
+
+```text
+DevOps Secrets Management Canon v1.0
+
+System: payment-platform
+Adoption Profile: Full
+Maturity: DSM-M4
+
+Discovery Coverage:
+  declared/inventory: 100%
+  automated-discovery estimate: 87%
+  runtime-discovery estimate: 65%
+
+Exceptions:
+  - EXC-042 legacy-bank-api-token
+  - EXC-057 vendor-sftp-password
+```
+
+Discovery coverage SHOULD be included when materially incomplete discovery could affect the credibility of a maturity claim.
+
+Teams not yet ready for full conformance MAY instead declare:
+
+```text
+Adoption Profile: DSM-CORE-1
+```
+
+provided this is not represented as full canon conformance.
+
+---
+
+# 39. Portfolio Conformance
+
+Organizations SHOULD NOT claim a single maturity level without describing the distribution of authorities or credentials.
+
+A preferred representation is:
+
+```text
+M0   0%
+M1   4%
+M2  11%
+M3  27%
+M4  46%
+M5  12%
+```
+
+The distribution SHOULD ideally distinguish important credential classes.
+
+For example:
+
+```text
+Cloud workloads      M4
+Database access      M4
+Third-party SaaS     M2
+Legacy appliances    M1
+CI identity          M3
+Signing              M5
+```
+
+Portfolio declarations SHOULD state material discovery limitations.
+
+For example:
+
+```text
+Coverage:
+  managed authorities       98%
+  CI systems                100%
+  Kubernetes clusters        95%
+  third-party SaaS           70%
+  developer-held material    unknown
+```
+
+A maturity declaration describes what is known about the estate; it MUST NOT imply that unknown areas have been proven free of unmanaged credentials.
+
+---
+
+# 40. Non-Normative Framework Alignment
+
+This section is informational and does not establish compliance.
+
+The canon is broadly compatible with the direction of established security frameworks.
+
+## Zero Trust
+
+The strongest alignment is with zero-trust architecture principles:
+
+- authenticate explicitly;
+- authorize per request;
+- minimize implicit trust;
+- limit standing privilege;
+- use contextual policy;
+- prefer short-lived credentials.
+
+The M3–M5 progression can be seen as increasingly complete application of these ideas to machine and workload authority.
+
+## NIST Cybersecurity Framework
+
+Relevant themes include:
+
+- asset and identity awareness;
+- access control;
+- credential protection;
+- continuous monitoring;
+- detection;
+- incident response;
+- recovery.
+
+The canon adds a more specific credential-lifecycle and workload-identity model beneath those higher-level outcomes.
+
+## NIST SP 800-53
+
+The canon overlaps especially with control families concerned with:
+
+- access control;
+- identification and authentication;
+- audit and accountability;
+- configuration management;
+- system and communications protection;
+- incident response.
+
+It should not be treated as a replacement for an SP 800-53 control assessment.
+
+## ISO/IEC 27001
+
+Relevant areas include:
+
+- identity management;
+- authentication information;
+- access rights;
+- privileged access;
+- cryptography;
+- logging;
+- secure development;
+- configuration management;
+- incident management.
+
+The canon can provide an implementation-oriented secrets-management submodel beneath an ISO 27001 ISMS.
+
+## Compliance Principle
+
+Compliance frameworks tend to ask:
+
+> Is credential risk controlled?
+
+The canon additionally asks:
+
+> Why does this credential exist at all?
+
+That second question is what drives movement from M2 toward M3–M5.
+
+---
+
+# 41. Governing Principles
+
+The central design principle of this canon is:
+
+> **A persistent secret represents deferred identity or capability engineering.**
+
+Sometimes that debt is rational.
+
+Legacy systems exist. Third-party APIs expose fixed tokens. Recovery authorities cannot always be eliminated. Dynamic issuance can introduce real dependencies and operational cost.
+
+The canon therefore does not demand maximal machinery.
+
+Instead, every persistent secret should provoke these questions:
+
+> Why must this authority exist as a credential?  
+> Why must the credential persist?  
+> Why must its value be readable?  
+> Why must it be copied?  
+> Why must more than one principal possess it?  
+> What prevents us from moving it one level upward in the preference hierarchy?
+
+The desired long-term trajectory is:
+
+```text
+secret storage
+    ↓
+secret lifecycle management
+    ↓
+workload identity
+    ↓
+ephemeral credentials
+    ↓
+capability brokerage
+```
+
+But the operational rule is:
+
+> **Move authority upward only when the resulting system is both more secure and sustainably operable.**
+
+The end state of mature secrets management is not the elimination of every secret.
+
+It is the transition from managing secret material to:
+
+> **managing explicit, bounded, observable authority.**
\ No newline at end of file
diff --git a/workplans/SECURITY-WP-0002-devops-secrets-management-standard.md b/workplans/SECURITY-WP-0002-devops-secrets-management-standard.md
new file mode 100644
index 0000000..4c10f1c
--- /dev/null
+++ b/workplans/SECURITY-WP-0002-devops-secrets-management-standard.md
@@ -0,0 +1,47 @@
+---
+id: SECURITY-WP-0002
+type: workplan
+title: "Insert the DevOps Secrets Management Standard and point the staff at it"
+domain: infotech
+repo: security-canon
+status: finished
+owner: grok
+topic_slug: security-canon
+created: "2026-10-11"
+updated: "2026-10-11"
+---
+
+# DevOps Secrets Management Standard
+
+The repository owner supplied `DevOpsSecretsManagementCanon-v1.0.md` and asked
+that it be inserted as a standard, and that gate-house use it as the
+best-practice guide for secrets practice, with ops-mason and ops-warden guided
+by it. Recorded as SECURITY-DEC-2026-004.
+
+## Insert the standard
+
+```task
+id: SECURITY-WP-0002-T01
+status: done
+priority: high
+```
+
+Place the source, unchanged, at
+`infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md`
+with canon frontmatter and a placement preface. Publish it on the federation
+card as `sec-dsm` 1.0.0. Do not claim ownership of Principal, Authority,
+Capability, or Scope.
+
+## Point the staff at it
+
+```task
+id: SECURITY-WP-0002-T02
+status: done
+priority: high
+```
+
+Gate House names SEC-DSM as the secrets best-practice guide and keeps ASM v0.3
+for estate invariants, operating modes, and assurance tests. ops-mason's
+construction plans answer the standard's decision procedure before proposing a
+new credential. ops-warden's routing guide follows the same hierarchy and does
+not take custody of static secrets.