What Is Rehydration (Restoring Masked Values)?

Where does rehydration fit in the flow?

Take a support reply drafted with an AI model. The agent's prompt contains a customer's name and email. Masking replaces both with random tokens before the prompt leaves. The model never sees the real values, but it can still write a sensible reply because it knows a person is being addressed. Rehydration is what turns the reply back into something an agent can send.

Your app sends:    Write a reply to Ada Lovelace (ada@example.com) about her refund.
Provider receives: Write a reply to mf_mask_170b... (mf_mask_4e21...) about her refund.
Provider answers:  Dear mf_mask_170b..., we have started your refund...
Rehydrated reply:  Dear Ada Lovelace, we have started your refund...

This is the restoring half of reversible tokenization. Without it, masking would protect the data but leave people editing placeholders by hand. With it, masking can stay on for most traffic without making the answers worse.

How does Maskflare rehydrate responses?

• Opt-in per API key. Restoring is a setting on the gateway key. Keys without it return masked answers.
• Only tokens the response carried. The gateway notes which tokens appear in the provider's raw answer and restores those. A value the model writes in clear is masked as usual, not restored.
• Scoped to the key. Tokens resolve only for the key that created them. Another key's token, or an unknown one, stays as it is.
• Streaming works. For server-sent events, text is restored as it streams, holding back only a fragment that could still become a token. See the AI gateway.
• A status you can check. Documents carry an X-Maskflare-Rehydration header with full or partial, and traffic events record the same outcome and the number restored.

Originals are kept encrypted so tokens can be resolved for 30 days. The prompts and responses themselves aren't logged or stored. The detection engine describes how tokens are created.

When does rehydration come back partial?

Partial means some tokens stayed masked on purpose or because something prevented the restore. The cases:

• The token store was unavailable, in which case tokens stay masked and the response is still delivered.
• A token belonged to another key, or has expired.
• A very long response is streamed without being buffered, so it is masked but not fully restored.
• A stream needed a lookup that took longer than the time allowed for it, and the remaining tokens stayed masked.

In every case the failure direction is the safe one: the reader sees a token instead of the original, never the other way around. Compare the fail closed vs fail open choice for masking itself.

What can go wrong because of the model?

Rehydration is a string replacement on tokens, so it depends on the model leaving the tokens intact. Three behaviours cause trouble.

1. Rephrasing. Asked to "rewrite politely", a model may turn mf_mask_170b... into "the customer". The name isn't coming back, and that is also fine: the answer no longer needs it.
2. Mangling. A model can shorten, reformat or break a token. A damaged token doesn't match anything and is left as it is.
3. Inventing. A model can write a name of its own in the same place. That is ordinary text and isn't touched, but it also means the answer may now name a person who is not your customer, so a human should read it.

Plan for human review wherever a name or number in the reply matters.

What is rehydration not?

• Not decryption of the provider's data. The provider never had the originals, and rehydration doesn't give them any.
• Not available everywhere. Embeddings and batch uploads are not rehydrated, and an answer returned as newline-delimited JSON is not restored.
• Not a way to make masking reversible forever. After the token lifetime of 30 days, an answer you stored with tokens in it will not restore.
• Not needed for every flow. If nobody needs the real value back, such as a summary for analytics, plain redaction is simpler. See data redaction vs data masking.

Is rehydrated text personal data?

Yes, once it is restored, it is ordinary personal data in your system and your normal rules apply to it: access, retention, deletion. The prompt that left your control carried tokens, not names. Whether that makes the provider's copy personal data depends on whether they can reverse it; the neighbouring question is covered in are pseudonymised prompts personal data. This is not legal advice.

The SDKs expose the same operation if you work outside the gateway: unmask and unmask_text in Python, unmask and unmaskText in TypeScript.