api-key-ui-lifecycle: after #7727 an ordinary member still cannot revoke their OWN API key — 403 PERMISSION_DENIED, and the key keeps authenticating

[baozhoutao]

Residual of #7727, found by re-testing it. #7727 is genuinely fixed for admins — PATCH /api/v1/data/sys_api_key/{id} {revoked:true} went from 405 OBJECT_API_METHOD_NOT_ALLOWED to 200, the key stops authenticating on the very next request, and the console's Setup → API Keys → Revoke row action now fires a 200 and toasts "API key revoked" instead of erroring. The method gate and the ADR-0092 column whitelist both landed correctly.

What did not land is the persona the item names first — "a signed-in member (key owner)". The declared row actions revoke_api_key / restore_api_key still render in that member's own My Keys grid, and still error for them.

Symptom

A member mints a personal API key, then cannot revoke it:

• PATCH /api/v1/data/sys_api_key/{their own id} {revoked:true} → 403 PERMISSION_DENIED
• the row still reads revoked: false
• the key still returns 200 on GET /api/v1/data/showcase_task

Reproduced with two independent personas.

Reproduction

1. As admin: POST /api/v1/auth/admin/create-user {"email":…,"password":…,"mustChangePassword":false}
2. Sign in as that member.
3. POST /api/v1/keys {"name":"k"} → 201; capture data.id and data.key.
4. GET /api/v1/data/showcase_task with x-api-key: <key> → 200.
5. As the same member: PATCH /api/v1/data/sys_api_key/{id} {"revoked":true}.

Expected 200, and the key stops authenticating.
Actual 403 {"code":"PERMISSION_DENIED"}, row unchanged, key still 200.

Root cause

#7769 opened the method gate (apiMethods now ['get','list','update']) and the ADR-0092 D2 column whitelist (revoked), but the object-CRUD layer is unchanged. The platform member_default set grants only allowRead on the BETTER_AUTH_MANAGED_OBJECTS list (packages/plugins/plugin-security/src/objects/default-permission-sets.ts), so update on sys_api_key resolves only for admin_full_access.

Confirmed with the platform's own explain route, as that member:

GET /api/v1/security/explain?object=sys_api_key&operation=update
→ allowed: false; object_crud DENIES —
  "No resolved permission set grants update on sys_api_key"

(member_default does carry a sys_api_key_self RLS carve-out, so the row is visible to its owner — there is just no allowEdit to go with it.)

Why it is worth closing rather than deferring

A personal API key "acts as you — treat it like a password" (the console's own copy on the mint screen). The owner is the person who discovers it leaked, and right now their only remedy is to find an admin. It is also a dead affordance of the exact shape #7727 filed, one layer up: the button renders for the persona that cannot use it.

Suggested shape (not prescriptive)

Give member_default an owner-scoped update grant on sys_api_key narrowed to the whitelisted column, so the existing sys_api_key_self RLS carve-out decides which rows and the column whitelist decides which fields. The gate: extend the revoke test to run as the key's owner, not only as admin — the current pins exercise the admin path, which is why this half stayed hidden behind #7727's fix.

Not affected

Cross-owner revocation is correctly refused (a member PATCHing the admin's key → 403, row unchanged), non-revoked column writes are still refused with a located message, create/delete/batch stay closed (405), and show-once semantics are intact.

Source

Found by the platform checklist retest of identity-auth.api-key-ui-lifecycle (framework 279ee48a), re-running #7727's own reproduction.

[hotlong]

Triage: lands in packages/plugins/plugin-security/src/objects/default-permission-sets.ts (owner-scoped update grant on sys_api_key for member_default) → domain:identity, queued. Re-laned from domain:access-security — not a lane-table label. Type intent: Bug (type field not set — list_issue_types 403 for this credential).

target:v17 (release-board classes ① + ④): a member's only remedy for their own leaked personal key is to find an admin, on the persona the checklist item names first, while the console renders the revoke affordance for them — an apology-grade gap on a published surface.

Grading note on the access-widening question: this is treated as declared ≠ enforced restoration, not a new grant — the declared surface (row actions rendered for the member's My Keys grid, the checklist persona, the existing sys_api_key_self RLS carve-out that already makes the row owner-visible) all say the owner path was intended. The guardrails already on the card are binding for review: the grant must stay owner-scoped (ride the existing RLS carve-out) and column-whitelisted (revoked only), cross-owner refusal and 405-closed methods must be pinned unchanged, and the revoke test must run as the key's owner, not only as admin. Any wider grant shape is out of scope and escalates.

Serial constraint: identity lane has #7735 in flight in plugin-auth; different package (plugin-security), so batch-compatible on the package rule — executing seat confirms file disjointness at claim time.

---

Generated by Claude Code

[os-zhuang]

Landing package determined — plugin-security. Not claimed yet: serialized behind #7809. domain:identity seat #6022, session session_01PEVB6w7D7uCszR9Mw1BL73.

Recording this on the card rather than keeping it in session context, because a determination that exists only in a PM's head is lost the moment that session ends — which is exactly how this seat was found at takeover today.

Where it lands, and how that was settled

The card's own root-cause section settles it: the object-CRUD layer is unchanged, and member_default grants only allowRead on the BETTER_AUTH_MANAGED_OBJECTS list in packages/plugins/plugin-security/src/objects/default-permission-sets.ts. The fix is an owner-scoped update grant there, leaning on the sys_api_key_self RLS carve-out that already exists to decide which rows and the ADR-0092 D2 column whitelist to decide which fields.

⚠️ I had deferred this determination twice, deliberately, because the card could plausibly have landed in plugin-auth (API-key issuance) — and guessing would have put it in the wrong serialization queue. Reading it settles it: plugin-security.

Why it is not being claimed in this round

plugin-security currently has #7809 in flight (PR #8106, dev has not yet reported). Different file — #7809 works security-plugin.ts's bulk AST path, this card works the member_default seed — but this lane serializes on the package, not the file, and that convention has held all shift. ⛔ Not making an exception on my own authority for a card I would like to move faster.

Honest cost, stated rather than buried: this is target:v17 and #7809 is not, so a target:v17 card is now waiting behind a non-board card. That ordering is an artefact of dispatch sequence — #7809 was claimed at 15:03Z when this card's package was still undetermined — not a judgement that #7809 matters more. Had the determination been made first, this card would have gone out instead.

Dispatches the moment PR #8106 is MERGED, with the file surface re-verified on the merged ref first.

Two notes carried forward for whoever dispatches it

1. The gate is the persona, not the assertion. The card names it precisely: "extend the revoke test to run as the key's owner, not only as admin — the current pins exercise the admin path, which is why this half stayed hidden behind api-key-ui-lifecycle: API keys cannot be revoked through any product route (405) — object declares revoke/restore as PATCH but disables the PATCH method #7727's fix." A pin added as admin would pass against the unfixed build. That is the third instance today of a fixture whose persona or default disarms the thing under test (see [finding] An org-less test fixture cannot observe the org_member-gated write floor, so a real 403 defect records as a PASSING cell #8074), and it is the reason this card exists at all rather than having been caught by api-key-ui-lifecycle: API keys cannot be revoked through any product route (405) — object declares revoke/restore as PATCH but disables the PATCH method #7727's own tests.
2. The "Not affected" list is the regression surface, and it is a security boundary. Cross-owner revocation must stay 403, non-revoked column writes must stay refused, create/delete/batch must stay 405, show-once semantics intact. A grant that opens update on sys_api_key more broadly than owner-scoped-plus-one-column would close this card and open a worse one.

---

Generated by Claude Code