railiance-platform/workplans/RAILIANCE-WP-0022-agent-high-risk-boundary-coverage.md
codex 382f04412a
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Close CCR drift and high-risk policy gaps
2026-08-21 01:29:28 +02:00

124 lines
4.4 KiB
Markdown

---
id: RAILIANCE-WP-0022
type: workplan
title: "Close agent high-risk OpenBao boundary coverage"
domain: financials
repo: railiance-platform
status: blocked
owner: codex
topic_slug: railiance
created: "2026-08-21"
updated: "2026-08-21"
related:
- WARDEN-WP-0032
- RISK-F-0009
origin: routed
origin_ref: "State Hub message 828e4903-30fe-4903-acfd-cd2ecdda437d"
---
# RAILIANCE-WP-0022 — 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
```task
id: RAILIANCE-WP-0022-T01
status: done
priority: high
```
Run the capabilities-only ops-warden audit against the policy. The 2026-08-21
reconciliation found 17 high-risk lanes: six covered, six concrete uncovered,
and five without a concrete KV address. No credential value was read.
## T02 — Close the concrete deny gaps
```task
id: RAILIANCE-WP-0022-T02
status: done
priority: high
```
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-21. The source policy covers all 12 unique concrete paths
(including the Core Hub path, which has no catalog lane), and the local
catalog audit reports all 12 catalog entries covered with none uncovered.
## T03 — Apply and verify live
```task
id: RAILIANCE-WP-0022-T03
status: done
priority: high
```
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 2026-08-21 under attended `platform-admin` OIDC. OpenBao accepted the
policy; normalized readback matched source, and the server-backed catalog audit
reported 17 high-risk lanes, 12 covered entries, zero uncovered, and five
pattern/non-KV lanes without a concrete address. Metadata-only inspection of
all discoverable netkingdom, Kubernetes, AppRole, and token roles found zero
attachments of `agent-high-risk-boundary` and therefore zero roles combining
it with a workload-read policy. No token was minted and no Secret was read.
## T04 — Route the result
```task
id: RAILIANCE-WP-0022-T04
status: done
priority: medium
```
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.
## T05 — Establish a distinct coding-agent identity
```task
id: RAILIANCE-WP-0022-T05
status: wait
priority: high
```
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.
This is blocked on an identity-owner decision and is not invented here.
## Acceptance
- [x] Every concrete high-risk catalog path is denied in the source policy.
- [x] The live policy matches source and the server-backed audit passes.
- [x] Agent boundary attachment is established from metadata (currently zero).
- [x] Result and generated-artifact follow-up are routed to ops-warden.
- [ ] A distinct coding-agent identity actually attaches the boundary.