Replace sensitive values, with controlled restoration

The initial work focused on a local step before language-model processing: detecting identifying values and preparing text with values removed or replaced.

Some workflows need an original value again. Reversible substitution keeps an association between the original and its replacement, so authorized local processing can restore it later.

The gateway gives irreversible removal and reversible substitution separate interfaces. Reversible substitution is also called pseudonymization: the identifying values change, while a controlled route back to the originals remains.

The reversible workflow stores the association locally and encrypts the original values. Each session uses key material derived specifically for that session.

Restoration requires a separate authorization token. The store checks its fingerprint against the saved authorization record and checks session expiry. The replacement text alone does not provide that authority.

Retaining the mapping does not give every recipient of the substituted text permission to restore it.

The restoration code recognizes exact replacements and registered aliases. It avoids overlapping replacements and skips ambiguous aliases, reporting those skips instead of choosing an original value arbitrarily.

An authorized caller can discard the mapping when it is no longer needed. That stored association is then unavailable for later restoration requests.

The July 2026 extension introduced controlled restoration alongside the gateway's detection and text-preparation functions. Its release included synthetic round-trip tests, which replace values and then restore them, and an HTTP check that rejected an incorrect restoration token.

This was a local demonstration using invented data. It shows implemented restoration controls and tested examples; it does not establish that every real-world identifier will be detected. The work described here did not deploy the gateway with real personal data.