Summary
Create a living threat model document covering audit data in mcp-proxy. At minimum:
- Data residency: where audit data lives today (local SQLite) and where it's expected to go (remote storage for enterprise/power users)
- Trust boundaries: passphrase source (env var), storage layer, transport
- Threat actors: who might target audit data and what they'd gain
- Assumptions: what must hold true for the current design to be safe (e.g., "passphrase is unique per installation")
- Open questions / provisional decisions: trade-offs that are acceptable now but need revisiting as the threat model evolves
Why
The fixed-salt issue (#54) was a design-level gap that no scanner could have caught. The root cause was an unstated assumption: "audit data stays local." A threat model that explicitly states data residency assumptions would have flagged the salt design as provisional from day one.
Could live as an ADR, a THREAT_MODEL.md, or a section in the security docs.
Summary
Create a living threat model document covering audit data in mcp-proxy. At minimum:
Why
The fixed-salt issue (#54) was a design-level gap that no scanner could have caught. The root cause was an unstated assumption: "audit data stays local." A threat model that explicitly states data residency assumptions would have flagged the salt design as provisional from day one.
Could live as an ADR, a
THREAT_MODEL.md, or a section in the security docs.