Abstract
This document discloses how to govern access to the **re-identification correspondence map** produced when a security gateway reversibly pseudonymises sensitive values before sending a document to a cloud large language model (LLM) and restores them on the response path. The correspondence map — the token-to-value mapping — **is** the data-protection re-identification key (the GDPR Article 4(5) "additional information" that turns pseudonymous tokens back into personal data); it is the most sensitive artefact in the round-trip, and the established round-trip (tokenise on egress, hold an encrypted short-lived mapping, restore on response) does not, by itself, govern *who may reverse it and how*. The disclosed contribution is a binding that treats reverse-mapping retrieval as a distinct, high-impact capability rather than an ordinary read. It comprises: (1) a **single-use capability handle** — an unguessable, high-entropy token, distinct from any request identifier — that is the *only* way to address a correspondence map for reversal, is bound at creation to the authenticated identity entitled to reverse it and to a dedicated *de-tokenisation* authorisation role, is consumed on use, and is **never written to logs, audit records, or traces** (so it cannot leak through the observability surface the way a request-id does); (2) a **role-scoped, step-up-gated reveal** — reversing or downloading a correspondence map requires both the dedicated de-tokenisation role *and* a fresh step-up authentication (e.g. a time-based one-time-password challenge), reusing the same step-up primitive the system uses for other high-impact actions, so a reveal is not merely an authorised read but a re-authenticated, explicitly-elevated action; and (3) **handle-as-authenticated-data** — the capability handle is supplied as the additional-authenticated-data (AAD) input to the authenticated encryption of the map, so that the handle for one map cannot decrypt a different map (the handle and the encryption key are independent, and a stolen handle without the key, or a key applied with the wrong handle-as-AAD, both fail). On the response path, a fourth element binds restoration to position and context — a restored value is only re-inserted where its token actually occurs, within a bounded surrounding-context window, so an attacker who replays a captured token in a different position or a fabricated response cannot induce the gateway to reveal the original value out of context. The surrounding tokenise/restore round-trip and the use of an encrypted, time-limited store are treated as known background; the disclosed contribution is the capability-handle binding (1)–(3) and the position/context-bound restoration (4).
**Keywords:** re-identification key; correspondence map; token-to-value mapping; reversible pseudonymisation; de-tokenisation; capability token; capability handle; single-use token; high-entropy handle; unguessable handle; not-a-request-id; step-up authentication; TOTP reveal; role-scoped access; detokenize RBAC role; authenticated encryption; AES-256-GCM; additional-authenticated-data; handle-as-AAD; key-handle separation; TTL; request-scoped; never-logged secret; position-bound restoration; context-window binding; token replay defence; response-path anti-replay; GDPR Article 4(5); LLM security gateway; cloud LLM privacy.
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 License.
Recommended Citation
Rosado, Tiago, "Single-Use Capability-Handle Binding of a Re-Identification Correspondence Map, with Role-Scoped Step-Up-Gated Reveal and Handle-as-Authenticated-Data, for Reversible Pseudonymisation at an LLM Security Gateway", Technical Disclosure Commons, (June 29, 2026)
https://www.tdcommons.org/dpubs_series/10603