- Shipped
- September 6, 2026 at 6:40 PM UTC
- Author
- Kamo
- Commit
- 35e72c4
MANAGE_USERS reached the break-glass identity. UserAdminController guarded only the System User, so a non-god holder could disable a god account and revoke its live sessions, rewrite its sign-in identifiers, flag it synthetic, or mail a password reset for it — every one of them a way to disarm the people who would otherwise undo it. The console already drew the row as untouchable and said so in a comment; nothing behind the screen agreed. GodAccountGuard applies the peerage rule PlatformAdministratorController already held over a god's platform RIGHTS to the account those rights hang on. The account was the weaker of the two doors: taking somebody's password is a superset of taking their rights. It guards all five write paths, and UserAccountEditPolicy's PLATFORM_ADMIN arm, which is the same right's other surface — the member profile's identity update and both personal-address endpoints. Reads stay open, so the console can explain the refusal. The target fails closed and the caller fails open, deliberately: a row that cannot be read is god, a row that does not exist is not, and a caller who cannot be resolved is not. Only ever lifting a restriction is what decides which way each side goes. Impersonation gets the same target refused, with no peerage at all. The cross-org door has always refused a god **************** the same-org door behind the settings page never did, which made it the cheaper of the two ways in. Impersonating a god hands the caller the platform's last way back in, so it admits no exception — not even for another god. Responses now carry callerIsGod, and the member payload carries accountIsGod for a god-eligible reader. Without them the console has to lock every god row for everybody, including the one caller entitled to the edit.