Security: Protect stored credentials and make API secret fields write-only #101

Summary

credentials.py:59 writes the complete credential dictionary to JSON. main.py:883 returns an LLMConfig containing api_key without authentication. A disposable key was recovered both from the saved file and the GET response. Catching write failures also allows a setting operation to appear successful without durable storage.

Environment and evidence

• Review finding: F01 (2026-10-05 product/technical review).
• Baseline: Windows, dev at c1c5dbe. The remote dev matched this commit when filing.
• Evidence: Reproduced.
• Priority recommendation: P1 - proposed first-release blocker. This is review triage, not a production-incident severity declaration.
• No real credentials, paid inference, engine installation, or unrelated process termination were used for review probes. Mocked observations establish the stated code behavior, not live-provider/GPU acceptance.

Reproduction or validation

An isolated CredentialManager saved a dummy value to its JSON file without encryption. A FastAPI TestClient request to the LLM configuration read API returned that same dummy value. No real credential was accessed. Public evidence is limited to this remediation summary; no credential or exploit payload is included.

User impact

A local client can retrieve an API credential; UI assurances about protected storage overstate the implementation.

Proposed approach

Use OS-backed secret storage where supported, return redacted/write-only secret fields, and surface save failures. Verify no API response, log, export, or project serialization contains a complete key.

Acceptance criteria

• Persist secrets using an appropriate OS-backed facility and document platform behavior.
• GET and save responses return only redacted/configured state, never a complete secret.
• Failed persistence produces an actionable error rather than reporting a durable save.
• Regression tests cover response, log, project, and export redaction.

Verification scope

Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target dev under the repository's contribution/branching rules.