Appsec reviews whether a framework’s default memory and chat-history store encrypts resident conversations at rest. What control is being validated?
Select an answer to reveal the explanation.
Short Explanation
Chat memory is just another database of resident talk — if it sits on disk cleartext, it is a leak waiting for a backup tape. Check that the framework’s history store encrypts at rest. Climate jokes and localStorage-only plans do not replace server-side encryption.
Full Explanation
GenAI frameworks often persist conversation memory and chat history that can contain sensitive municipal resident data, so validating that the default memory store encrypts conversations at rest is a core data-protection control for civic applications. Appsec is checking data-at-rest protection for GenAI conversation state—including algorithms, keys, and key management—not model cleverness or temperature trivia. Encryption at rest reduces disclosure risk from disk theft, snapshot exposure, and misconfigured backups of chat memory stores.
Whether temperature settings exceed municipal climate goals is a distractor pun, not a security control relevant to conversation stores. Whether the model can invent encryption without key management misunderstands cryptography: durable protection requires real key management operated by the city or an approved KMS, not model improvisation. Whether chat history should be stored in browser localStorage only is a poor substitute for server-side protected stores and often worsens client-side exposure and loss of centralized retention control.
Exam caveat: framework "memory" defaults vary widely—never assume encryption is enabled without verifying configuration and key custody for municipal deployments. Operational check: review the framework's chat-history store settings, enable encryption at rest with city-managed keys where possible, restrict access to memory volumes and databases, set retention aligned to records policy, and confirm backups inherit encryption.