Most of Shellius is shared: servers, policies and the Keystore belong to the organization. The personal vault is the part that belongs to you. It holds personal identities and SSH keys, and My hosts — a private address book of SSH targets.

Use it for machines that are yours rather than the team's: a home lab, a personal VPS, a sandbox. It gives you the browser terminal, host key pinning and encrypted storage without putting those hosts in front of your colleagues.

Who can see what

Scope	Who sees and uses it
Organization	People with keystore.view see it and keystore.manage edits it. It can be bound to servers and used for key deployment. See Keystore.
Personal	Only its owner. Nobody else — not an admin, not a super admin — can list, read, use, edit, export or delete it through Shellius.

Someone else's personal item does not return "forbidden"; it returns "not found", so its existence cannot be probed.

What admins do see

Actions on personal items are written to the audit log like everything else — names and ids, never secrets. Sessions to personal hosts appear in the session list and follow the organization's recording rules. Private storage is not private activity.

Required permissions

Permission	Default roles	Allows
vault.use	Every built-in role	Keep personal identities and keys, use them in Quick Connect and My hosts, export your own keys.
vault.hosts	Every built-in role	Save personal hosts and connect to them.
quick_connect.use_stored_identity	Admin, Super admin	Use an organization identity on a personal host.
keystore.manage	Admin, Super admin	Move your own personal item into the organization Keystore.
org.access_settings	Super admin	Turn the personal vault on or off for the organization.

Both vault permissions can be removed from any role under Administration → Roles.

Turn the vault on or off

Under Administration → Access rules, the Personal vault switch controls the whole feature. It is on by default.

While it is off, personal identities, keys and My hosts are hidden and unusable for everyone. Nothing is deleted — turning it back on restores what was saved.

Keep a personal identity or key

1. Open Keystore and switch the scope from Organization to Personal. (If you have no access to the organization Keystore, you land on Personal directly.)
2. Use New identity, Generate key or Import key exactly as in the organization Keystore.

Personal scope has no Export to servers tab, because personal keys are never deployed to organization servers.

Names are unique per scope: two people can each have an identity called home.

Add a host to My hosts

1. Open My hosts (g then h) and select Add host.
2. Enter a name, the host, the port (22 unless you change it) and a username.
3. For Identity, pick one of your identities, or choose Ask each time to be prompted for a password or key on every connect. The username is required when there is no identity.
4. Optionally add a description and tags, then save.

To connect, open the host from the list. With Ask each time, Shellius asks for a password or private key first; it is used for that session and not stored.

You can also send a host here from a Quick Connect session with Save to My hosts.

My hosts are not servers

A personal host never appears in the server inventory, policies, approvals, dashboards, health checks, global search or the terminal client. There is no access request to make and nobody to approve it.

That is only safe because of what a personal host cannot reach. Connections go through the same ticket engine as Quick Connect, with the same guards:

Guard	Behaviour
Production hosts	A target matching a saved prod server, by name or resolved address, is refused.
Deny policies	A deny policy on a matching saved server still applies to you.
Internal targets	Loopback, link-local, cloud metadata, unspecified and multicast addresses are refused.
Host keys	Pinned on the first successful connection and checked on every one after. You can reset the pin on your own hosts with Reset host key.

My hosts does not depend on the Quick Connect permission or its organization switch. It has its own permission (vault.hosts) and its own switch.

Rules that keep the scopes apart

• A personal identity can only use your personal keys; an organization identity only organization keys.
• Personal identities and keys can never be bound to an organization server, used for key deployment, or used when saving a Quick Connect target as a server.
• Personal items and My hosts are never returned by global search.

Move an item to the organization

If something personal turns out to be shared infrastructure, its owner can hand it over. In the item's detail view choose Move to organization…. This needs keystore.manage as well as ownership.

Moving an identity takes its key along, provided no other personal identity of yours uses that key. The move is one-way, it is audited, and it is refused if the organization already has an item with the same name.

When someone leaves

• Suspending a user keeps their personal identities, keys and hosts. They are unusable while the account is suspended.
• Deleting a user deletes their personal identities, keys and hosts with the account.

Nobody can recover a personal item

Because admins cannot read personal items, they cannot rescue them either. Move anything the team depends on into the organization Keystore before an account is deleted.

Next steps

KeystoreThe shared, organization-scoped counterpart.Quick ConnectOne-off sessions, and saving a target to My hosts.Team and rolesGrant or remove the vault permissions per role.Threat modelWhat Shellius protects, and what it trusts.