[security] driver upsert: a tenant-scoped upsert keyed on a globally-unique business column can merge into, and re-parent, another tenant's row

[objectstack-fleet]

Ruled: 5934879010 · letter A (refinements 1/2/3) · 2026-10-01T15:40Z

Filing gate: ① a reproducible defect with a named landing site: the driver upsert merge set (packages/drivers/driver-sql/src/sql-driver.ts, upsert and insertOnlyUpsertColumns; the remote face reads the same list since PR #21184). reach: exception: security. It was measured once, by #21166's dev, on SqlDriver over better-sqlite3 through a direct driver call. The remote face, PostgreSQL and MySQL were not measured.

Filed by the domain:engine execution seat 2 (seat post #20966, session_01Ujdtvqs7ree7WyQmEDwEnG) from #21166's report, out_of_scope_findings[0]. ⛔ Filed bare: grading and routing belong to triage. ⛔ Not a claim. Reader: the maintainer first (a tenant-isolation boundary), then triage.

What is known publicly

• A caller scoped to one tenant called the published IDataDriver.upsert with a conflict key on a column declared unique across tenants. The call merged into a row that another tenant owns. The row's tenant column and its other columns were overwritten, with no error. The row then belonged to the caller's tenant, and was readable there.
• The class: the tenant column is not among the columns upsert treats as insert-only. That is the family drivers(sql): an upsert that merges on a non-PK conflict key silently REWRITES the existing row's primary key — measured on SQLite and MySQL alike #8622 fixed for id, and [finding] driver-turso remote: upsert keyed on a business column replaces the existing row's primary key (the #8622 re-key) — RemoteTransport's merge set keeps id, which the local face declares insert-only #21166 for the remote face.
• In-repo reach, measured by this seat's grep: no in-repo producer passes a business-key conflictKeys.
  • LifecycleService passes ['id'].
  • ObjectQL has no upsert method, so the sandbox body runner's upsert falls back to insert.
  • The import runner finds a record by its match fields, then updates it by id ([finding] driver-turso remote: upsert keyed on a business column replaces the existing row's primary key (the #8622 re-key) — RemoteTransport's merge set keeps id, which the local face declares insert-only #21166, H2).
• The exposure is the published driver contract: a connector, a plugin or a host that upserts on a business key.

Detail withheld pending the maintainer. The reproduction stays with the seat.

Scope for whoever takes it (⛔ not a ruling)

• The tenant column is insert-only in the upsert merge set on every face, read from the one list (insertOnlyUpsertColumns).
• And/or a conflict that resolves to another tenant's row is refused rather than merged. That is a security-boundary choice, and the maintainer's.
• Pins on SQLite and PostgreSQL, and on the remote face.

Dedupe

#8622 (the id re-key, local face) and #21166 (the id re-key, remote face; PR #21184) are the same family. Neither covers the tenant column. The 200 most recent objectstack issues contain no card on a cross-tenant upsert merge.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · security · priority:p1 · domain:engine · area:access · pm:blocked. Ruling: a conflict that resolves to another tenant's row is refused, and the tenant column is insert-only

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-01T14:51Z. ⛔ Not a claim, ⛔ not a dispatch. ⛔ Classes and positions only (detail withheld pending the maintainer).

Blocked-by: #21166

Why p1. A tenant-isolation boundary does not hold on the published driver contract: a tenant-scoped upsert on a globally unique business key can merge into and re-parent another tenant's row. No in-repo producer reaches it today, by the seat's census, and the PostgreSQL and remote faces are not measured.

• Raise rule: if the claim finds an in-repo producer that reaches it, or measures it on the remote face that hosted tenants run, it raises the card to p0 and says so here.

The ruling (triage's, the safe side; overturnable by the maintainer, who is this card's first reader):

• Both halves, not either. Making the tenant column insert-only alone would still let the call overwrite another tenant's other columns, which is a cross-tenant write. So the conflict that resolves to a row of another tenant is refused with the platform's error shape, and nothing is written.
• The tenant column is also insert-only in the merge set, read from the one list (insertOnlyUpsertColumns) on every face. ⛔ No second list.

Routing. driver-sql, and driver-turso through the same list, are domain:engine.

Why blocked. PR #21184 (#21166, in flight; read at this write) edits that same list. Fold: #21166's holder may fold this card into that PR, and says so on this card.

Pins: SQLite, PostgreSQL and the remote face each refuse the cross-tenant conflict with nothing written. A same-tenant upsert on the same key merges as before (the control).

---

Generated by Claude Code

[objectstack-fleet]

Unlocked: pm:blocked → pm:queue — #21166 closed as completed

domain:engine#2 (seat post #20966) · session_01Ujdtvqs7ree7WyQmEDwEnG · 2026-10-01T15:16Z. ⛔ Not a claim. ⛔ Classes and positions only.

• The condition: triage's transition 5933970973 blocked this card on [finding] driver-turso remote: upsert keyed on a business column replaces the existing row's primary key (the #8622 re-key) — RemoteTransport's merge set keeps id, which the local face declares insert-only #21166, because PR fix(driver-turso,driver-sql): a business-key upsert keeps the stored id on the remote face, and both faces answer the stored row (#21166) #21184 edited the same insert-only list. [finding] driver-turso remote: upsert keyed on a business column replaces the existing row's primary key (the #8622 re-key) — RemoteTransport's merge set keeps id, which the local face declares insert-only #21166 is closed: PR fix(driver-turso,driver-sql): a business-key upsert keeps the stored id on the remote face, and both faces answer the stored row (#21166) #21184 merged as ebdb6f2ac. Its remote face now reads SqlDriver.insertOnlyUpsertColumns, so the list this card extends is the one list on both faces.

• The double check: the newest transition is 5933970973, and no PR has merged on this card. The offered fold was not taken; PR fix(driver-turso,driver-sql): a business-key upsert keeps the stored id on the remote face, and both faces answer the stored row (#21166) #21184 landed on its reviewed scope.

• Next claim: under the maintainer's current orders, release preparation with p0 and p1 only, and one subagent at a time once the in-flight work drains (5934179218, 5933047746), this card is first in this seat's line, ahead of [finding] driver-turso remote: RemoteTransport.buildWhereSQL has no JSON-column gate — $contains matches a substring instead of a member, $nin fails open, and the refused families compile over the serialized array (the orphaned #20987 remote item) #21178. That is security before non-security at equal priority. The claim executes triage's ruling, both halves:

  • the cross-tenant conflict is refused, with nothing written;
  • the tenant column is insert-only, from the one list.

  It also runs the p0 raise rule.

• Public text on this card and its PR stays at classes and positions. The dispatch order requires it of the dev's report and the PR body.

---

Generated by Claude Code

[objectstack-fleet]

决策卡:租户作用域 upsert 的冲突落到他租户的行时,平台怎么答

domain:engine#1(座位贴 #6367)· session_017xfMoEjKUuSh2xYB8sCozp · 2026-10-01T15:36Z。⛔ 不是认领。⛔ 只写类别与位置,复现细节不公开。

出处: 维护者在本席会话里对「按分诊方向派发吗」的选择,原话:「先不派，进决策箱」。本卡因此由 pm:queue 转 needs-user-decision,退出活动队列。

一句话问题

一个只属于甲组织的调用方,用一个全平台唯一的业务字段做 upsert 时,冲突可能落在乙组织的那一行上:那一行被合并改写、归属改成甲,没有任何报错。

Governing text

• ADR-0131 D8(已接受):「threads the same value to Layer 0 (computeTenantLayer0Filter) and to every driver」——租户谓词应到达 driver 的每一扇门;upsert 的冲突合并路径是这句话没有兑现的一处。
• ADR-0074 Decision §2(已接受):created_at 是 insert-only,upsert 的冲突合并排除它——「哪些列 upsert 不许改」已有单一列表的先例(insertOnlyUpsertColumns)。
• AGENTS.md「Absence must be loud」:「Prefer failing to falling back」。
• 协议声明:不改 packages/spec;改的是已发布 driver 契约 IDataDriver.upsert 的行为(新增一种拒绝)⇒ Clause-②: no (narrowing),driver-sql / driver-turso minor BREAKING。

前提(带 re-check 命令)

• P1 租户列不在 insert-only 列表里。git show origin/main:packages/drivers/driver-sql/src/sql-driver.ts | grep -n -A6 "protected insertOnlyUpsertColumns":本席读数(origin/main ebdb6f2ac)集合只有 created_at、id 与 autonumber 列;同一命令命中函数名本身即阳性对照。
• P2 remote 面读同一列表。git grep -n "insertOnlyUpsertColumns" origin/main -- packages/drivers/driver-turso/src/turso-driver.ts:本席读数命中(PR fix(driver-turso,driver-sql): a business-key upsert keeps the stored id on the remote face, and both faces answer the stored row (#21166) #21184 之后)。
• P3 仓内今天没有生产者用业务键做冲突键 —— 未验证,来源是 seat 2 在卡正文里的普查;PostgreSQL 与 remote 面也未实测。

选项 × 真实代价

选项	做什么	客户看得见的后果
A 两半都做(分诊方向)	冲突落到他组织的行 ⇒ 整笔拒绝、什么都不写(平台错误信封);同时租户列进 insert-only 单一列表	跨组织 upsert 得到一个响亮的拒绝;同组织 upsert 照旧合并
B 只做 insert-only	租户列不再被改写	行的归属保住了,但乙组织那一行的其它列仍被甲覆盖 —— 跨组织写仍在
C 冲突目标自动收窄到本组织	把租户列并进冲突键	全局唯一列上落成数据库唯一约束错误(不是平台信封),三种方言各答各的
D 不改代码,只写文档	文档要求冲突键含租户列	漏洞照旧可达,只是有了一句告示

业务含义直译

• A = 柜员发现这个账号属于别家客户,当场拒办,什么都不动。
• B = 不改户主,但把别家客户的余额改了。
• C = 把问题推给数据库,客户看到的是一条底层报错。
• D = 在柜台贴一张「请勿办理别家业务」的告示。

四轴(业务立场)

• 项目长远合理性: A 让「租户谓词到达每一扇门」(ADR-0131 D8)在 upsert 上也成立,并且沿用 ADR-0074 的单一 insert-only 列表,不增第二份清单;B/D 留下一扇不受谓词约束的门,C 把语义交给各方言的约束错误。
• 实际业务拉动: 今天仓内没有已知生产者走到这条路(P3,未验证);暴露面是已发布的 driver 契约,任何用业务键 upsert 的连接器、插件或宿主都会撞上。安全类不按拉动打折。
• 防 AI 犯错: 一个让 AI 写的连接器「用业务键 upsert」的写法,在 A 下得到响亮拒绝;在 B/D 下静默改写别家数据,出错时没人看到 —— 恰是最坏的那一面。
• 创业阶段不扩散: A 不新增能力、不新增键,只补一个拒绝和一行列表;C 引入一种新的冲突键语义,反而是扩散。

推荐

• 推荐 A。 终态句:两年后,平台的每个 driver 写门都受同一个租户谓词约束,upsert 与 insert/update 没有例外;多租户 SaaS 的通行做法(如 Salesforce 的外部 ID upsert 只在本组织数据内匹配)同样不存在跨组织合并。
• 只看①选 A;②③④ 是否翻转:否。
• 回退: 若某方言无法在一条语句里原子判定「冲突行属于他组织」,该方言在同一事务里先做一次不受租户谓词约束的按冲突键查询,命中他组织即拒绝;仍属 A,不是 B。
• 置信缺口: PostgreSQL 与 remote 面未实测;各方言判定是否无竞态未实测;拒绝用哪个已登记的错误码(PERMISSION_DENIED 一类,或冲突类)由 dev 在现有 ERROR_CODE_LEDGER 里取,新码即 Clause-②: yes,需另报。

裁后执行

裁 A ⇒ 本席同笔转 pm:queue 并认领派发一单(mode:subagent):SQLite、PostgreSQL、remote 三面各 pin「跨组织冲突被拒且零写入」,同组织同键合并作对照;租户列进 insertOnlyUpsertColumns;公开文字(PR 正文、changeset、报告)只写类别与位置;分诊的 p0 提升规则照跑(找到仓内生产者或在 remote 面实测命中 ⇒ 升 p0 并在本卡说明)。

os-decision-facets

• ① 项目长远合理性:A 缩小特例 —— upsert 不再是租户谓词之外的唯一一扇门,insert-only 仍是一份列表。
• ② 实际业务拉动:仓内今天零已知生产者(未验证),暴露在已发布 driver 契约上;安全边界不按拉动降级。
• ③ 防 AI 犯错:响亮拒绝优于静默改写他组织数据;B/D 的失败方向是静默泄露。
• ④ 创业阶段不扩散:A 零新键、零新能力;C 新增一种冲突键语义,是扩散。
  Prior rulings read: upsert,tenant,cross-tenant,insert-only → 45 hits; ADR-0131 D8, ADR-0074 Decision §2; thread: none; repo: objectstack-ai/objectstack
  推荐:A。只看①选 A;②③④ 是否翻转:否。
  置信缺口:PostgreSQL 与 remote 面未实测;各方言判定的竞态未实测;拒绝的错误码未定(新码即 Clause-②: yes)。

---

Generated by Claude Code

[objectstack-fleet]

Ruling: batch #263 item 1 · letter A, with refinements 1 / 2 / 3 · maintainer 「21185 同意 1/2/3」 2026-10-01T15:39Z

Director seat, summon #32, session_016tKoy8NJa35Yih1FdzrVmn. Written as objectstack-fleet[bot] through the relay. ⛔ Classes and positions only: the reproduction stays with the seats.

• The discussion. The maintainer opened this card with the director in the live director chat. The director agreed with triage's direction (5933970973, both halves) and proposed three refinements. The maintainer answered 「21185 同意 1/2/3」.
• The freshness gate. domain:engine seat 1's decision request 5934820328 (15:36Z) was read before this record. It followed the maintainer's earlier word in that seat's session 「先不派，进决策箱」. Its option A is triage's both-halves direction, and its confidence gaps (the error code, and how each dialect decides atomically) are exactly what refinements 2 and 3 settle. So this record rules A on that table, refined.

The ruling

A: a conflict that lands on another organization's row is refused with nothing written, AND the tenant column is insert-only, from the one list insertOnlyUpsertColumns. Refined as follows.

1. The predicate is the landed row's organization, for ANY conflict target, the primary key included.
   • Read from source at objectstack main 0b12b9ea8f (packages/drivers/driver-sql/src/sql-driver.ts, upsert); not measured.
   • The default conflict target is ['id'], the tenant column sits in the merge set, and a tenant-scoped call is stamped with its caller's organization on entry. So an upsert carrying another organization's id merges into and re-parents that row, on the same mechanism as the business-key case.
   • The business-key case is narrower than the body suggests: under ADR-0120 D1 a field's unique: true is per-organization on a tenanted object. Only an explicit unique: 'global' (or a declared index's bare true, until protocol 18) is installation-wide. The primary key always is.
   • So the pins cover the ['id'] target as well as a unique: 'global' business column.
2. The refusal answers UNIQUE_VIOLATION, the registered code, exactly as create() answers the same collision.
   • From the caller's organization the conflicting row does not exist (it cannot read it), so this upsert IS an insert, and that insert collides on an installation-wide key.
   • The same answer adds no cross-organization information; ADR-0120 records that oracle as the accepted cost of a 'global' key.
   • ⛔ No new code, and ⛔ no message, field or detail that says the row belongs to another organization or names one. A dedicated answer would be a sharper oracle than the one create() already is.
   • Reference: PostgreSQL's own row-level security makes INSERT … ON CONFLICT DO UPDATE raise an error, rather than skip or write, when the conflicting row fails the UPDATE policy.
3. The mechanism: one predicate inside the merge statement, and no new machinery.
   • SQLite, PostgreSQL and the remote face (libsql): ON CONFLICT (…) DO UPDATE SET … WHERE the stored row's tenant column IS NOT DISTINCT FROM the written row's (SQLite: IS).
     • Another organization's row is left untouched, in one atomic statement, with no added transaction or round trip.
     • The tenant-scoped read-back by conflict-key values that already follows the statement then finds no row, and that is when the call throws UNIQUE_VIOLATION.
     • On the remote face, whose read-back today carries no tenant scope, the read-back is scoped too, or the statement's rowsAffected decides. The dev states which in the PR.
   • MySQL (ON DUPLICATE KEY UPDATE has no WHERE): reuse drivers(sql): on MySQL an upsert with no conflictKeys — or one naming the primary key — still merges on a unique key the caller never named #8807's mechanism. The statement and assertMergeLandedOnSuppliedIdentity run as one transaction; the check reads the row under the written tenant, and its failure rolls the write back. This is owed whenever the call is tenant-scoped on a tenanted object, not only when a rival UNIQUE key exists.
   • Half 2 (the tenant column insert-only) is a no-op for a tenant-scoped call once the predicate holds. Its job is the call with no tenant context: an upsert never re-parents a row. update() is the deliberate path, which is the upsert 每次「合并到既有行」都烧一个自增号,并覆写该行已有的业务号(健康计数器上实测,与陈旧无关) #7011 / drivers(sql): an upsert that merges on a non-PK conflict key silently REWRITES the existing row's primary key — measured on SQLite and MySQL alike #8622 argument for auto_number and id.

Not taken:

• B: insert-only alone still overwrites the other organization's columns.
• C: folding the tenant column into the conflict key gives dialect errors outside the platform envelope.
• D: documentation only.

Governing text and prior rulings read

• ADR-0131 D8 (the tenant predicate reaches every driver door).
• ADR-0074 Decision §2 (the single insert-only list).
• ADR-0120 D1 (the unique-scope vocabulary, and the oracle note on 'global').
• AGENTS.md 「Prefer failing to falling back」.
• Thread: triage 5933970973; unlock 5934416748; seat 1's request 5934820328 (whose Governing-text and premise lines this record adopts).

四棱(本裁决新记录)

• ① 长远:upsert 不再是租户谓词之外的唯一一扇门(ADR-0131 D8);判据落在「冲突行属于谁」,对任何冲突目标一样,不为业务键另立特例;insert-only 仍是一份列表。
• ② 拉动:仓内零已知生产者(seat 2 普查,未复验),暴露在已发布 driver 契约上;按主键 id 的这条路同样可达。安全边界不按拉动降级。
• ③ 防 AI:AI 写的连接器拿业务键或外泄的 id 去 upsert,得到响亮的 UNIQUE_VIOLATION,与 create() 同一答案;不新增探测口,也不再静默改写别家数据。
• ④ 不扩散:零新键、零新错误码、零新机制(语句内判据,MySQL 复用 drivers(sql): on MySQL an upsert with no conflictKeys — or one naming the primary key — still merges on a unique key the caller never named #8807)。
• 只看①选 A;②③④ 是否翻转:否。

Execution parameters (ruled here; no further decision card)

• needs-user-decision → pm:queue in this act, in domain:engine, level M, mode:subagent.
  • Seat 1 offered to claim on ruling A (5934820328), and seat 2 listed the card first in its line (5934416748). The claim protocol decides: the first Claim: wins and the other yields.
• Clause-②: no (narrowing). It becomes yes (narrowing) if the same PR corrects an IDataDriver.upsert docblock in packages/spec/src/contracts/ that states merge semantics this ruling makes false; that is the security(plugin-security): a non-system caller who resolves no permission set is admitted to every object and read with no row scope; an empty set list grants by absence instead of answering the deny baseline #21079 precedent, and the docblock moves in the same PR.
• The changeset: BREAKING for driver-sql and driver-turso. FROM → TO: an upsert whose conflict lands on another organization's row is refused with UNIQUE_VIOLATION and writes nothing, and an upsert never changes a row's organization; to move a row between organizations, use update().
• Pins:
  • SQLite, PostgreSQL, MySQL (CI's live leg) and the remote face. On each, a cross-organization conflict on the ['id'] target and on a unique: 'global' column is refused with UNIQUE_VIOLATION, and the other organization's row reads back byte-identical.
  • A same-organization upsert on the same key merges as before (the control).
  • A call with no tenant context does not change the row's organization (half 2).
  • The error body names no organization.
• Triage's p0 raise rule stands: an in-repo producer that reaches this, or a measured hit on the remote face hosted tenants run, raises the card to p0, stated here.
• Noted, not in scope:
  • driver-memory refuses tenant-scoped calls outright, so it is unaffected.
  • driver-mongodb's own docblock says it ignores DriverOptions.tenantId, so it has no isolation at all. That is a different question, ⛔ not widened into this card.

---

Generated by Claude Code