docs: recognize ops-warden operational SSH credential lane

Add Operational SSH Path to platform architecture and move ops-warden
from out-of-scope to operational SSH dependency in responsibility-map.
Aligns with ops-warden WARDEN-WP-0006 stewardship work.

docs/platform-identity-security-architecture.md

@@ -214,6 +214,36 @@ identifies actors and workloads; flex-auth decides whether a credential
 or secret request is allowed; OpenBao stores, issues, audits, and revokes
 the resulting secret material.
 
+## Operational SSH Path
+
+Short-lived **SSH certificates** for host and ops reachability are a
+separate lane from OpenBao runtime secrets. ops-warden owns issuance;
+ops-bridge consumes certs for tunnels; railiance-infra deploys host trust
+and principals.
+
+```text
+Development worker (adm / agt / atm)
+        |
+        v
+ops-warden
+  actor inventory + TTL/principal policy
+  warden sign / cert_command / ops-ssh-wrapper
+  (signing via local CA or OpenBao SSH secrets engine API)
+        |
+        +-- ops-bridge (tunnel transport, cert_command consumer)
+        |
+        v
+SSH to host
+  principals matched via /etc/ssh/auth_principals/ (railiance-infra)
+```
+
+ops-warden also maintains **credential routing guidance** so workers do not
+mistake the SSH lane for OpenBao API keys or flex-auth policy decisions.
+Non-SSH credentials follow the Secret And Credential Path above.
+
+Future: flex-auth may gate `warden sign` before SSH engine signing
+(`ops-warden/wiki/PolicyGatedSigning.md`).
+
 ## Platform Root Custody
 
 Platform root authority is an accountable custody role, not a tenant admin role

docs/responsibility-map.md

@@ -133,6 +133,28 @@ their intent and do not appear in the resource map above.
 
 - `railiance-fabric` — tooling NetKingdom uses to provide an interface
 - `ops-bridge` — tunnel/transport tooling
+- `ops-warden` — operational SSH certificate authority and access-routing
+  stewardship (see Operational SSH dependency below)
+
+---
+
+## Operational SSH dependency (`ops-warden`)
+
+NetKingdom does not orchestrate ops-warden resources the way it orchestrates
+identity or OpenBao mounts, but the platform **depends** on ops-warden for the
+operational SSH credential lane:
+
+| | |
+| --- | --- |
+| **Resources held** | SSH actor inventory, signing policy (TTL/principals), cert-side audit (`signatures.log`) |
+| **Repo owns** | `warden` CLI, cert_command contract, ops-ssh-wrapper, stewardship runbooks |
+| **NetKingdom orchestrates** | Alignment with IAM actor model (`adm`/`agt`/`atm`); credential-routing canon so workers reach OpenBao/flex-auth/key-cape for non-SSH needs; NK-WP-0009 tutorial linkage |
+
+ops-warden is **post-minimal-bring-up** for platform bootstrap but **in scope**
+for ongoing dev-worker and agent SSH access. It must not become a universal
+secret broker — runtime secrets remain OpenBao; authorization remains flex-auth.
+
+Canon: `ops-warden/INTENT.md`, `ops-warden/wiki/CredentialRouting.md`.
 
 ---
 
@@ -143,8 +165,6 @@ Recorded so the scoping decision is explicit and revisitable:
 - `artifact-store` — artifact/object-storage **service** consumed by
   applications (platform-level storage is held by `railiance-platform`)
 - `railiance-apps` — applications
-- `ops-warden` — operational SSH-credential tooling (post-setup, not part
-  of minimal bring-up)
 - `railiance-enablement` — developer/CI tooling
 - all other domain repositories (application/business capabilities)