Close CCR drift and high-risk policy gaps

docs/credential-change-approval.md

@@ -74,6 +74,7 @@ Suggested states:
 
 ```text
 draft
+in_flight
 proposed
 needs_changes
 approved
@@ -89,6 +90,12 @@ superseded
 cancelled
 ```
 
+`in_flight` is the only state that may explicitly omit completion-only fields.
+It must declare every omission in `in_flight.missing_fields`, name the owner and
+blocking reason, and remain non-resolvable. The validator still checks every
+other field. This is not an applyable state and must never be used to hide a
+malformed active lane.
+
 Only `approved` requests may be applied. Only `verified` requests may become
 `active`.
 
@@ -141,6 +148,12 @@ Version 1 should be boring:
 - prompt or delegate separately for secret value entry;
 - record non-secret evidence in State Hub.
 
+When the schema adds or strengthens a required field, the same change must
+include a migration pass over every existing CCR. Active declarations must
+describe the live authentication path; incomplete requests must move to the
+explicit `in_flight` state rather than relying on a filename exception or a
+loosened repository-wide assertion.
+
 The first implemented CLI slice is:
 
 ```bash

docs/evidence/agent-high-risk-boundary-2026-08-21.md

@@ -0,0 +1,43 @@
+# Agent high-risk OpenBao boundary — 2026-08-21
+
+## Scope
+
+This is capabilities and metadata evidence for `RAILIANCE-WP-0022`. No
+credential value was read, no token was minted, and no operator role was
+modified.
+
+## Source and live coverage
+
+- State Hub message `828e4903-30fe-4903-acfd-cd2ecdda437d` reported that the
+  live `agent-high-risk-boundary` lacked the Core Hub path and that six other
+  concrete high-risk catalog paths were absent from both source and live.
+- Source now denies KV-v2 data and permits metadata only for all concrete
+  high-risk catalog paths. Pattern-only and non-KV lanes do not generate an
+  invented address.
+- Under attended `platform-admin` OIDC, OpenBao accepted the updated policy.
+  A normalized readback matched the source file.
+- The ops-warden audit used `policy_source: server` and reported 17 high-risk
+  lanes: 12 covered catalog entries, zero uncovered, and five with no concrete
+  KV address. The policy itself contains 12 unique deny paths because two
+  catalog entries share the Binky IMAP path and Core Hub is an additional
+  reviewed deny without a catalog lane.
+
+## Attachment audit and residual blocker
+
+A metadata-only scan listed and read role configuration under netkingdom OIDC,
+Kubernetes auth, AppRole, and token roles. It found:
+
+- roles attaching `agent-high-risk-boundary`: **0**;
+- roles combining it with any `workload-kv-read-*` policy: **0**.
+
+The live policy is therefore complete but is not automatically attached to a
+coding-agent identity. The documented manual short-lived token example is not
+a standing identity and carries no workload-read policy. Attaching the boundary
+to `platform-admin` would incorrectly constrain the attended operator role and
+erase the human/agent distinction, so that change was not made.
+
+The remaining work is an identity-owner decision: define a distinct coding-
+agent issuance path, attach the boundary, and prove that deny wins when a
+workload read policy is also present. A versioned generated list of concrete
+high-risk deny paths is also requested from ops-warden so policy coverage does
+not depend on manual catalog transcription.

docs/workload-kv-access-lanes.md

@@ -476,7 +476,8 @@ IONOS STARTTLS credentials and the shared user-engine ingest bearer for the
 | Policy file | `openbao/policies/workload-kv-read-email-connect-transactional.hcl` |
 | ESO policy | `external-secrets-email-connect` |
 | ESO policy file | `openbao/policies/external-secrets-email-connect.hcl` |
-| K8s auth role | `external-secrets-email-connect` (ESO delivery) |
+| Current ESO auth | policy-limited orphan token in Secret `external-secrets/openbao-email-connect-eso-token` |
+| K8s auth follow-up | role `external-secrets-email-connect` after the railiance01 auth mount is wired |
 | ClusterSecretStore | `openbao-email-connect` (namespace `email-connect` only) |
 | Primary consumer | ExternalSecret `email-connect/email-connect-runtime` → Secret `email-connect-runtime` |
 | Package manifests | `email-connect/deploy/k8s/railiance/` |