Security & privacy
How the CLI and platform protect your token, your data, and your machine. For the full security and data-handling story, see the Trust Center.
Authentication
- PKCE login.
stn loginsends a hashed challenge and only redeems the token with the matching verifier, so the browser-visible session id alone is useless to an attacker. - Token transport. The CLI refuses to attach your token to any non-HTTPS host that isn't loopback — a misconfigured or hostile endpoint can't capture it in clear text.
- File permissions. The config file holding your token is written owner-readable only, atomically.
- Scoped API tokens are read-only and limited to two scopes; see API tokens.
Local capture is opt-in and redacted
- Git context is captured locally with no network. Shell history
(
--shell), AI sessions (--ai-session), GitHub (--github), and editor state (--editor) are all opt-in flags onstn checkpoint. - Secrets (tokens, keys, passwords, bearer values) are redacted from shell history before it leaves your machine, and credentials are stripped from git remote URLs.
- The CLI never auto-loads a working-directory
.env— see Configuration for why.
Server & integrations
- Integration tokens are encrypted at rest and only decrypted in the background worker, never on the web request path.
- OAuth install flows use signed, expiring state and re-check team-admin permission on the callback.
- Inbound webhooks are authenticated by HMAC signature and deduped; bad signatures are rejected before any processing (see Inbound webhooks). Slack requests are verified with Slack's signing secret.
- Validation. Unknown
@handles and invalid severities are rejected before anything is sent; PR references handed to your localghare validated to prevent argument injection.