Shared-Machine Logout Automation: The Account That Never Actually Left

A multi-account switcher exists specifically to make it convenient for one browser to hold onto several people's saved sign-ins at once — genuinely useful on a person's own private device, switching between their own multiple accounts. The exact same convenience becomes a real privacy question the moment that browser is SHARED — a kiosk, a front-desk computer, a borrowed laptop — because the feature's entire premise (remembering an account so it's there next time) is precisely the behavior that needs to stop, deliberately and completely, the moment that specific account's own person is genuinely done using that shared machine. A feature can be correctly built for its own primary use case and still leave exactly this gap for the secondary, shared-device case, if logging out was never specifically tested against a browser holding more than one saved account.

Testing a logout flow by signing in as one person, then logging out, and confirming that person's own session correctly ends is a natural, thorough-feeling way to verify the feature — and it produces a completely correct result for exactly that scenario. The gap this specific class of defect lives in only becomes visible when a SECOND, different person is deliberately introduced into the same test: does the browser now show any trace of the first, departed person's account? Does the second person land in their OWN correct context, or the first person's? Those are meaningfully different questions from "did my own logout work," and a test plan built around one account at a time has no natural opportunity to ask them.

A dedicated internal audit of Centriu Helix's own logout flow, conducted on a shared browser scenario specifically, found two related gaps. First, Helix's multi-account switcher — designed to let one browser conveniently hold several saved accounts — never removed the departing account's own cached entry, including personal information and locally-held authentication tokens, when that specific account logged out; the entry remained listed in the switcher exactly as before, as if that person were still available to resume their session with one click. Second, the browser cookie recording which organization a person was actively viewing (the same cookie this pillar's companion page on Centriu Helix's organization-resolution hook describes introducing) was never explicitly cleared when logging out — meaning the very next person to open Helix in that same physical browser, even a genuinely different, properly-authenticated person, could silently inherit whichever organization the PREVIOUS person had last been viewing as their own default context.

The fix is deliberately targeted rather than total. On logout, the system captures the departing person's own identifier before their session is revoked, then evicts specifically that one account's own entry from the local multi-account switcher — never calling a blanket clear-everything operation, which would incorrectly discard any OTHER people's legitimately saved accounts sharing that same browser. Separately, and unconditionally on every logout regardless of the multi-account switcher's own state, the organization-context cookie is explicitly cleared server-side, ensuring the next person to authenticate on that browser starts from a genuinely neutral state rather than inheriting anyone else's prior context.

A related, independent hardening landed in the same change: the same underlying API route that reads and writes the organization-context cookie now also performs an explicit check, when a request carries an Origin header, confirming that header's host genuinely matches the request's own Host header — rejecting the request outright with an explicit "forbidden origin" response if the two disagree. This adds a direct, explicit defense against cross-site request forgery on top of the cookie's own existing same-site attribute, which already provided meaningful but implicit protection; the explicit check is deliberately permissive when a request carries no Origin header at all, since a genuine same-origin request can legitimately omit one.

Before the fix, a person logging out of Centriu Helix on a shared computer would see their own session correctly end — but their account remained listed in the multi-account switcher, and the next person to sign in on that same browser could land directly inside the previous person's own last-viewed organization by default. After the fix, logging out removes exactly that one account from the switcher, and the next person to authenticate on the same browser starts from a clean, neutral context, correctly scoped to their own actual organization from the first screen onward.

Logging out of Centriu Helix on a shared browser now removes the departing account's own cached entry from the multi-account switcher and clears the active-organization cookie unconditionally, closing a gap where the next person to use that same browser could see a previous account still listed and could silently inherit that person's own last-viewed tenant context — with an additional explicit Origin/Host check now hardening the same underlying API route against cross-site request forgery.

This automation covers specifically what a shared browser retains after someone logs out of Centriu Helix — local account caching and tenant-context state, not session validity itself. It is a distinct mechanism from this pillar's separate wave 89 page on logout not revoking the underlying SERVER-SIDE session (a `local`-scope sign-out call) — this page's gaps are entirely about what a browser keeps locally after a session HAS already ended correctly, a different layer of the same broader logout flow.

Clearing every locally-saved account on any logout is the simplest possible implementation, and it would technically close the specific gap this fix addresses — but at a real, disruptive cost on any shared browser genuinely holding more than one person's legitimately saved account: everyone else's saved sign-in would be discarded too, the moment any ONE of them logged out. Evicting only the specific account that is actually logging out, identified before its own session is revoked, is the only version of the two that closes the privacy gap for the departing person without imposing an unrelated inconvenience on everyone else sharing that same browser.