Observation: package permission sets are materialized with a tenant-less system context, so `sys_permission_set` rows land organization-less

[qq9340100]

Found while implementing #8617 (per-organization audience-binding-suggestion reconciler). Filed as an observation, not a defect claim — the harm is unmeasured and the contract question underneath it is a maintainer call, not mine. Recording it so the next author does not have to re-derive it.

What is there

packages/plugins/plugin-security/src/permission-set-projection.ts exports the shared engine helpers used by the permission-set seeder and the package-door publish materializer:

export async function tryFind(ql: any, object: string, where: any, limit = 100): Promise<any[]> {
 try {
 const rows = await ql.find(object, { where, limit }, { context: SYSTEM_CTX });

SYSTEM_CTX there is { isSystem: true } with no tenantId, and upsertPackagePermissionSet in bootstrap-declared-permissions.ts writes sys_permission_set through those helpers — at boot, on a package-door permission publish, and from confirmAudienceBindingSuggestion when a suggestion's set is not yet materialized.

sys_permission_set declares no tenancy opt-out, so its organization_id is injected like any other tenant column. Measured on a real ObjectQL + SqlDriver engine under OS_TENANCY_POSTURE=isolated (the same rig as #8617):

call	result
insert under { isSystem: true }	stores organization_id NULL
find under { isSystem: true, tenantId: X }	sees X's rows and the NULL ones

So a package-declared permission set lands in the platform bucket (ADR-0120 D3) and is read by every tenant.

Why this is an observation and not a fix

Unlike sys_audience_binding_suggestion — whose header says rows are "resolved when a tenant admin confirms", which is what made #8617 a straightforward per-organization repair — a permission SET plausibly is installation-wide by design: the package ships one definition, and the per-tenant decision is the BINDING (sys_position_permission_set), not the set. On that reading an organization-less row is exactly right and nothing needs changing.

What I did not measure, and what would decide it:

1. whether any deployment shape wants two organizations to hold different sets under one name (if yes, the org-less write blocks it, and the declared unique-index class of tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 / fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461 / sys_position.name is the third instance of the #8323 class: an admin-authored name on a tenant-scoped RBAC object carries an installation-wide unique index #8468 / Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554 applies here too);
2. whether a tenant can create its own sys_permission_set row through the admin door, and how that row's organization_id interacts with the org-less package row of the same name — upsertPackagePermissionSet's provenance branches (managed_by platform/user/absent ⇒ "env-authored, never clobbered") resolve ownership by provenance, never by organization.

Related

• The audience-binding-suggestion reconciler writes with a tenant-less system context, so one organization-less row serves every tenant — the second half of the #8577 install-path dead end #8617 — the audience-binding-suggestion reconciler, where this was noticed. The suggestion surface is fixed there; this file is untouched by that PR.
• Two MORE clean inheritors of the #8323 class the #8554 sweep missed: sys_notification_subscription and sys_audience_binding_suggestion — both measured live #8577 — the per-organization index respelling on the suggestion object.
• tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 / fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461 / sys_position.name is the third instance of the #8323 class: an admin-authored name on a tenant-scoped RBAC object carries an installation-wide unique index #8468 / Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554 — the tenant-scoped declared unique index class.

Filed unassigned. Found by session session_01MX1qcBzfwZb5wkRrJTNbhH (dev seat for #8617).

---

Generated by Claude Code

[qq9340100]

Finding first-touch grade: hold (finding → pm:on-hold)

Graded by PM session session_01MX1qcBzfwZb5wkRrJTNbhH, acting as caretaker of the vacant domain:identity seat (#6022) under the maintainer's 2026-08-14 delegation of finding first-touch triage in vacant lanes. A graded card leaves the finding label, so it is removed.

Why hold rather than promote

The card is scrupulous that the harm is unmeasured, and that scruple is correct rather than cautious. Unlike sys_audience_binding_suggestion — whose own header says rows are "resolved when a tenant admin confirms", which is what made #8617 a straightforward per-organization repair — a permission set is plausibly installation-wide by design: the package ships one definition, and the per-tenant decision is the binding (sys_position_permission_set), not the set. On that reading an organization-less row is exactly right and there is nothing to fix.

So this is not a defect awaiting scheduling. It is a contract question with no measured victim, and the startup-scope axis says a declared-but-unpulled concern waits rather than becoming permanent maintenance.

Why not needs-user-decision

The maintainer's decision box is for questions that block work. Nothing is blocked: no card depends on this, and #8617 (the card it was found from) shipped without it. Escalating an unmeasured contract question with no consequence attached would spend the maintainer's attention to produce a ruling nobody is waiting on.

Restart conditions — named, so this can legitimately leave hold

⚠️ A hold with no restart condition is a state nobody can exit. Either of these fires it:

1. A deployment shape wants two organizations to hold different permission sets under one name. The org-less write blocks that, and at that point the tenant-scoped declared-unique-index class (tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 / fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461 / sys_position.name is the third instance of the #8323 class: an admin-authored name on a tenant-scoped RBAC object carries an installation-wide unique index #8468 / Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554) applies here too.
2. A tenant can create its own sys_permission_set row through the admin door, and that row collides by name with the org-less package row. upsertPackagePermissionSet's provenance branches resolve ownership by managed_by, never by organization, so a collision would be resolved on the wrong axis.

Neither was measured. Either one turns this from a shape question into a defect with a victim.

Trigger files, so the opportunistic path has a real reader

Per the standing rule that an opportunistic restart condition must name its trigger files: any PR touching packages/plugins/plugin-security/src/permission-set-projection.ts or bootstrap-declared-permissions.ts should check this card, because that is where SYSTEM_CTX is applied without a tenant and where a fix would land.

⛔ Not nominated for target:v17. It carries no measured user impact, and this theme's work set is the target:v17 set only.

---

Generated by Claude Code