coulomb/ops-warden
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify workload secret posture stewardship

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-27 18:22:09 +02:00
parent 32ae4f6851
commit 177e36d5a9
6 changed files with 178 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
INTENT.md
View File

@@ -10,8 +10,8 @@
## One-liner
**Operational access steward for the NetKingdom security model — knows the platform
credential lanes, keeps them aligned, and issues short-lived SSH certificates where
that lane belongs to ops-warden.**
credential lanes, keeps workload posture conformance aligned, and issues short-lived
SSH certificates where that lane belongs to ops-warden.**
---
@@ -28,6 +28,8 @@ That stack is easy to misuse:
- wrong subsystem chosen for a credential need (OpenBao vs warden vs key-cape)
- drift between NetKingdom architecture canon and what operators actually run
- ad hoc rediscovery of bootstrap and custody rules every time a worker needs access
- unclear security blockers because dev/test/prod posture and workload maturity are
not named before someone asks for real credentials
**ops-warden exists so operational access has a custodian-domain home** that
understands NetKingdom security infrastructure, routes workers to the right
@@ -54,14 +56,19 @@ owns one lane and points at the rest:
lanes — proxies the fetch *as the caller* (a transparent, policy-gated, audited
conduit that holds, caches, and logs **nothing**). This is the assist layer, not a
broker: custody stays in OpenBao, authorization in flex-auth.
3. **Align** runbooks, wiki, inventory patterns, and scorecard checks with
3. **Steward workload security posture conformance.** Author the ops-security slice
for environment posture (`dev/test/prod`) and workload maturity (`M0-M3`), then
ship descriptors and read-only checks that identify whether a secret-flow blocker
is real, owner-routed, or removable with a contract double. Runtime enforcement
remains flex-auth; custody remains OpenBao.
4. **Align** runbooks, wiki, inventory patterns, and scorecard checks with
NetKingdom canon as the platform evolves (OpenBao-first, flex-auth policy,
key-cape IAM Profile, railiance deployment layers).
4. **Issue** short-lived SSH certificates for `adm` / `agt` / `atm` actors when
5. **Issue** short-lived SSH certificates for `adm` / `agt` / `atm` actors when
host or ops reachability requires the SSH lane — via `warden sign`,
`cert_command`, and `ops-ssh-wrapper`. This is the **only** lane ops-warden
executes.
5. **Audit** SSH signing operations and cert-side compliance so gatekeeping is
executes with its own authority.
6. **Audit** SSH signing operations and cert-side compliance so gatekeeping is
observable, not tribal knowledge.
---
@@ -98,6 +105,8 @@ Canonical references:
- Actor inventory, TTL/principal policy, cert-side scorecard, signatures log
- `cert_command` contract and `ops-ssh-wrapper` automation surface
- Keeping ops-warden docs and patterns aligned with NetKingdom security evolution
- Workload Security Posture draft, conformance descriptors/checks, and dev-tier
contract-double guidance for secret-flow readiness
### ops-warden instructs but does not own
@@ -208,12 +217,15 @@ ops-warden is succeeding when:
4. NetKingdom security evolution (OpenBao, IAM Profile, bootstrap lanes) is
reflected in ops-warden docs within the same maintenance cycle.
5. Non-SSH secrets remain **out of ops-warden storage** — only documented paths.
6. Security blockers can be classified by environment posture, workload maturity,
owner route, and non-secret evidence instead of by vague credential risk.
---
## Non-goals
- Universal credential broker for all secret types
- Runtime enforcement of the workload secret-flow lattice (flex-auth owns that)
- Replacing OpenBao, flex-auth, key-cape, or railiance deployment ownership
- Storing Inter-Hub, LLM provider, or other long-lived API keys
- Host-side SSH configuration deployment
@@ -232,7 +244,8 @@ flex-auth integration design, and NetKingdom cross-links — without collapsing
platform boundaries.
See `wiki/CredentialRouting.md` for worker-facing routing,
`wiki/WorkloadSecurityPosture.md` for the posture/maturity conformance model,
`wiki/NetKingdomSecurityMap.md` for component literacy,
`history/2026-06-18-post-wp0008-intent-scope-reassessment.md` for the latest
gap analysis (production SSH path verified), and archived workplans WP-0006–0008
for stewardship and production closeout execution.
for stewardship and production closeout execution.

