Getting started
Securing your API key
Keys live in the OS keychain. Never commit them to your vault or repo.
Why this matters
A leaked API key can rack up hundreds or thousands of dollars in charges within hours — this is not a theoretical risk, it happens daily. Automated scrapers comb public GitHub repos 24/7 hunting for strings beginning with sk-. Kition stores every API key in the OS-level keychain by default and only writes a reference placeholder to disk — so even if you push the entire vault to a public repo, no usable key goes with it.
Where keys live
Kition does not roll its own crypto — it uses the platform-native credential store. That is meaningfully more secure than a hand-rolled scheme and shares infrastructure with your SSH keys, browser passwords, and so on.
- macOS: Keychain (search "Kition" in Keychain Access)
- Windows: Credential Manager (Control Panel → Credential Manager → Windows Credentials)
- Linux: Secret Service D-Bus protocol (GNOME Keyring / KWallet)
- Headless Linux: falls back to an encrypted file at
~/.config/kition/secrets.gpg
# macOS: inspect what Kition stored (will prompt for your login password)
security find-generic-password -s "kition.openai.personal" -g
# Linux: list everything Kition wrote to the Secret Service
secret-tool search application kitionAvoid leaks
The most common leak path is not a breach — it is carelessness. Pasting a key into a doc to debug, committing .kition/config.json to Git, screenshotting the settings page — every one of these has happened.
- Never paste a key into a doc — let the agent reference the provider instead
.gitignoreexcludes.kition/secrets/and.kition/cache/by default- Use read-only / rate-limited keys (Anthropic budgets, OpenAI project-scoped keys)
- Before screenshotting, collapse the key field in Settings (the app masks it as
••••••) - Keep prod and experimentation keys separate so you can rotate fast
- Rotate quarterly at minimum
Recommended `.gitignore`
When pushing the vault to Git, use this .gitignore — it blocks every directory that could carry sensitive material while keeping the things you actually want versioned (docs, table schema, provider metadata).
# Secrets and per-machine state
.kition/secrets/
.kition/cache/
.kition/history/
.kition/index/
# OS noise
.DS_Store
Thumbs.db
# Large binary attachments you may not want in Git
Resources/*.mp4
Resources/*.zipCheck whether a key already leaked
If you suspect a key leaked: rotate it immediately (revoke the old key in the provider console, issue a fresh one), then audit usage. OpenAI and Anthropic both expose per-key usage dashboards; an abused key usually shows requests from unfamiliar regions or models you do not use.
- OpenAI: Platform → Usage, filter by API key
- Anthropic: Console → Usage, filter by API key
- GitHub: scan history with
trufflehogorgitleaks - Set a monthly billing alert to cap exposure
Multi-account and team scenarios
In team scenarios, give each vault its own provider — work vault uses the company-issued key, personal vault uses yours. When you leave or hand off, revoke the work key and your local data needs no migration.
Do not want to store the key locally at all? Point the sidecar at a corporate LLM gateway — the key stays on the gateway side. Kition only needs the gateway URL, and calls get billed against your identity.