- Shipped
- September 4, 2026 at 10:41 PM UTC
- Author
- Kamo
- Commit
- 8f9222b
The member payload now carries accountOwnedByThisOrg. The console used to work this out for itself by comparing the READER's securityOrgId to the current organization — a fact about whoever is looking rather than about the person on screen. So the gate on the legal name was decided by whose account the ADMINISTRATOR held: an admin entitled to fix a colleague's name could be refused because their own account came from elsewhere, and one who was not could be offered the box. Only the server can see the target's account, so it answers. Deliberately NOT also enforced on the write, and the endpoint now says so where the next reader will look. Requiring the current organization to own the account sounds like the missing lock, but the platform provides the account for almost every tenant member — 77 of 141 memberships today — so it would mean no tenant administrator could ever correct a colleague's name and no tenant member could correct their own. That is precisely the defect the legal-name gate was added to fix, and re-creating it while calling it a security control would be worse than the gap. What guards this write is what always did: same organization, plus MANAGE_MEMBERS / MANAGE_MEMBER_SECURITY to rename anybody else. Also adds POST **************** to the unguarded-endpoint baseline with its justification. The ratchet was right to stop it: the endpoint is deliberately public, and that is a claim which belongs written down next to the others rather than discovered later.