API keys, TOTP seeds, and recovery codes
User-saved raw credentials are written to macOS Keychain under app-specific services. Key Ring asks for Touch ID or password unlock before revealing or copying these values.
Security model
Your secrets stay on your Mac.
Key Ring is built for the failure mode developers actually worry about: API keys, 2FA seeds, recovery codes, and local project paths leaking into chats, logs, screenshots, or cloud tools. The default path is local storage, local scanning, and explicit unlock before sensitive actions.
No cloud vault
Secrets are stored in macOS Keychain, not synced to a Key Ring server.
Touch ID unlock
Reveal, copy, import, backup, and write flows require local unlock.
Redacted telemetry
Scan history stores metadata, previews, and fingerprints, not raw values.
Agent-safe by design
Future agent tools should request actions, not print secrets.
What is stored where
Key Ring separates sensitive values from useful metadata. Raw secrets live in Keychain-backed vault records. Search, scanner, notes, tags, and UI state use local metadata so the app can stay useful without casually spreading secrets through local files or logs.
Metadata for search and audit trails
Provider, project, env name, source path, user notes, tags, timestamps, confidence, redacted previews, and SHA-256 fingerprints are stored locally so lookup, filtering, and duplicate detection work without exposing raw secrets. Key Ring rejects saving the raw key value into notes or tags.
Short-lived copy path
Copying is an explicit unlocked action. Key Ring shows copied state and clears copied credentials after a short timeout so they do not sit indefinitely in the clipboard.
Encrypted export, explicit restore
Backups are encrypted with a user-provided passphrase and are intended for migration or recovery. Restore is explicit and local; raw values are not printed during backup workflows.
Scanner guardrails
Secret scanning is useful only if it is precise and explainable. Key Ring classifies findings by confidence and keeps dotenvx public metadata separate from real API keys.
Matched, generic, ignored, and public metadata states
Findings are labeled by detector quality so users can separate provider-shaped credentials from generic strings, examples, public client config, and dotenvx metadata.
Encrypted values are not plain API keys
`encrypted:` values, `DOTENV_PUBLIC_KEY`, `DOTENV_PRIVATE_KEY`, `DOTENV_KEY`, and legacy vault metadata are handled as dotenvx state. Decryption happens locally only when the user has the right local key material and chooses that flow.
Redacted fixtures test false positives
The test harness uses synthetic fixtures to verify provider detection, duplicate handling, public/config exclusions, dotenvx behavior, and telemetry redaction without embedding real secrets.
Safe roots, explicit scans, and example-file controls
Automatic scans avoid protected user folders, manual scans are user-selected, and example files such as `.env.example`, `.env.sample`, and `.env.template` can be excluded from scanner output.
Agent workflows should not receive raw secrets
Key Ring’s agent roadmap is built around local capabilities: search metadata, ask for approval, write to a local env file, run a local command, mount an ephemeral file, or proxy a provider locally. The agent should get a result, not the secret value.
Copy/write/run/mount/proxy
- Write `OPENAI_API_KEY` into `.env.local` after local approval.
- Run `npm test` with short-lived local environment injection.
- Mount a temporary credential file and clean it up after the command exits.
- Proxy provider calls locally so API keys never enter chat or stdout.
No default `get-secret` tool
- No raw API keys in MCP resources.
- No TOTP seeds or live codes in agent transcripts.
- No unattended browser login, CAPTCHA solving, or DOM injection.
- No cloud-hosted tool output containing secret values.
Launch stance
The current Mac app is the product. Agent CLI/MCP is a security-led roadmap, not a reason to loosen the local-first guarantee.
Download Key Ring
Current limitations
Security pages should say what is true, not what sounds good. These are the launch-relevant constraints to understand before treating Key Ring as a long-term credential manager.
Private build first, broader trust next
The launch roadmap includes Developer ID signing, notarization, release checksums, and a clearer update path before broad public distribution.
Detection is being hardened
Provider-specific detector coverage and precision snapshots are active work. Users should review findings before importing or rotating credentials.
Local copy, not unattended autofill
Key Ring can store and copy TOTP/recovery codes locally. Apple-style AutoFill is future distribution/entitlement work, and unattended login automation is intentionally out of scope.
Metadata-only CLI foundation
The shipped CLI foundation supports telemetry, fingerprints, and access-request metadata. Full write/run/MCP workflows remain future work.