Finish coding-agent high-risk boundary coverage

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02669-87ee-7a31-b111-edc95a16e0fa

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

@@ -22,6 +22,23 @@ modified.
   catalog entries share the Binky IMAP path and Core Hub is an additional
   reviewed deny without a catalog lane.
 
+### 2026-08-22 generated-input reconciliation
+
+- Ops-warden delivered generated artifact revision
+  `55f0f47a021375b8b25c924953d1b49a24e002c5`: 19 high-risk lanes, 14
+  concrete entries (13 unique paths), and five pattern/non-KV lanes.
+- The corrected grades add issue-core runtime (whose bundle also contains
+  `GITEA_BACKEND_TOKEN`) and reuse-surface runtime (whose bundle also contains
+  `REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET`). Both data paths now have explicit
+  deny blocks and read-only metadata blocks.
+- `scripts/agent_high_risk_boundary.py` verified that the vendored input equals
+  the clean upstream artifact aside from generation time and that every entry
+  is covered. Forty-nine focused tests passed.
+- Under attended `platform-admin` OIDC, the policy was uploaded and read back.
+  OpenBao added only its normal trailing newline. The server-backed ops-warden
+  audit reported 19 high-risk lanes, 14 covered, zero uncovered, and five with
+  no concrete address.
+
 ## Attachment audit and residual blocker
 
 A metadata-only scan listed and read role configuration under netkingdom OIDC,
@@ -30,14 +47,33 @@ 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 2026-08-21 scan accurately found no attachment at that time. On 2026-08-22,
+State Hub decision `f0955252-7b20-4c80-86e9-f8080ec60793` selected the
+platform-owned `coding-agent-railiance-platform` AppRole as the operational
+machine identity while retaining the KeyCape JWT role as an issuer-backed
+migration target.
 
-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.
+Live AppRole metadata matched the reviewed source:
+
+- `bind_secret_id=true`, `secret_id_ttl=300`, and
+  `secret_id_num_uses=1`;
+- `token_ttl=900`, `token_max_ttl=900`, `token_num_uses=8`, and no default
+  policy;
+- policies exactly `agent-high-risk-boundary` and
+  `workload-kv-read-issue-core-runtime`.
+
+The non-disclosing verifier minted one ephemeral SecretID, logged in, and used
+only token metadata plus `sys/capabilities-self`. The data path resolved to
+`deny`; its metadata path resolved to `read`; the token TTL was 900 seconds.
+The first verification exposed that a no-default-policy token could not revoke
+itself. That bounded test token was located and revoked by accessor under
+attended authority, `auth/token/revoke-self:update` was added to the boundary,
+and the repeat verification passed and self-revoked without warning. No KV read
+was attempted and no SecretID, token, or protected value was printed or logged.
+
+The exact-bound JWT role `auth/netkingdom/role/coding-agent` was also applied
+with audience `codex-railiance-platform`, subject
+`service:codex:railiance-platform`, `principal_type=service`,
+`tenant=tenant:coulomb`, and role `coding-agent`. KeyCape client registration
+is a future identity-hardening handoff; it is not required for the live AppRole
+attachment proven here.