[Compliance] Search disclosure #552

Summary

Page content is stored as plaintext for search/AI functionality. Internal security docs cover this tradeoff, but there is no explicit public-facing "known tradeoffs" section explaining it to customers and security reviewers.

Current State

Plaintext storage is intentional and documented internally:

• packages/db/src/schema/core.ts line 30: content: text('content') — plaintext text field
• apps/web/src/app/api/search/route.ts: uses ilike(pages.content, ...) for regex search
• docs/security/compliance-sovereignty-analysis.md explains: "Database content stored as plaintext was a deliberate design decision — it enables regex search for the AI system"
• Security posture assessment states: "Page/chat content is plaintext at the application layer (intentional tradeoff for search/AI workflows)"
• Public blog mentions regex_search capability (implying plaintext storage)

What's missing:

• No explicit public-facing page or section that states the tradeoff directly
• No "known tradeoffs" section in marketing security docs
• No deployment guidance distinguishing when this is acceptable (self-hosted) vs higher-compliance contexts
• No mitigation guidance (infrastructure encryption, access controls, backup controls)

Proposed Work

1. Add "Known Tradeoffs" section to public security documentation (apps/marketing/src/app/security/ or /docs/security/)
2. Clearly state: plaintext storage enables search/AI, mitigated by infrastructure encryption at rest
3. Add deployment guidance: when this is acceptable vs when additional controls are needed
4. Add mitigation guidance (disk encryption, access controls, backup encryption, provider choices)

Acceptance Criteria

• Public security docs include explicit plaintext storage tradeoff explanation
• Deployment guidance for different compliance contexts
• Mitigation guidance documented
• No over-claiming in customer/security communications