Security

The Jorli CLIs are built on a strict trust stance inherited from Jorli itself: your data stays on your machine, your credentials stay in your OS keyring, no analytics phone home.

What the CLIs touch

• Your OS keyring — to store your broker credentials (client-id / access-token / API key / API secret). See Concepts › Secret storage for the per-OS store used.
• A small AES-GCM encrypted file as a fallback when no OS keyring is available (Linux headless, WSL). On Linux the file lives at ~/.config/<tool>/secrets.dat; the adjacent secrets.key is chmod 0600 on non-Windows. macOS uses the Keychain directly and does not use this file fallback.
• Loopback callback port 17890 (default) — only on 127.0.0.1, used for the browser-login redirect. Never listens on a public interface.
• A non-secret preferences file at %AppData%/<tool>/config.json — base URL overrides, redirect port. No secrets live here.
• The broker’s REST API — the only network the CLI ever talks to.

What the CLIs don’t touch

• No telemetry. The binary does not phone home. There is no usage ping, no update checker, no crash reporter. The update command prints a GitHub release URL; it does not fetch version info automatically.
• No third-party analytics. No Google Analytics, no Sentry, no Mixpanel.
• No token exfiltration. Your access token only travels in the Authorization header to the broker. It is never logged, never written to disk in plaintext.
• No “first-run” survey. No registration, no email capture, no opt-in toggles.

This stance is deliberate — it mirrors Jorli’s own “privacy-first is the trust signal” brand pillar. Indian trading is drowning in tip-sellers, Telegram pump groups, and data harvesters; “we don’t even run analytics on you” is a radical differentiator and it applies to these CLIs exactly.

The OS keyring is the trust boundary

If your machine is compromised, your broker credentials are at risk regardless of how they are stored. The CLIs prefer the OS keyring because:

• It’s encrypted at rest by the OS, keyed to your login identity.
• It’s audit-able via the OS’s own tooling (Credential Manager, security find-generic-password, secret-tool).
• It’s wiped independently of the binary — uninstalling the CLI does not wipe the keyring entry. Use auth logout --forget-app (Kite) or auth logout --forget-client-id (Dhan) to remove stored credentials before you uninstall, hand off, or recycle a machine.

You can verify what’s stored at any time:

kite auth status --json --no-color
dhan auth status --json --no-color

These commands print only booleans (apiKeyStored, accessTokenStored, etc.) — they never print the secret values themselves.

The --verbose flag and transcript hygiene

--verbose writes raw broker error payloads and SDK stack traces to stderr. This is useful when debugging an API failure but dangerous in a shared transcript — error bodies can include headers, request fragments, or other sensitive metadata.

• Avoid --verbose in shared logs.
• When sharing a transcript, redact with placeholders: <api_key>, <api_secret>, <request_token>, <access_token>, <client_id>.
• Never run auth configure verbatim in a public transcript — the secret value will be captured directly in your shell history and the transcription.

TLS connections use standard .NET HttpClient defaults (TLS 1.2+ on modern .NET 10 builds). The CLIs do not pin certificates, do not disable certificate validation, and do not intercept traffic.

Reporting a security issue

If you find a credential-handling bug or a leak in either CLI, contact jorli@techriff.in. Don’t file a public issue with reproduction steps that include real credentials.