The identity vault

When protection seals a client's name into a stand-in, the mapping between the real value and its replacement has to live somewhere the firm controls. That somewhere is the identity vault. It lives in two places, matched to the two products: on the device for Endpoint Protection, and in a server vault inside the firm's dedicated environment for Proxara Connect.

The two are built differently, and the difference matters to a reviewer. On the device the vault is a standing per-tenant registry of every entity Proxara has sealed. In Connect it is short-lived and scoped to a single piece of work. Neither copy ever leaves the firm's control.

How the mapping works

Each entry pairs an original value with a pseudonymous stand-in and an entity type, so the same value read twice lands as one entity rather than two. The device proxy and the Connect policy engine resolve against the firm's one identity picture, which is what makes a client mentioned in a ChatGPT prompt and the same client in a retrieved email read as one entity in the record.

In Proxara Connect a stand-in looks like [Person_0CE2473EA47B] or [Organization_0599F9C6AF50]: one of ten labels (Person, Organization, Household, Account, Address, Contact, Amount, Project, Identifier, Credential) followed by an opaque suffix. The same client keeps one stand-in throughout a single piece of work, and receives an unrelated stand-in the next time. The compliance record keeps counts and categories rather than the stand-ins themselves.

On the device the token forms are [Person_N], [ID_N], [Org_N] and [Vocab_N], each carrying its entity type: client PII, identifier, proprietary deal, personal contact, or vocabulary violation. Values are normalised before lookup there, so casing and spacing differences still land on the same token.

The Connect server vault

For Proxara Connect there is no device in the path, so the vault runs server-side inside the firm's dedicated environment, encrypted at rest. It is short-lived rather than standing: the mapping for a piece of work lives only as long as that work, expires with it, and resolves only inside it. A client keeps one stand-in throughout a single brief and receives a different one next time.

Mappings are scoped to the firm and to one piece of work. The employee binding comes from that work: a piece of work belongs to one employee, and turning a stand-in back into a real value re-checks the employee's own live connection, their identity, and the exact policy version before anything is revealed. A stand-in copied into an unrelated conversation resolves to nothing.

Real values are restored in one place only: the private Proxara view the employee opens inside the chat. The mapping is resolved inside the firm's environment, for that employee, for that one piece of work, and the clear result is delivered to the employee rather than sent anywhere else. Connect requests read and sign-in permissions only, so there is no outbound action that could receive a restored value. The mapping travels on no channel: not to the model, not into the conversation, not into the record.

How the device vault is protected

On the device, the registry lives encrypted at rest. Each record is sealed with its own random key, wrapped under a root key generated on that device, and lookups are keyed with a tenant secret, so the registry file on its own discloses nothing. Retiring an entity destroys its key material, which makes the stored original unrecoverable even from a copied backup of the file. That is how a right-to-erasure request is honoured cryptographically rather than by best-effort deletion. The copy the console investigates lives in the environment the firm is enrolled in, alongside the rest of the record, where a reveal happens only through the audited console path and the end-of-trial purge overwrites stored originals before deleting the rows.

What the compliance officer can do with it

For Endpoint Protection, the vault page in the console (under Compliance) is the investigation surface:

• Search by token or by original value.
• Reveal a token's original. Every reveal writes a signed row to the audit record, so looking is itself accountable.
• Trace exposure. Each token has a timeline of every interaction where the entity appeared: when, on which AI provider, in what conversation, and whether redaction applied. When the question is "which AI tools have ever seen this client," this page is the answer.
• Retire an entity and its linked tokens, with the erasure recorded.

In Proxara Connect the only reveal is the employee's own private view of their own piece of work, and each opening writes a signed entry to the firm's record.

Why this design

Tokenization without a vault would leave the model's answers unusable, and a vault without stable tokens would leave the firm's records unjoinable. The combination is what lets an employee work normally, a model answer usefully, and an examiner later trace exactly where one client's data travelled, with the mapping held inside the environment the firm is enrolled in.

That tracing is the Endpoint Protection record. The Connect record is deliberately content-free: it keeps counts and categories rather than the stand-ins themselves, so it cannot be used to follow one client from one piece of work to the next. For how tokens are produced in the first place, see Redaction and tokenization.