Switching vaults

Members of one or more organizations have access to multiple vaults: their own personal vault, plus every organization vault they hold an active membership in. When they sign in, they pick one to act inside for the session. Every page, capability check, sidebar entry, and audit row resolves against that pick.

This page covers the picker, the session-level lock-in, and how project visibility differs depending on which vault a member is currently in.

The post-login picker

After sign-in (and after any required step-up), the dashboard checks the member's available vaults:

• One vault (only their own personal vault, no organization memberships). The picker is skipped; the session lands directly in the personal vault.
• Multiple vaults (personal vault plus one or more organization memberships). The picker renders inline on the login screen. The password field morphs into a vault dropdown, the Sign in button becomes Enter Vault, and the member chooses where to land.

The dropdown shows each vault's public ID, kind (personal or organization), name (organizations only), and the owner's username. The owner of an organization sees their own organization listed alongside their personal vault from the same dropdown.

Vaults whose owner has been destroyed or suspended are filtered out of the picker server-side. A member cannot enter an organization vault whose owner is no longer in good standing.

Why the pick is session-scoped

The chosen vault stays for the lifetime of the session — typically until the member logs out. To act inside a different vault, the member logs out and signs back in.

This is a deliberate trade. The alternative is a top-of-page vault switcher that lets the member jump between vaults mid-session, the way many SaaS products handle workspace switching. We don't do that because:

• Mid-session vault switching makes audit attribution harder to reason about. With session-scope, every action in a session is unambiguous: it happened in the vault the member entered at sign-in.
• Stolen sessions have a tighter blast radius. A captured session resolves against one vault, not every vault the user has access to.
• The picker is a deliberate prompt, not a hover. A member entering an organization vault sees its name and owner before they act — every time.

Logging out to switch is the cost of those properties.

What looks different inside an organization vault

When a member is acting inside an organization vault, the dashboard chrome shows the organization's name and owner. Sidebar nav entries are gated by the capabilities the member's template grants. Project entries follow the member's project scope: global access shows every project; a specific scope shows only the projects in the member's scope list.

A member with no template sees only the Overview and Settings pages of the organization, plus their own account-level surfaces (Sessions, personal Settings). Capabilities they don't have produce no UI entries — the member doesn't see grayed-out buttons; the buttons simply aren't there.

What looks different inside the member's own vault

Inside their personal vault, the member is the owner. Every capability is held unconditionally. Templates, scope, and organization gates don't apply — those concepts exist only for delegated members of someone else's organization.

If the member's own vault has been converted to an organization (they're an owner), they see all the same organization-management surfaces (Members, Templates) inside it.

Audit attribution

Every action a member takes is attributed to them in the vault they're acting inside. If you're an owner reading your organization's audit log, member actions appear with the member's username as the actor. The member, reading their own audit log (if their template grants it), sees the same rows from their side. The audit log doesn't aggregate across vaults — the personal-vault audit log and the organization-vault audit log are separate streams, scoped to the vault the action happened in.

Edge cases

A few specific situations and how they resolve:

• The owner of an organization is suspended or destroys their account. The vault drops out of every member's picker on the next login. A member's existing session for that vault is terminated on the next request (the server re-checks the owner's status on every authenticated request).
• A member is suspended mid-session. Their next request to the organization vault returns 401; the session is effectively cut at the gate.
• A member is removed mid-session. Same as suspension from the session's point of view. The member's membership row is gone; their next request fails. They keep their own SikkerKey account and personal vault.
• A member's template is changed mid-session. Capabilities resolve fresh on every request. The change is live by the next page load.

What machines see

Nothing about the vault picker affects machine authentication. Machines authenticate against a specific vault ID with their own Ed25519 keypair; they don't have a notion of "active vault" because they don't have a session in the dashboard sense. An organization is a human-side concept; the machine plane keeps the same per-vault, per-machine identity model it always has.