railiance-platform/workplans/RPF-WP-0013-agent-high-risk-boundary-coverage.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	related	origin	origin_ref	state_hub_workstream_id
RPF-WP-0013	workplan	Close agent high-risk OpenBao boundary coverage	financials	railiance-platform	finished	codex	railiance	2026-08-21	2026-08-22	WARDEN-WP-0032 RISK-F-0009	routed	State Hub message 828e4903-30fe-4903-acfd-cd2ecdda437d	25c0b1c9-a1b7-5844-bd39-9db165fe196c

RPF-WP-0013 — Agent high-risk boundary coverage

Goal

Make the OpenBao agent-high-risk-boundary deny every concrete high-risk KV data path in the ops-warden routing catalog, verify the deployed policy, and establish whether any agent identity actually carries the boundary.

Boundaries

• Read policy documents, token-role metadata and capabilities only; never read a Secret value.
• A deny is added only for a concrete catalog path graded risk: high.
• Pattern-only and non-KV lanes are reported but do not produce invented paths.
• Operator identities do not receive this boundary; it is for coding-agent identities where deny must override any coincident workload read policy.

T01 — Reconcile catalog coverage

id: RPF-WP-0013-T01
status: done
priority: high
state_hub_task_id: "35855316-3282-52d2-922e-43af1c4495c0"

Run the capabilities-only ops-warden audit against the policy. The initial 2026-08-21 reconciliation found 17 high-risk lanes: six covered, six concrete uncovered, and five without a concrete KV address. The final generated input contains 19 high-risk lanes, 14 concrete entries, and five without an address. No credential value was read.

T02 — Close the concrete deny gaps

id: RPF-WP-0013-T02
status: done
priority: high
state_hub_task_id: "9f2a6ffc-5f48-5e45-b636-76dff7d41743"

Add deny-data/read-metadata pairs for the six catalog paths: whynot-design npm, rapp-qonto Keycape client, agent-harness Forgejo deploy key, audit-core senders, email-connect transactional, and Scaleway bootstrap. Add regression coverage for every concrete path currently emitted by the catalog audit.

Completed 2026-08-22. After ops-warden corrected two multi-field grades, the source policy covers all 13 unique concrete catalog paths plus the additional reviewed Core Hub path. The generated-input check reports all 14 concrete catalog entries covered with none uncovered.

T03 — Apply and verify live

id: RPF-WP-0013-T03
status: done
priority: high
state_hub_task_id: "92b4b531-986d-54b4-a18b-cd8785dca5ce"

Under attended platform authority, upload the reviewed policy, read it back, and rerun the catalog audit with policy_source: server. Inspect policy/token role metadata to determine whether an agent identity carries the boundary and whether any role combines it with a workload-read policy. Do not mint a token.

Completed initially on 2026-08-21 and reconciled again on 2026-08-22 under attended platform-admin OIDC. OpenBao accepted the policy; normalized readback matched source, and the final server-backed audit reported 19 high-risk lanes, 14 covered entries, zero uncovered, and five pattern/non-KV lanes without a concrete address. No Secret value was read.

T04 — Route the result

id: RPF-WP-0013-T04
status: done
priority: medium
state_hub_task_id: "d394fcb7-1477-5dfe-9e4b-65bd14f08346"

Reply to ops-warden with the deployment evidence and remaining attachment finding. Request a generated, versioned concrete-deny artifact so future policy updates consume catalog output rather than relying on a hand-maintained list.

Completed 2026-08-21 via State Hub message fe727451-163a-4e14-8ce3-187fea8ce5b3, including live audit counts, the zero- attachment finding, the distinct-agent-identity blocker, and the requested versioned generated artifact shape.

Ops-warden delivered revision 55f0f47a021375b8b25c924953d1b49a24e002c5 on 2026-08-21. The platform now vendors it as a checked policy input and has a repeatable upstream-equality plus policy-coverage command.

T05 — Establish a distinct coding-agent identity

id: RPF-WP-0013-T05
status: done
priority: high
state_hub_task_id: "6805ef60-bd20-5549-b955-cee94eb69dad"

The policy is live but no role attaches it. Do not add the boundary to platform-admin: that is an attended human/operator role whose legitimate recovery work may require the protected values. The identity owner must define a distinct coding-agent issuance path, attach this boundary there, and prove deny-wins behavior when combined with an otherwise readable workload policy. Completed 2026-08-22. State Hub decision f0955252-7b20-4c80-86e9-f8080ec60793 establishes the platform-owned AppRole coding-agent-railiance-platform as the operational machine identity. Its single-use SecretIDs expire after five minutes; its tokens last at most 15 minutes, have eight uses, omit the default policy, and attach both agent-high-risk-boundary and the otherwise-readable issue-core workload policy. A live ephemeral login proved data capabilities resolve to deny and metadata to read; the token was revoked without reading the KV value.

The exact-bound KeyCape JWT role is also live as the issuer-backed migration target. KeyCape principal registration remains an identity hardening follow-up, not a blocker to the active AppRole boundary.

T06 — Consume the generated catalog artifact

id: RPF-WP-0013-T06
status: done
priority: high
state_hub_task_id: "1b0c4f03-0ec7-5fcc-908d-beed236e4865"

Consume ops-warden's versioned high-risk-data-paths.yaml as a policy-check input, add the two newly regraded issue-core and reuse-surface paths, and rerun source plus live coverage. The input remains ops-warden's risk statement, not the policy authority; railiance-platform continues to own every deny decision.

Completed 2026-08-22. The vendored input matches the clean upstream artifact, the repository check covers all 14 entries, and the server-backed audit reports zero uncovered. Evidence: docs/evidence/agent-high-risk-boundary-2026-08-21.md.

Acceptance

• Every concrete high-risk catalog path is denied in the source policy.
• The live policy matches source and the server-backed audit passes.
• A distinct AppRole attachment is established from live metadata.
• Result and generated-artifact follow-up are routed to ops-warden.
• A distinct coding-agent identity actually attaches the boundary.