Clarify workload secret posture stewardship

wiki/WorkloadSecurityPosture.md

@@ -85,6 +85,30 @@ prod-posture, M3 workload.
 
 ---
 
+## Using this to refine blockers
+
+When a workstream says "blocked on security", classify it before escalating. The
+classification decides whether the blocker is real, belongs to an owning subsystem, or
+can be removed by a dev/test double.
+
+| Question | Result |
+| --- | --- |
+| Is the work **dev** or **test** posture only? | Use synthetic contract doubles or generated test values. Do not wait on real production secrets. |
+| Is the work **prod** posture with real values? | Require owner custody (usually OpenBao), flex-auth policy where applicable, and non-secret evidence only. |
+| Is workload maturity below the secret's `required_maturity` or data-class floor? | This is a real IT-security blocker until the workload advances, the secret is reclassified, or the design avoids the secret. |
+| Does a route exist and the lane is `exec_capable`? | `warden access --fetch/--exec` may remove operator copy/paste as a blocker by proxying the owner's tool as the caller. |
+| Is unseal, break-glass, or issuer custody unresolved? | Keep it as an operator ceremony/design blocker; do not paper it over with agent-visible values. |
+
+The evidence to record is route id, owner, env posture, workload maturity,
+`required_maturity`, policy decision id, OpenBao path/version, populated-key count,
+smoke id, or token accessor. Never record the secret value.
+
+This is the practical bridge from WARDEN-WP-0014 (`warden access`) to WP-0015: access
+assist can remove manual secret handling friction, while posture/maturity decides
+whether the secret may flow at all.
+
+---
+
 ## Canon layering (where each part lands)
 
 | Part | Canonical home | ops-warden role |