This page is written so you can decide whether Shellius fits your risk profile. It is deliberately explicit about what it does not protect.

What Shellius is trying to prevent

• Access that outlives its reason. Keys that stay in authorized_keys after someone changes team or leaves.
• Unreviewed production access. Reaching a production host without anyone agreeing to it.
• Revocation that does not take effect. Removing access but still having a working credential in the wild.
• Unattributed access. Connections that cannot be tied to a person.

Trust boundaries

Boundary	Assumption
Shellius server	Trusted. It holds the CA and can sign any certificate.
Target hosts	Semi-trusted. They hold the CA public key and a per-host agent token.
Users	Untrusted until authenticated; then limited by their permissions.
Network to targets	Not protected by Shellius. On browser routes the backend makes the connection; on client routes your machine does. See Network reachability.

What an attacker gets

If the Shellius host is compromised. Everything. They can decrypt the CA private key (the key is in the environment of the process they now control) and sign a certificate for any principal on any bootstrapped host. There is no recovery short of rotating the CA and re-bootstrapping every host. Treat the Shellius host as your most sensitive server — at least as sensitive as the fleet it grants access to.

They can also read any browser session in plaintext, because the backend terminates those connections and speaks to the target itself — the same property that makes session recording possible. Sessions opened from the terminal client do not pass through Shellius and cannot be observed this way. See Network reachability.

If the database is stolen but SERVER_ENCRYPTION_KEY is not. The CA private key and stored credentials are AES-256-GCM encrypted at rest and are not usable. The attacker still learns your inventory, users, policies, and audit history.

If a target host is compromised. They get that host's agent token, which can query the API about certificate validity. They do not get the CA private key — only the public key is on the host. They cannot mint certificates or reach other hosts with it.

If a user's session is stolen. The attacker has that user's permissions until the token expires or the session is revoked. If the user could request production access, so can the attacker — but the request is still reviewed and still audited, which is the point of the approval flow.

If an issued certificate leaks. It works until it expires or until access is revoked, because check-principals re-validates on every connection. Revocation is the fast path; do not wait for expiry.

What Shellius does not defend against

• A malicious approver. Someone who can approve can grant access. Approval is a control, not a cryptographic guarantee.
• A malicious operator. Anyone with access.prod_bypass, or who can edit roles, can widen their own reach. The audit log records it; it does not stop it.
• Network-level attacks against your hosts. Shellius does not protect the network itself.
• What someone does once connected. Session recording gives you a record after the fact, not prevention.
• A compromised target host lying to you. check-principals runs on the host; a root-level attacker there can bypass it locally.

Deliberate design decisions

check-principals fails closed. If a host cannot reach the API, no principals are returned and connections are refused. This trades availability for safety: an API outage locks people out. Keep a documented break-glass path that does not depend on Shellius.

Private keys are never stored. Keys issued for download are generated per request, returned once, and not persisted. If a user loses one, they request again.

The keystore is the exception. Stored identities and keys for hosts that cannot take certificates are encrypted at rest, never returned by list or get endpoints, and decrypted only at connect or deploy time. It is a deliberate weakening for hosts you do not control; prefer certificates.

The audit log is append-only. There is no update or delete path in the application. An attacker with direct database access can still alter it.

If you are evaluating this for compliance

Shellius gives you reviewed access, bounded credential lifetime, immutable application-level audit, and session replay. It does not give you a tamper-evident log, an HSM-backed CA, or separation of duties strong enough to stop a determined administrator. Judge it accordingly.

Reporting a vulnerability

Email [email protected]. Do not open a public issue. See SECURITY.md.