Product
Rehydration
The model sees placeholders. Your app sees real data.
After the provider returns its response, Privian restores the original values inside the gateway so the rest of your stack does not need to know masking happened.
Definition
What is rehydration?
Rehydration is request-scoped: only placeholders issued for the current request can be restored.
Rehydration is the egress counterpart of PII masking. Because placeholders are deterministic within a request, the gateway can look them up against the in-memory mapping and restore the original values before returning the response.
How it works
How rehydration restores values
Framework
Response restoration sequence
- 01
Receive
Accept the provider response containing placeholders.
- 02
Match
Look up issued placeholders in the current request map.
- 03
Restore
Substitute mapped original values in memory.
- 04
Discard
Return the response and remove the mapping.
Step 1
Provider responds
The model returns text that may reference placeholders.
Step 2
Map back
The gateway scans the response and looks each placeholder up in the per-request mapping.
Step 3
Return clean response
Your app receives a rehydrated response. The mapping is discarded.
Example
Response rehydration example
Masked provider response
I found the account for PERSON_1. Send the update to EMAIL_1.Response returned to application
I found the account for Michael Olsen. Send the update to michael@example.com.Why it matters
Why rehydration matters
- Drop-in for existing prompts — downstream code does not need to handle placeholders
- Preserves UX — users see the names and identifiers they expect
- No client-side mapping — the restore step stays inside the gateway
- Zero retention — the mapping is discarded after the response
Transparency
Beta limitations
- Rehydration is per-request — placeholders are not stable across separate requests
- No native provider streaming — chunking is artificial in the beta
FAQ
Frequently asked questions
- What is rehydration?
- Rehydration is the egress half of masking. After the provider returns a response, the gateway replaces deterministic placeholders (PERSON_1, EMAIL_2, ...) with the original values that were masked on the way in.
- Where does rehydration happen?
- Inside the Privian gateway, in memory, using the per-request mapping built during detection. The mapping is discarded after the response is returned.
- What if the model invents a placeholder?
- Unmapped placeholders pass through as-is. The gateway only rehydrates values it issued for the current request.
- Does rehydration work with streaming?
- Streaming in the beta is artificial — Privian chunks the already-rehydrated response. Native provider token streaming is not exposed yet.
Enterprise review
Questions buyers commonly ask
- Where are original values restored?
- Inside the gateway, before the response returns to your application.
- Is the token mapping retained?
- No. It exists in memory for one request and is discarded after the response.
- Can an invented placeholder reveal data?
- No. Only placeholders issued and mapped for the current request are restored; unknown placeholders pass through.
- Are placeholders stable across requests?
- No. Rehydration uses a request-scoped mapping rather than persistent cross-request identity.
Related
Related documentation
Scope
What this does NOT solve
Enterprise review
Built for enterprise review
Trust assets procurement and security teams routinely request.
Plans & pricing
Pricing for Privian's gateway and rehydration layer
Rehydration ships as part of the Privian gateway. Pricing is published transparently — Privian is in beta.