DATA RETENTION

Vallum keeps no payloads.

Vallum terminates and reissues every protected response, which means it sees all of your traffic. It stores none of it. Request and response bodies are transformed in memory and forwarded — there is no table, column, or cache key that holds one. What Vallum does keep is metadata, and the whole of it is listed below.

Zero payload retentionFingerprints stored as keyed hashesLast reviewed August 11, 2026

THE COMPLETE LIST

What is stored

Read the second column first. Most of what Vallum retains is a keyed hash or an enumeration, which is the difference between a system that can answer “were these two sessions the same actor” and one that can tell you who they were.

DataStored asWhereRetention

Request and response bodiesPayloadNot stored—None

Request paths and query stringsPayloadSHA-256 hash of the pathPostgreSQLLife of the organization

Client IP addressSessionHMAC-SHA256 keyed hashRedis, PostgreSQLSession lifetime

User agent and authenticated identitySessionHMAC-SHA256 keyed hashRedis, PostgreSQLSession lifetime

Session classification and risk scoreSessionEnum and integerRedis, PostgreSQLSession TTL, 24 hours by default

Security telemetryTelemetryEvent type, route, method, response status, latency, risk score, transformation typesPostgreSQLLife of the organization

Decoy and honeytoken activityTelemetryHash of the issued token, type, route, timestampsPostgreSQLToken TTL, then retained as telemetry

Route policy and transformation configurationConfigurationConfiguration you authored, as writtenPostgreSQLLife of the organization

Protected domainsConfigurationHostname, CNAME target, verification token, verification statePostgreSQLLife of the organization

Audit recordsConfigurationAction, hashed actor, configuration hashPostgreSQLLife of the organization

Console user identityAccountName, work email, organization membership, sessionsClerkUntil the user or organization is removed

Support ticketsAccountSubject, message text, and the name, email, and role of the person who opened itPostgreSQLLife of the organization

Request and response bodies: Payloads are transformed in memory and forwarded. No table, column, or cache key in Vallum holds a request or response body, and none is written to disk.
Request paths and query strings: Telemetry records a hash of the path, never the path itself, and query strings are not recorded at all. The hash is unkeyed, so treat it as a correlation key rather than as protection for an identifier embedded in a path.
Client IP address: The raw address exists only for the duration of the request and in the X-Forwarded-For header Vallum passes to your origin. What persists is a keyed hash, and the key is held outside the database.
User agent and authenticated identity: Fingerprint inputs are hashed with the same keyed construction. Vallum can compare two sessions without being able to name either one.
Session classification and risk score: Configurable per tenant. Redis entries expire on their own; the PostgreSQL row carries an explicit expiry.
Security telemetry: The accompanying metadata is bounded to counters, categories, and enumerations — a containment reason, a transformation count, a response size in bytes. It carries no fragment of the response itself.
Decoy and honeytoken activity: These values are generated by Vallum, not drawn from your data. A triggered token is what tells you something read a response it should not have.
Route policy and transformation configuration: Snapshots are versioned so a change can be attributed and rolled back. Origin URLs are stored as a hash, and per-tenant secrets are environment or secret-store references resolved outside the database.
Audit records: The actor is stored as a hash, so the trail proves who did what without holding a directory of your staff.
Console user identity: Vallum's own database holds no console credentials or profiles. See the service providers page.
Support tickets: This is the one place customer-written prose is stored, because a support thread is not useful without it. Do not paste production payloads into a ticket.

Deletion and export

Telemetry, sessions, decoy activity, policy, and audit records are all scoped to an application and are removed with it — closing an organization deletes them rather than archiving them. You can also request deletion of a single application's history, or an export of it, from the console at any time.

Where this data is processed, and by whom, is listed on the Service providers page. How it is handled in legal terms is set out in the Privacy Policy and the Data Processing Addendum.