--- 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.**