Restore
How a tokenised answer becomes a usable one inside your perimeter, and what is deliberately not restored.
The path
The provider’s answer echoes the tokens it was given; that is expected behaviour, not a failure. Your application sends the answer to POST /v1/recover/text with the context it belongs to. The engine looks up the session, loads its restorable tokens, and replaces them in one left-to-right pass, longest token first so that a token that happens to be a prefix of another is never mis-matched.
answer Sayın PERSON_kxmrqa, ABN-4471822 numaralı aboneliğinizin mart faturası incelenmiştir.
restored Sayın Ayşe Demir, ABN-4471822 numaralı aboneliğinizin mart faturası incelenmiştir.
A token that is not known in this context passes through unchanged. Nothing is guessed, and nothing from another context or tenant is ever substituted.
Canonical form and casing
A cluster may have been seen in several surface forms, “Ayşe Demir”, “AYŞE DEMİR”, “Demir”. The vault keeps one canonical form and restores that. If the token sits inside an all-capitals segment, the value is upper-cased with Turkish rules so that “SAYIN PERSON_kxmrqa” reads “SAYIN AYŞE DEMİR”, not a mixed-case intrusion.
What is not restored
A value that first appeared in the model’s output, rather than in your input, is tokenised on the way back with restore disabled. It stays a token until the same literal value is later supplied as input by your side, which is the only way a value can become restorable. This stops a provider from introducing a guessed or hallucinated value and having it restored into your systems as if it were yours.
Authorisation and evidence
Restore requires an API key in the same tenant with the recover_text permission. Any such key can restore any context in that tenant, so give the permission to the component that delivers answers to people, not to the one that only sends prompts. Each restore is logged as a security event with the request id and the context; the restored content is never logged.
Streaming
The restore endpoint is synchronous. For streamed answers the LiteLLM guardrail restores incrementally: it keeps a buffer per call, screens a rolling window, commits restored text in steps and returns a hold-back count so the gateway never shows a token that has only partly arrived. See LiteLLM guardrail.
Format-preserving mode
In FPE mode there is no token to look up. Recovery decrypts the ciphertexts recorded for the document in a short-lived ledger, by document_id, within 128 recent documents in memory or one hour in Redis. After that, recovery returns 404. Use the vault for anything that needs to be restorable later.
All example values in this documentation are synthetic.