docs(security): threat model document — one page per subsystem

[cmeans-claude-dev]

Write a threat model doc committed to the repo. The act of writing it catches bugs that no scanner will.

Scope

docs/security/threat-model.md with one section per subsystem:

• MCP tool surface — trust boundary (remote MCP client), input sources, what an attacker controlling each tool input could do
• Edge-process intake (report_status, report_alert, add_context, etc.) — untrusted edges writing to the store; prompt-injection payloads embedded in content; scan_status expectations
• OAuth / auth middleware — token validation, JWKS rotation, fork-PR secret exposure (already hardened)
• RLS / multi-tenant isolation — current policies, FORCE ROW LEVEL SECURITY, _system schema carve-out, tenant-leak failure modes
• Background tasks — _cleanup_expired, embedding executor — what role they run as, what they can see
• Migrations / Alembic — forward-compat vs. backward-compat, what happens if a migration regresses a policy
• Deployment (Docker, Cloudflare tunnel) — edge layer trust, secret-path mount, WAF assumptions

Constraints

• One page per subsystem. Concise.
• Each section: trust boundary, data flow, what happens if an attacker controls each input, current mitigations, known gaps.
• Committed to the repo so future-you (and contributors) can update it.
• Link from README.md ## Security and SECURITY.md.

Why high-priority

The doc doubles as the pre-release checklist's what should I be worried about? reference. The alternative is implicit threat-modeling in every design decision — which is what's happening today and is error-prone.

References

Parent roadmap: security-tooling-roadmap-2026-04-22 (id 0d4007ce)
CD's recommendation (verbatim): "A written threat model document, one page per subsystem … The act of writing it catches more bugs than any tool."