Rehydration

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 to your app.

1. Step 1

   Provider responds

   The model returns text that may reference placeholders.

2. Step 2

   Map back

   The gateway scans the response and looks each placeholder up in the per-request mapping.

3. Step 3

   Return clean response

   Your app receives a rehydrated response. The mapping is discarded.

• 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

• Rehydration is per-request — placeholders are not stable across separate requests
• No native provider streaming — chunking is artificial in the beta

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.

• Concepts: Rehydration
• Concepts: PII Masking
• Product: PII Masking
• Product: LLM Gateway
• Category: AI Security Layer
• API reference