coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

WARDEN-WP-0033-T04: route the coding-agent issuance identity to key-cape
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
Routed, not absorbed. It is an identity and issuance question about a principal
authenticating to OpenBao, which is key-cape's. secrets-engine drew the same
boundary at us an hour ago over key-cape-oidc-login and we agreed with them.

Named zone-engine as interested and user-engine as explicitly not involved, so
neither is concluded by inference. Asked for accept or refuse; a refusal with a
pointer is an equally good answer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 08:39:10 +02:00
parent 6e1d5201aa
commit 6cd969dda9
1 changed files with 18 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

19
workplans/WARDEN-WP-0033-native-lane-handoff.md
View file

@ -156,7 +156,7 @@ railiance-platform may deny more, deny less, or dispute a grade (`ADR-0002`).
```task
id: WARDEN-WP-0033-T04
status: todo
status: wait
priority: medium
```
@ -177,6 +177,23 @@ Note the interaction with `ADR-0004`: the agent read-boundary already depends on
side. A real issuance identity is what would make that boundary hold on the
OpenBao side too, so ops-warden is an interested consumer, not a bystander.
**Routed 2026-08-21 to `key-cape` (msg 903b2223); waiting on accept or refuse.**
Reasoning given: it is an identity and issuance question about a principal
authenticating to OpenBao, which is key-cape/Keycloak's. The precedent is an hour
old and runs the same direction — `secrets-engine` declined `key-cape-oidc-login`
as ops-warden's to hand them, on the grounds that login and identity-token
issuance stay with key-cape. Absorbing this would contradict agreeing with them.
Named the adjacent parties explicitly rather than leaving them to inference:
`zone-engine` has an interest (a coding-agent identity is a strong candidate zone
subject) and `user-engine` is **not** involved — this is a machine principal, not
an end-user account. Stated so nobody concludes it by elimination.
Asked for a refusal-with-pointer as an equally good answer. The failure mode to
avoid is the 2026-08-17 one recorded in `.claude/rules/finding-routing.md`:
ops-warden answered a question well and never routed it, and another repo ended
up filing it.
## Related
- `secrets-engine` `SECRETS-WP-0006` — catalog admission, decision `ae676382`