OS Keychain & Secret Storage
OpenHuman uses operating system secure credential storage to protect keys that must remain on your device.
On desktop builds, this means:
- macOS: Keychain
- Windows: Credential Manager
- Linux: Secret Service / libsecret
This is the trust root for local key material. OpenHuman does not rely on plaintext .env files or plaintext local config files to store user credentials.
What Goes in the OS Keychain
OpenHuman uses two types of local key material with the OS keychain:
1. Credential Entries
When a feature needs a local credential slot, OpenHuman stores it in the platform keychain rather than writing the raw key into a plain config file.
Examples:
- Provider API keys stored locally
- Session and bearer tokens that must remain on device
- Applicable wallet key material
These entries are scoped under OpenHuman's own key namespace and won't conflict with unrelated applications.
2. Master Encryption Key
Some sensitive values still need to live inside files because the application configuration itself is file-based.
OpenHuman handles this separation by:
- Storing the key value on disk as encrypted ciphertext
- Keeping the master key for decryption in the OS keychain
This means your local config and state files can contain encrypted values, with the decryption key not sitting next to them in plaintext.
What Stays Encrypted on Disk
When OpenHuman needs to persist sensitive app settings locally, it writes ciphertext to disk while keeping the key in the OS keychain.
Local keys covered:
- BYO API keys for provider support
- Channel and webhook keys stored in local config
- Other locally persisted key settings required by desktop features
The encryption format is authenticated, so OpenHuman can detect tampering rather than silently accepting modified ciphertext.
In practice, the security model is:
- Key is in the keychain
- Ciphertext is in the file
- Decrypted only in memory when needed
Why This Is Better Than Plaintext Config
If your machine has local workspace backups, sync folders, or support packages, keys in plaintext config files are a liability.
Using the OS keychain as the root key store gives OpenHuman a safer separation:
- Config files can be copied without exposing raw credentials
- Accidental logs or file checks are unlikely to leak keys
- Decryption keys are delegated to the platform credential system rather than app-managed plaintext files
Managed Integrations & Local Keys
Not every key follows the same path.
Managed Integrations
For default managed integration flows, third-party OAuth tokens are handled by the OpenHuman backend. Your local app doesn't need to keep those provider tokens in plaintext on your machine.
Local BYO Credentials
When you choose the bring-your-own-key or direct mode path, OpenHuman treats these credentials as local keys, protected by the OS keychain and encrypted disk storage where needed.
Migration from Old Versions
Old versions may have kept local encryption material in file-based forms.
Current desktop builds migrate that material to the OS keychain while keeping encrypted payloads on disk. The goal is root keys moving out of plain files and into platform credential storage without requiring users to manually re-enter every key.
Next Steps
- Privacy & Security - Complete security picture
- Third-party Integrations - Integration security