amal66 hardens the lockbox for AI provider keys

A focused security upgrade makes stored credentials less vulnerable to reuse if one record is exposed.

securityinfrastructure

amal66 has strengthened how the fork protects API keys used to connect legal workflows to external AI providers. Each saved credential now receives its own cryptographic salt, rather than relying on a more reusable protection pattern.

That is a quiet but meaningful defence-in-depth move: compromise of one stored record should provide less help in attacking another. The change also accounts for existing saved keys, preserving a route to read older records during the transition.

The catch is operational rather than conceptual. Anyone adopting it needs to handle the data migration carefully and retain compatibility with the prior protection method until every older credential has safely moved across.

So what Legal teams and product owners handling client-sensitive AI credentials should care because key storage is part of the security boundary, not administrative plumbing.

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`5762ee71`	fix(chapter-22): derive API-key encryption keys with HKDF salts	Amal	2026-05-24	↗ GitHub
commit body Chapter: 22 - User API key protection. Plain-English map: Replace static SHA-256 key derivation with HKDF and a unique salt per stored user API key row. Why it matters: Users may store real provider keys in Mike. Those keys deserve standard, reviewable cryptography instead of one shared derived key for every row. Principle: Use established key-derivation functions and per-record salts for encrypted secrets. Precedent borrowed: Upstream PR #76. Upstream base: willchen96/mike@d39f580. Original local commit: e0a64bd.

SHA

Subject

Author

Date

5762ee71

fix(chapter-22): derive API-key encryption keys with HKDF salts

Amal

2026-05-24

↗ GitHub

commit body

Chapter: 22 - User API key protection.

Plain-English map:
Replace static SHA-256 key derivation with HKDF and a unique salt per stored
user API key row.

Why it matters:
Users may store real provider keys in Mike. Those keys deserve standard,
reviewable cryptography instead of one shared derived key for every row.

Principle:
Use established key-derivation functions and per-record salts for encrypted
secrets.

Precedent borrowed:
Upstream PR #76.

Upstream base: willchen96/mike@d39f580.
Original local commit: e0a64bd.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-2008.md from inside the repo you want the changes in.