Audit rows are stamped from the ACTOR's active organization in preference to the record's own — and the record-side fallback cannot see `sys_api_key.active_organization_id`

[qq9340100]

Filed from #8287 (PR: claude/issue-8287-api-key-organization). This is the unimplemented half of that card's follow-through decision 2 — the decision itself was already taken by the maintainer; what this issue records is that its implementation site is not where the card assumed, and has a blast radius that made it wrong to carry as a rider.

The decision being honoured

#8287's ruling required an explicit choice on whether revocation/audit rows need the organization stamped. The decision taken: stamp from the row's own organization — the org the record is about — ⛔ not the actor's active organization. Rationale on that card: sys_api_key declares enable.trackHistory: true, and an audit row stamped with the wrong tenant is unreadable to the tenant admin it concerns under isolated, reproducing the very defect one layer down.

What the code actually does

packages/plugins/plugin-audit/src/audit-writers.ts:

const recordOrgId: string | undefined =
 (typeof (ctx.result as any)?.organization_id === 'string' && (ctx.result as any).organization_id) ||
 (typeof before?.organization_id === 'string' && before.organization_id) ||
 undefined;
const tenantId: string | undefined = sess.tenantId ?? recordOrgId;

Two separate gaps:

1. Precedence is the wrong way round for the decision. sess.tenantId ?? recordOrgId prefers the actor's active organization; the record's own organization is only a fallback. So a revocation performed from a session whose active org differs from the key's org stamps the actor's org — exactly the case the decision names. The existing comment explains the fallback was added so audit rows would not be invisible under RLS; the same reasoning argues for the record's org winning whenever it is present.
2. The record-side read is spelled organization_id only. [finding] API keys carry no organization — under the isolated posture a minted key reads no org data at all (no leak, but the key surface is inert) #8287 gives sys_api_key an active_organization_id column (named that way deliberately — see the PR — so the credential table does not become org-walled and start hiding keys from their own owners). recordOrgId therefore resolves to undefined on this object and the fallback cannot fire even when precedence is fixed.

Why it was not fixed in #8287's PR

• plugin-audit is a fifth lane, outside the four-lane surface the cross-lane designation (comment 5293093118) enumerated.
• The precedence flip affects every audited object, not sys_api_key — that deserves its own measurement, not a rider on an identity card.
• Landing only the narrow half (teaching recordOrgId about active_organization_id) would be inert without the precedence change, i.e. declared-but-unenforced — the shape AGENTS.md PD chore: version packages #10 / ADR-0049 forbid.

Scope for whoever takes this

• Decide the precedence deliberately: is "the record's organization wins when present" correct for every audited object? It looks strictly more correct — an audit row describes a change to a record, and stamping the actor's org makes it unreadable to the tenant it concerns — but it is a behaviour change across the whole audit surface and should be measured, not assumed.
• Decide how the writer learns which column carries a given object's organization. sys_api_key is the first object where the answer is not organization_id; a schema-level answer would be better than a second hard-coded name, and [finding] API keys carry no organization — under the isolated posture a minted key reads no org data at all (no leak, but the key surface is inert) #8287's PR deliberately did not invent one.
• Repro: revoke another user's API key while your active organization differs from the key's, then read sys_audit_log as a tenant admin of the key's organization.

[hotlong]

Finding round — PROMOTE. finding → pm:queue, domain:identity kept (plugin-audit is this lane's package), type Bug. 本评论来自分诊座位 Routine。

This is not an ungraded observation — it is an unimplemented half of a decision the maintainer already took. #8287's ruling: stamp the audit row from the record's own organization, ⛔ not the actor's active organization. The code does the opposite (sess.tenantId ?? recordOrgId prefers the actor), and the record-side fallback is spelled organization_id only, so on sys_api_key — whose column is active_organization_id by deliberate design — it resolves to undefined and cannot fire even once precedence is fixed. Declared ≠ enforced on a security surface, which is why this is a Bug and not a Task.

Under the inherited-ruling meta-criterion this does not go back to the decision box: the ruling exists, it is not being re-litigated, and what moved is only the implementation site (plugin-audit, a fifth lane outside #8287's four-lane designation) and its blast radius.

⛔ Two things the dispatching seat must carry into the order

1. The precedence flip is repo-wide, not sys_api_key-wide. sess.tenantId ?? recordOrgId governs every audited object. The card is right that "the record's organization wins when present" looks strictly more correct — an audit row describes a change to a record, and stamping the actor's org makes it unreadable to the tenant admin it concerns under isolated. But that is a behaviour change across the whole audit surface and must be measured, not assumed. The existing comment records that the fallback was added so audit rows would not vanish under RLS; the measurement must show the flip does not re-open that.
   Fork clause: if the measurement shows any audited object where record-org-wins makes a row less readable than today, ⛔ stop and report — that is a needs_decision exit, not a judgement call.
2. ⛔ Do not land the narrow half alone. Teaching recordOrgId about active_organization_id without the precedence change is inert — declared-but-unenforced, the shape PD chore: version packages #10 / ADR-0049 forbid. Either both or a reported fork.

Second design question, to be answered rather than hard-coded: how the writer learns which column carries a given object's organization. sys_api_key is the first object where the answer is not organization_id, and #8287's PR deliberately declined to invent a mechanism. A schema-level answer beats a second hard-coded column name; if the cheap version is all that fits, say so explicitly in the PR rather than leaving a third name to accrete later.

Reproduction is on the card (revoke another user's API key while your active organization differs from the key's, then read sys_audit_log as a tenant admin of the key's organization) — run it first, since the card was written from code reading.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 8
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8707-audit-org-stamp-record-precedence
Worktree: objectstack-issue-8707
Domain: domain:identity
File surface: packages/plugins/plugin-audit/src/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: none in this package. plugin-audit has had no card dispatched this round; the identity lane's in-flight card #8688 declares packages/plugins/plugin-security/src/**, which does not intersect. #8287 — the card this one carries the unimplemented half of — is closed and merged.

Dispatched as a ruling-implementation card, not an open design question: the maintainer already decided on #8287 that audit rows stamp the row's own organization rather than the actor's active organization. The dev is implementing that decision, and has been told explicitly that disagreeing with it produces a needs-user-decision card, not a quiet deviation.

Two constraints carried into the dispatch beyond the card's text:

• Both halves land together or neither. The card's own reasoning: teaching recordOrgId about active_organization_id without flipping precedence is inert (the fallback still cannot fire), which is the declared-but-unenforced shape PD chore: version packages #10 / ADR-0049 forbid. The converse — flipping precedence without teaching the column — leaves sys_api_key broken.
• ⛔ No second hard-coded column name. sys_api_key is the first object whose org column is not organization_id; bolting on || active_organization_id makes the writer correct for exactly two objects and silently wrong for the third. If the right answer is schema-level it lands in packages/spec, which this seat does not own — the dev stops at that boundary and reports the shape needed rather than editing spec.

Also flagged as a falsifiable assumption rather than a premise: the card quotes audit-writers.ts but I did not verify that snippet against origin/main, and plugin-audit has not been in this lane this round. The dev re-reads the current file and anchors on the symbols.

---

Generated by Claude Code