51
SCOPE.md
View File

@@ -10,12 +10,12 @@
Operational access steward for the NetKingdom security model — issues short-lived
SSH certificates for `adm`/`agt`/`atm` actors, documents how to obtain other
credential types from the right platform subsystems, and keeps ops access guidance
aligned with NetKingdom canon.
credential types from the right platform subsystems, stewards workload security
posture conformance, and keeps ops access guidance aligned with NetKingdom canon.
---
## Where we are (2026-06-24)
## Where we are (2026-06-27)
ops-warden **issues short-lived SSH certificates and routes every other credential
need to the subsystem that owns it.** SSH signing is **production-verified** on
@@ -27,6 +27,16 @@ NetKingdom security map, machine-readable pointer catalog
(`registry/routing/catalog.yaml`, WP-0010), and `warden route` lookup CLI
(`list`/`show`/`find`, `--json`, WP-0011).
**Operator access assist** is shipped (WP-0014): `warden access` gives advisory
handoffs for every catalog need and can proxy `exec_capable` lanes as the caller,
without taking custody of values.
**Workload security posture** is drafted (WP-0015 T1): dev/test/prod environment
posture, M0-M3 workload maturity, the secret-flow lattice, and blocker triage
language. Machine-readable descriptors and `warden policy list|show` shipped in
WP-0015 T2; the read-only conformance checker and dev contract doubles remain
WP-0015 follow-up tasks.
**Policy gate** is shipped on the caller side (WP-0007) with production registry
and smoke evidence (WP-0009 archived). flex-auth published the `ssh-certificate`
policy package (FLEX-WP-0006). `policy.enabled` remains **false** in production
@@ -38,14 +48,14 @@ runtime deployment (not ops-warden code), and operator hygiene.
### Issue vs route
ops-warden executes exactly one lane and points at the owner for the rest.
ops-warden executes exactly one lane with its own authority and routes/assists the rest.
| Need | Subsystem | ops-warden role |
| --- | --- | --- |
| SSH cert for host/ops access (`adm`/`agt`/`atm`) | **ops-warden** | **Issue** (`warden sign`) |
| API key / DB cred / dynamic lease | OpenBao | Route — point at path |
| "May I perform action X?" | flex-auth | Route — point at policy |
| Login / OIDC / MFA | key-cape / Keycloak | Route — point at IAM Profile |
| API key / DB cred / dynamic lease | OpenBao | Assist — route; proxy as caller only for `exec_capable` lanes |
| "May I perform action X?" | flex-auth | Route — point at policy; consume decisions where configured |
| Login / OIDC / MFA | key-cape / Keycloak | Assist — route; proxy `login` lane when `exec_capable` |
| SSH tunnel / port forward | ops-bridge | Route — supply `cert_command` |
| Host principal deployment | railiance-infra | Route — point at Ansible |
@@ -67,6 +77,7 @@ Gap analysis: `history/2026-06-24-intent-scope-gap-analysis.md` (current);
| ops-bridge integrates via stable `cert_command` | **Partial** — contract yes; tunnels still static-key |
| NetKingdom evolution reflected in docs | Met |
| Non-SSH secrets stay out of ops-warden | Met |
| Workload posture / maturity model for secret-flow blockers | Drafted (WP-0015 T1); conformance tooling pending |
**Maturity vector:** `D5 / A5 / C4 / R3` (Discovery / Availability / Completeness / Reliability)
@@ -121,6 +132,8 @@ for the rest.
- Capability registry entry for SSH certificate issuance
- Routing pointer catalog (`registry/routing/catalog.yaml`)
- Keeping ops access patterns consistent with `net-kingdom` platform architecture
- Workload Security Posture draft (`wiki/WorkloadSecurityPosture.md`) and planned
machine-readable posture descriptors, conformance checks, and dev-tier doubles
### Shipped workplans (archived)
@@ -140,6 +153,7 @@ for the rest.
| WP | Status | Focus |
| --- | --- | --- |
| **WP-0012** | `active` | Routing scenario playbooks (catalog + wiki expansion) |
| **WP-0015** | `active` | Workload security posture: env posture, maturity, conformance, dev doubles |
### Known gaps (not ops-warden workplans)
@@ -150,16 +164,19 @@ for the rest.
| ops-bridge `cert_command` on live tunnels | ops-bridge | Playbook shipped (`wiki/playbooks/ops-bridge-tunnel-cert.md`); pilot pending |
| Principals sync warden ↔ railiance-infra | ops-warden + infra | `scripts/check_principals_drift.py` — operator runs periodically |
| NK-WP-0009 joint SSH tutorial | net-kingdom | Parallel coordination track |
| WP-0015 conformance checker/dev doubles | ops-warden | T3-T4 pending; canon landing tracked in T5 |
---
## Out of Scope
- **Issuing** non-SSH secrets (API keys, DB creds, S3 STS, Inter-Hub keys) → OpenBao
with flex-auth policy where required; ops-warden documents paths only
- **Issuing or custodying** non-SSH secrets (API keys, DB creds, S3 STS,
Inter-Hub keys) → OpenBao with flex-auth policy where required; ops-warden
documents paths and may proxy caller-authenticated `exec_capable` lanes only
- Identity / OIDC / MFA → key-cape, Keycloak
- Authorization policy decisions → flex-auth
- flex-auth runtime deployment → flex-auth (`FLEX-WP-0007`)
- flex-auth runtime deployment and secret-flow lattice enforcement → flex-auth
(`FLEX-WP-0007` and follow-ups)
- Tunnel lifecycle → `ops-bridge`
- Host principal deployment → `railiance-infra`
- OpenBao / Vault cluster deployment → `railiance-platform`
@@ -178,6 +195,8 @@ for the rest.
- Inter-Hub or bootstrap tasks need a **short-lived agent SSH envelope**
- Checking cert-side compliance (scorecard)
- Enabling or testing the opt-in flex-auth policy gate
- Classifying whether a credential blocker is a dev/test double, owner-routed prod
gate, or maturity/posture violation
---
@@ -197,7 +216,8 @@ for the rest.
- **Access routing:** WP-0010 + WP-0011 shipped (`warden route`, pointer catalog)
- **Policy gate:** caller shipped (WP-0007); registry + smoke complete (WP-0009 archived).
`policy.enabled: false` until flex-auth reachable (`FLEX-WP-0007`)
- **Active work:** WP-0012 (routing playbooks — T2/T3 done)
- **Active work:** WP-0012 (routing playbooks — T2/T3 done) and WP-0015
(workload posture T1/T2 done, T5 in progress; checker/dev doubles pending)
- **Integration docs:** cert_command migration, token hygiene, principals drift (`wiki/playbooks/`)
- **Latest assessment:** `history/2026-06-24-intent-scope-gap-analysis.md`
@@ -228,7 +248,10 @@ Downstream: `ops-bridge` (primary), kaizen agents, CI automations, human operato
- `cert_command`: shell command returning a cert on stdout
- `inventory.yaml`: actor → principals + TTL registry
- `LocalCA` / `VaultCA`: signing backends (`backend: local` | `vault`)
- Pointer catalog: `registry/routing/catalog.yaml` — subsystem ownership lookup only
- Pointer catalog: `registry/routing/catalog.yaml` — subsystem ownership lookup plus
secret-free `warden access` handoff metadata
- Workload Security Posture: env posture (`dev/test/prod`) plus maturity (`M0-M3`)
used to decide whether a secret may flow to a workload
---
@@ -268,6 +291,7 @@ keywords: [ssh, certificate, ca, credential, warden, ops-warden, pki, openbao, v
| `wiki/AccessRouting.md` | What ops-warden issues vs routes vs assists (role and boundary) |
| `wiki/OperatorAccessAssist.md` | `warden access` front door + conduit-vs-broker boundary + guardrails |
| `wiki/CredentialRouting.md` | Which subsystem for each credential need |
| `wiki/WorkloadSecurityPosture.md` | Secret-store posture, workload maturity, and blocker triage |
| `registry/routing/catalog.yaml` | Machine-readable routing pointer catalog |
| `wiki/NetKingdomSecurityMap.md` | Platform security component map |
| `examples/warden.production.example.yaml` | Production warden.yaml template |
@@ -276,7 +300,8 @@ keywords: [ssh, certificate, ca, credential, warden, ops-warden, pki, openbao, v
| `wiki/OpsWardenConfig.md` | warden.yaml and OpenBao |
| `wiki/CertCommandInterface.md` | cert_command contract |
| `history/2026-06-24-intent-scope-gap-analysis.md` | Current gap analysis + WP-0013 |
| `history/2026-06-27-workload-security-posture-charter.md` | WP-0015 posture/conformance charter |
| `history/2026-06-18-post-wp0008-intent-scope-reassessment.md` | SSH lane gap analysis |
| `history/2026-06-18-access-routing-intent-shift-assessment.md` | Routing charter decision |
| `history/2026-06-23-flex-auth-policy-gate-production-smoke.md` | Policy gate smoke evidence |
| `net-kingdom/docs/platform-identity-security-architecture.md` | Platform security canon |
| `net-kingdom/docs/platform-identity-security-architecture.md` | Platform security canon |

53
history/2026-06-27-workload-security-posture-charter.md Normal file
View File

@@ -0,0 +1,53 @@
# Workload Security Posture Charter
Date: 2026-06-27
Workplan: WARDEN-WP-0015
## Decision
ops-warden will steward the NetKingdom workload security posture model as an
author-and-conformance surface, not as runtime enforcement or secret custody. The
model has two orthogonal axes:
- environment posture: `dev`, `test`, `prod` secret-store posture;
- workload maturity: `M0` through `M3`, describing whether a workload may receive
increasingly sensitive secrets/data.
The axes combine in a secret-flow lattice. A real secret may flow only when the
workload is in prod posture, the workload maturity meets the secret's
`required_maturity`, and the maturity meets the floor implied by the secret's data
classification.
## Boundary
This expands ops-warden's stewardship role without expanding secret custody:
- OpenBao holds secret values.
- flex-auth makes allow/deny decisions and is the eventual runtime enforcement point
for the lattice.
- key-cape/Keycloak establish identity.
- CARING governs access semantics.
- ops-warden issues SSH certificates, routes/assists other credential lanes, and
checks conformance evidence.
`warden access` from WP-0014 remains valid under this model because it is a
transparent conduit: it runs the owning tool as the caller, does not hold a standing
credential, does not persist values, and records metadata-only audit evidence.
## Why it matters
The model turns vague IT-security blockers into named outcomes:
- dev/test work can proceed with synthetic contract doubles rather than waiting for
production secrets;
- production work with real values must name owner custody, policy gate, posture,
maturity, and non-secret evidence;
- maturity below a secret's requirement remains a real blocker until the workload or
design changes;
- operator ceremonies such as prod OpenBao unseal and issuer custody remain hard
gates and must not be bypassed with agent-visible secret values.
## Follow-up
WARDEN-WP-0015 continues with the read-only conformance checker, dev-tier contract
doubles, and coordinated canon landing in net-kingdom and info-tech-canon.

55
wiki/CredentialRouting.md
View File

@@ -6,9 +6,12 @@ Use this page when a development worker (human, kaizen agent, CI job, or
custodian tool) needs **access or credentials** and is unsure which subsystem
owns the request.
ops-warden maintains this routing guide. It **issues SSH certificates only**.
For every other credential type, follow the routed path — do not paste secrets
into Git, State Hub, agent chat, or workplans.
ops-warden maintains this routing guide. It **issues SSH certificates directly**.
For every other credential type, use the routed owner path. `warden access` may
also **assist**: it renders the owner, auth method, path, and command shape and,
for `exec_capable` catalog lanes, can proxy the owner's tool **as the caller**.
That is a transparent conduit, not custody: do not paste secrets into Git,
State Hub, agent chat, or workplans.
---
@@ -28,12 +31,12 @@ What do you need?
+-- API key, DB password, provider token, K8s secret, dynamic lease
| -> OpenBao (after flex-auth approval where policy requires it)
| railiance-platform/docs/openbao.md
| NEVER ops-warden
| NEVER ops-warden as owner or store
|
+-- S3 / object-storage temporary credentials
| -> NK-WP-0007 vending path (flex-auth + OpenBao + storage STS)
| net-kingdom/docs/object-storage-sts-credential-vending.md
| NEVER ops-warden
| NEVER ops-warden as owner or store
|
+-- SSH certificate for host / ops reachability (adm/agt/atm)
| -> ops-warden (warden sign / cert_command)
@@ -49,7 +52,8 @@ What do you need?
```
**Under two minutes:** match your need to a branch above, open the linked doc,
stop if you landed on "NEVER ops-warden" for non-SSH secrets.
and treat non-SSH branches as owner-routed work. `warden access` can advise or
proxy an `exec_capable` lane, but it does not make ops-warden the owner of the value.
---
@@ -57,11 +61,11 @@ stop if you landed on "NEVER ops-warden" for non-SSH secrets.
| I need… | Subsystem | ops-warden role |
| --- | --- | --- |
| Interactive login, OIDC token, MFA | key-cape / Keycloak | Document only — use IAM Profile |
| "May I do X on resource Y?" | flex-auth (+ Topaz PDP) | Future pre-sign gate for SSH; document only today |
| OpenRouter / LLM provider API key | OpenBao → K8s Secret | **Do not** ask ops-warden |
| Inter-Hub operator / runtime API key | OpenBao or `0600` temp file | See `wiki/InterHubBootstrapAccessLane.md` |
| Database or service password | OpenBao dynamic/KV | Document only |
| Interactive login, OIDC token, MFA | key-cape / Keycloak | Assist: advise; proxy the `login` lane when the catalog entry is `exec_capable` |
| "May I do X on resource Y?" | flex-auth (+ Topaz PDP) | Route; policy gate for SSH/access proxies where configured |
| OpenRouter / LLM provider API key | OpenBao → K8s Secret | Assist: route; proxy only as caller when the catalog lane is `exec_capable` |
| Inter-Hub operator / runtime API key | OpenBao or `0600` temp file | Assist: route/custody notes; see `wiki/InterHubBootstrapAccessLane.md` |
| Database or service password | OpenBao dynamic/KV | Assist: route; proxy only as caller when the catalog lane is `exec_capable` |
| Short-lived SSH cert for operator | ops-warden (`adm-*`) | **Issue** via `warden sign` |
| Short-lived SSH cert for agent | ops-warden (`agt-*`) | **Issue** via `warden sign` / wrapper |
| Short-lived SSH cert for CI/cron | ops-warden (`atm-*`) | **Issue** via `warden sign` / `warden issue` |
@@ -74,16 +78,17 @@ stop if you landed on "NEVER ops-warden" for non-SSH secrets.
These needs are also carried in the machine-readable pointer catalog
(`registry/routing/catalog.yaml`, surfaced via `warden route` — WARDEN-WP-0011).
The catalog is a **pointer layer**: it names the owner and links the doc, it does
not restate the owner's procedure. Only the SSH row is something ops-warden
executes.
The catalog is a **pointer-and-assist layer**: it names the owner, links the doc,
and carries secret-free handoff templates for `warden access`. Only the SSH row is
something ops-warden executes with its own authority. Non-SSH `exec_capable` rows
run the owner's tool as the caller and preserve owner custody.
| Catalog `id` | What ops-warden answers | What the worker does next |
| --- | --- | --- |
| `ssh-cert-host-access` | **Issues** the cert (`warden sign`) | Use the cert / wire it into `cert_command` |
| `openbao-api-key` | "OpenBao owns this — here is the path" | Call OpenBao on the owning system |
| `openbao-api-key` | "OpenBao owns this — here is the path/command shape" | Call OpenBao directly, or use `warden access --fetch/--exec` as yourself when the lane is `exec_capable` |
| `flex-auth-policy-check` | "flex-auth decides — here is the policy doc" | Query flex-auth / embed the PEP |
| `key-cape-oidc-login` | "key-cape / Keycloak owns identity" | Authenticate via IAM Profile |
| `key-cape-oidc-login` | "key-cape / Keycloak owns identity" | Authenticate via IAM Profile, or use the `warden access` login lane as yourself |
| `ops-bridge-tunnel` | "ops-bridge owns transport — supply a `cert_command`" | Open the tunnel with ops-bridge |
| `railiance-infra-principals` | "railiance-infra deploys host principals" | Run the infra Ansible |
| `activity-core-issue-sink` | "activity-core + issue-core own emission — pair `ISSUE_CORE_*` env vars" | See `wiki/playbooks/activity-core-issue-sink.md` |
@@ -98,12 +103,13 @@ executes.
| `object-storage-sts` | NK-WP-0007 STS vending path | `wiki/playbooks/object-storage-sts.md` |
| `database-dynamic-credentials` | OpenBao database secrets engine | `wiki/playbooks/database-dynamic-credentials.md` |
ops-warden answers *where + who*; the worker acts on the owning system. ops-warden
never performs the non-SSH step on the worker's behalf.
ops-warden answers *where + who + how*. The worker still acts on the owning system.
When `warden access` proxies a non-SSH lane, it does so as the caller and stores no
value; the owner remains OpenBao, key-cape, flex-auth, or the routed subsystem.
---
## Examples — do NOT ask ops-warden
## Examples — do NOT ask ops-warden to own or vend
| Request | Correct path |
| --- | --- |
@@ -113,9 +119,11 @@ never performs the non-SSH step on the worker's behalf.
| "S3 credentials for artifact upload" | NK-WP-0007 / artifact-store consumer path |
| "JWT for my app" | key-cape / Keycloak IAM Profile |
**No duplicate interfaces.** Commands like `warden secret`, `warden login`,
`warden policy`, or `warden tunnel` do not exist and will not be added — each
belongs to another subsystem. The canonical anti-pattern table lives in
**No duplicate ownership.** Commands that would make warden a store, IdP, or
transport owner — `warden secret`, `warden bao`, `warden login` as an identity
service, or `warden tunnel` — do not exist. A future `warden policy` lookup, if
added by WARDEN-WP-0015, is metadata/conformance only; flex-auth remains the PDP.
The canonical anti-pattern table lives in
`wiki/AccessRouting.md#anti-patterns-not-coming-to-ops-warden`; it is not
restated here.
@@ -175,6 +183,7 @@ Report drift via custodian workplan or State Hub message to `ops-warden`.
- `INTENT.md` — steward mission
- `wiki/AccessRouting.md` — what ops-warden issues vs routes (role and boundary)
- `wiki/NetKingdomSecurityMap.md` — component literacy
- `wiki/WorkloadSecurityPosture.md` — dev/test/prod posture, M0-M3 maturity, and blocker triage
- `wiki/ActorInventoryPatterns.md` — actor naming
- `wiki/OpenBaoSshEngineChecklist.md` — production SSH signing verify
- `net-kingdom/docs/platform-identity-security-architecture.md` — platform canon
- `net-kingdom/docs/platform-identity-security-architecture.md` — platform canon

24
wiki/WorkloadSecurityPosture.md
View File

@@ -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 |

16
workplans/WARDEN-WP-0015-secret-lifecycle-tiering.md
View File

@@ -58,7 +58,8 @@ own process (inbox/PR), not a unilateral write from here.
**Depends on / relates to:** WARDEN-WP-0014 (the `warden access` proxy is the
posture-aware fetch surface; its caller-identity/transit guardrails are prod-compatible).
**Status:** `proposed` — awaiting Bernd's review before implementation.
**Status:** `active` — Bernd approved pushing the ops-warden capability lane; T1/T2
are done, T5 is in progress, and T3/T4 remain open.
---
@@ -187,19 +188,24 @@ state_hub_task_id: "e556fd2e-4e39-4c7d-bd94-b4330e4bef45"
```task
id: WARDEN-WP-0015-T05
status: todo
status: progress
priority: medium
state_hub_task_id: "298c9b09-4a5a-41bf-a3bd-6c572385236b"
```
- [ ] `INTENT.md`: ops-warden stewards **security-policy conformance** of the
- [x] `INTENT.md`: ops-warden stewards **security-policy conformance** of the
infrastructure (authoring the two-axis posture standard + conformance checks + dev
doubles), scoped to author+check — **not** enforcement or custody.
- [ ] SCOPE: add the posture policy + conformance surface; note the net-kingdom /
- [x] SCOPE: add the posture policy + conformance surface; note the net-kingdom /
info-tech-canon homes; bump the maturity vector where warranted.
- [ ] Track the info-tech-canon contribution (generic `WorkloadMaturityLevel`) and the
net-kingdom requirements landing to closure.
- [ ] `history/2026-06-27-workload-security-posture-charter.md` — decision record.
- [x] `history/2026-06-27-workload-security-posture-charter.md` — decision record.
2026-06-27 progress: updated `INTENT.md` / `SCOPE.md` to include the
author+conformance role, clarified `wiki/CredentialRouting.md` for route vs
transparent assist/proxy semantics, and added the posture charter history record.
Canon landing/tracking remains open.
---