An auditor asks where an in-memory tier's session records exist in plaintext outside the server process — what do you answer?

## The question behind the question The auditor is not asking about memory. They are asking where the entries exist in a form some other party can read, and an in-memory store has three such places outside the process — plus one inside it that people forget. Naming all of them, with what varies, is the whole answer. ## 1. On the hop Unless the connection between caller and server is encrypted, the entries cross the network readable. So does the credential, on stores that present one at connection setup. Anything that can observe traffic on that path — a compromised host on the segment, a mirrored port, a platform's own traffic capture — sees session records as plainly as the application does. What varies is who terminates the encryption. Some servers in this class can terminate an encrypted connection themselves; others cannot, and the established pattern there is a terminating proxy or an encrypted tunnel placed beside the process, so the unencrypted hop is reduced to a local one. Either way it is a deployment decision, never a default. It is worth being precise about what encrypting the hop buys: - **It buys** confidentiality and integrity of the bytes in transit, and it stops a credential being lifted off the wire. - **It does not buy** identity. The caller is not established by an encrypted connection unless both ends present proof during setup. Encryption and the server's credential check are separate controls that answer separate questions. - **It is not free** — there is a setup cost on each new connection and a per-byte cost on the transfer. ## 2. In the copies on disk If the deployment writes copies at all — a periodic whole copy, a replayed log of writes, or both — then the entries are on a volume, and anyone who can read that volume can recover them. This is the place people miss, because the component is described as in-memory and the disk copy feels like an implementation detail of restarting. Whether the server can encrypt what it writes varies; many cannot, and the encryption at rest is whatever the volume or the storage layer provides. That distinction matters, because volume-level encryption protects against a stolen disk and not at all against an operator, a debug container, or a process on the host that can read the filesystem. ## 3. In the backups of that volume The backup is a second copy, and it is the one that escapes. It usually lives in a different account or bucket, under access rules written for durable databases, owned by a different team, and kept for a retention chosen without reference to the entries inside it. ## The retention mismatch, stated plainly | Where the entry is | How long it lives there | Governed by | |---|---|---| | The tier itself | Until its deadline passes or it is removed under pressure | The lifetime attached to the entry | | A copy on disk | Until that copy is superseded or deleted | The copy schedule and the volume's lifecycle | | A backup of that volume | The backup retention, commonly months | A policy written for durable data | This is the finding that surprises teams: **a lifetime is a freshness and memory-reclamation mechanism, not a deletion guarantee for the data**. A record that was supposed to be gone in an hour is in a backup for a quarter. ## And one place inside the process Host memory itself. A process dump, a swapped page, or a host-level memory capture contains entries in the clear, and so does a human attached through an operator interface, who reads exactly what the application reads. The control there is who may attach and from where, and whether the attachment is recorded — not anything about the entry. ## What to answer, concretely - Is the hop encrypted, and where is it terminated — in the server, or in a component beside it? - Does the deployment write copies at all, and if so is anything encrypting them, at which layer? - Who can read the volume, and who can read the backup destination, with what retention? - Who may attach an operator interface to a live instance, and is that attachment recorded? - Does anything else copy this data — an export for troubleshooting, a lower environment loaded from a backup? ## What not to claim Do not claim that short lifetimes bound the exposure; do not claim that "it is in memory, so it is gone when the process stops" — that is true only where nothing was written and nothing observed the traffic. And do not present an encrypted hop as an answer to *who reached it*; that is the credential check's question, and on some stores in this class there is no credential check to ask it.