[security] org-admin sets ship object_permissions['*'].allowExport = true, so the 17.0 export gate cannot be denied for an org admin — and the sets are not_overridable (17.0.0 GA)

[hotlong]

Part of objectstack-ai/hotcrm#707 (never mirrored until now). Measured on @objectstack/* 17.0.0 GA during HotCRM's GA close-out sweep (hotcrm#1150 / #1152), 40 export probes, 5 principals x 8 objects, real Bearer tokens.

The good half — the gate works

For every non-admin principal the 17.0 export inversion is exact. Every declared-allowed cell returns 200 with read-derived rows; every declared-denied cell returns 403 EXPORT_NOT_PERMITTED. modifyAllRecords does not substitute for allowExport. This is not asserted from a single call — the gate is shown to be ENFORCING three ways:

• C1 the same token that is refused on crm_quote exports crm_lead 200 on the same route (so the 403 is the gate, not the token);
• C2 granting allowExport on crm_quote at runtime flips that 403 to 200;
• C3 revoking it flips it back to 403.

The hole

The org owner (holding admin_full_access + organization_admin_no_bypass) exports crm_quote (9 rows), crm_campaign (13 rows) and crm_task (15 rows) with 200 and full data — objects on which no app permission set grants allowExport.

Attribution, measured rather than guessed

hotcrm#707 guessed a canExport admin bypass. It is not that. Both platform admin sets ship a wildcard export grant:

admin_full_access['*'].allowExport = true
organization_admin_no_bypass['*'].allowExport = true
member_default['*'] = undefined

and a wildcard export grant is honoured — proven on a principal with no admin status at all, crm_quote, one grant shape per row:

grant shape on a plain org member	READ	EXPORT
S1 '*'.allowExport = true	200	200
S2 crm_quote.allowExport = true	200	200
S2b '*'.allowExport = true + crm_quote.allowExport = false	200	403

So the admin's 200 is the wildcard doing exactly what it says, not a bypass — and S2b shows the platform already honours a more-specific per-object false over the wildcard, i.e. a supported opt-out shape exists.

Why the app cannot use it

1. The wildcard lives in code-package metadata. Editing it answers
   403 [not_overridable] Metadata item 'permission/admin_full_access' is provided by a code package.
2. The org admin holds no app-authored permission set, so the app has nowhere to author the per-object false that S2b proves would win.

Consequence: an app can declare "this object is exportable by nobody" and the platform will still export it for any org admin, with no supported way to opt out. That is the same shape hotcrm#703 raised about the old member_default create/read/edit wildcard — which was resolved by removing the wildcard (#5491 / PR #6684). The export axis kept its wildcard.

The card's own open question, now closed

hotcrm#707 recorded a caveat that a pure app system_admin-set holder was not constructible in that run, so the finding might be "org-owner bypasses" rather than "the admin set bypasses". Constructed here by binding the app's system_admin set to a plain member through sys_user_permission_set:

crm_quote declared allowExport=false -- export 403 EXPORT_NOT_PERMITTED
crm_campaign declared allowExport=false -- export 403 EXPORT_NOT_PERMITTED
crm_task declared allowExport=false -- export 403 EXPORT_NOT_PERMITTED
crm_account declared allowExport=true -- export 200 rows=19
crm_lead declared allowExport=true -- export 200 rows=25

An app admin set gets exactly the declared posture. The hole is specific to the platform org-admin sets and the wildcard they ship.

Suggested direction

Either drop allowExport from the '*' entry of the shipped admin sets (matching what #5491 did for the CRUD axes), or give apps a supported way to author a per-object export denial that reaches an org admin. A design decision either way, which is why this is filed rather than patched.

Evidence: hotcrm#1152 probes 40-707.mjs, 45-707-decisive2.mjs, 46-707-sysadmin.mjs; readings posted on hotcrm#707.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/plugins/plugin-security/ (the shipped admin_full_access / organization_admin_no_bypass bundles) ⇒ domain:identity. Type Bug. Escalated to needs-user-decision.

Why escalated even though all four prisms agree. This is on the human floor twice over: it is a permission-boundary change, and route (a) removes a grant from a published capability that every org admin holds today. Prism alignment is not a licence to take a floor decision — it only makes the sitting short.

The measurement quality is unusually high and worth trusting: the card does not merely observe an admin exporting, it isolates the cause — C1/C2/C3 show the gate enforcing, and the S1/S2/S2b table on a plain member proves the wildcard is honoured and that a per-object false already beats it. So "admin bypass" is disproven and "the shipped sets ship a wildcard export grant" is proven.

Four-prism block

• ① Platform long-term coherence — (a). member_default's * wildcard object grant (C/R/E) union-merges into every org member — app-side explicit-allow object gates are erased on three axes #5491 / PR fix(plugin-security): enforce both declared write-wideners; the platform baseline becomes explicit-allow (#5492, #5491) #6684 already removed the member_default wildcard on the CRUD axes for this exact reason. The export axis keeping its wildcard is the leftover inconsistency, not a deliberate posture. (a) finishes a decision already taken; (b) adds a second mechanism to work around the first.
• ② Measured business pull — (a). A real app declares three objects exportable by nobody and the platform exports them anyway for any org admin, with no supported opt-out (403 [not_overridable] on the code-package metadata, and the org admin holds no app-authored set to put the false in). The pull is for the declaration to be true, not for a new authoring surface.
• ③ AI-agent error-resistance — (a). Today an app can declare "this object is exportable by nobody", ship, and be silently wrong. That is declared-≠-enforced on an export/exfiltration boundary — the worst axis for a silent gap. (b) leaves the wildcard in place and asks every app author to remember to counter it.
• ④ Startup scope discipline — (a). Removal, no new surface, no permanent obligation. (b) is a new authoring capability the platform would owe forever.

All four → (a). Human floor ⇒ yours to rule.

Recommendation

(a) — drop allowExport from the '*' entry of both shipped admin sets, following #5491's precedent exactly.

The one question that makes this breaking, stated plainly so it is not discovered after the fact: after (a), an org admin can no longer export anything they were not explicitly granted. That is the intended effect, and it is a behaviour change for every existing install whose admins export today. Two sub-questions:

1. Should the platform sets instead ship explicit per-object export grants for the platform's own objects, so admin tooling keeps working?
2. Does this ride the current train, or does it want a breaking-change note and a release boundary? (protocol:breaking is not applied yet — say the word and this seat applies it.)

⛔ Note for whichever seat implements it: partial enforcement (fixing one of the two sets) is rejected on prism ③ — a half-closed export boundary reads as closed and is not.

Evidence: hotcrm#1152 probes 40-707.mjs, 45-707-decisive2.mjs, 46-707-sysadmin.mjs.

---

Generated by Claude Code