diff --git a/history/2026-10-08-oidc-rp-follow-through-review.md b/history/2026-10-08-oidc-rp-follow-through-review.md
index 75974d7..f254ee4 100644
--- a/history/2026-10-08-oidc-rp-follow-through-review.md
+++ b/history/2026-10-08-oidc-rp-follow-through-review.md
@@ -117,3 +117,45 @@ R2 (canon definition of `warden_executes`), R3 (`value_handling`), R4′
 become reviewed catalog entries: `identity-provisioner-groups` (owner
 net-kingdom) and `keycape-client-secret-generate` (owner railiance-platform).
 ops-warden has no further required changes to the type.
+
+## Addendum 2026-10-09: R8, `ensure-groups` has no caller-identity path
+
+NK-WP-0048-T08 handed the ops-warden route for the provisioner's service token to
+WARDEN-WP-0044-T01. That route cannot be written as the type declares it.
+
+The `ensure-groups` step says `warden_executes: true`, auth "the caller's own
+identity-provisioner credential through its lane; ops-warden invokes it via the
+caller proxy and holds no token". The deployed provisioner has no per-caller
+credential:
+
+- `identity-provisioner/server.py` compares every `POST` bearer against one
+  `PROVISIONER_SERVICE_TOKEN`
+- that token is user-engine's runtime secret
+  (`platform/workloads/user-engine/runtime`, property `PROVISIONER_TOKEN`,
+  delivered by `sso-mfa/k8s/user-engine/openbao-runtime.yaml`)
+- NetworkPolicy `sso/identity-provisioner` admits port 8080 only from
+  user-engine pods, plus traefik for the `/setup/password` Ingress
+
+A catalog lane over this would have to fetch user-engine's workload secret and
+reach the service from outside its admitted peers. The operator would be acting
+as user-engine, not as themselves. That breaks canon §3's narrow
+`warden_executes` (caller identity, no standing credential) and ADR-0002. So
+ops-warden adds no `identity-provisioner-groups` entry in this form.
+
+**R8:** net-kingdom chooses one of these:
+
+1. **Attended, in the existing session (recommended).** Run `groups ensure` in
+   the attended session that already runs `register-client`, through the same
+   contained kubectl (an exec into the provisioner pod, or a contained one-shot
+   job), with `warden_executes: false`, `attended: true` and lane
+   `key-cape-oidc-login`. This adds no attended session, because the type
+   already needs one, and nothing new has to be built.
+2. **Give the provisioner a caller credential.** Add an operator-scoped
+   credential separate from user-engine's, such as an OIDC caller token
+   verified against KeyCape or an OpenBao-issued per-operator token, plus an
+   admitted ingress path for it. Then `identity-provisioner-groups` becomes a
+   real caller-proxy lane and `warden_executes: true` holds. This is more work,
+   and it is the shape the type describes today.
+
+Until one of these lands, `warden case check-type` keeps reporting the lane
+missing, which is correct.
diff --git a/workplans/WARDEN-WP-0044-security-case-follow-through.md b/workplans/WARDEN-WP-0044-security-case-follow-through.md
index 113ec69..e5a32e1 100644
--- a/workplans/WARDEN-WP-0044-security-case-follow-through.md
+++ b/workplans/WARDEN-WP-0044-security-case-follow-through.md
@@ -75,6 +75,15 @@ in the catalog: `identity-provisioner-groups` (net-kingdom) and
 `keycape-client-secret-generate` (railiance-platform). These gate T02, not
 T01. T01 still closes on net-kingdom's acknowledgement (NK-WP-0048-T05).
 
+2026-10-09: ops-warden cannot add `identity-provisioner-groups` as the type
+declares it. The provisioner accepts only user-engine's runtime token and
+admits only user-engine pods, so no caller-identity path exists. R8 (review
+addendum) asks net-kingdom either to move `ensure-groups` into the existing
+attended session (recommended) or to give the provisioner an operator
+credential. `keycape-client-secret-generate` needs a generate-in-custody entry
+point from railiance-platform, and the broker does not have one yet. Both were
+sent to their owners.
+
 ```task
 id: WARDEN-WP-0044-T02
 status: wait