Proxaradocs
Guides/Shared platform

Redaction and tokenization

How sensitive data is sealed before it reaches a model, on the device and in the connector.

Updated June 2026

Redaction is what happens in the gap between an employee pressing enter and a prompt reaching the model. Proxara reads the prompt in context, seals sensitive values into reversible tokens, sends the sealed version onward, and restores the real values in the reply. The employee works normally, and the model sees tokens in place of the values that were caught.

New chat
Today
Quarterly review draft
Holdings summary email
Meeting prep notes
ChatGPT
Draft a quarterly review for Sarah Chen, account 4482-9917, ahead of Thursday's call.
Message ChatGPT
Outbound · chatgpt.comclient_pii · identifier
Draft a quarterly review for [Person_1], account [ID_1], ahead of Thursday's call.
Sealed before it leaves
The seal and the restore, watched live

The path a prompt takes

  1. The device proxy intercepts the outbound prompt (see The device proxy).
  2. A classifier running on AWS Bedrock, inside the environment the firm is enrolled in and never a third-party SaaS, reads the text and any attached files in context and marks the sensitive spans. Long content is split into overlapping windows so length alone does not defeat detection.
  3. Each marked value is swapped for a stable token: [Person_1], [ID_2], [Org_1], [Vocab_1]. Tokens come from the firm's identity registry, so the same client resolves to the same token in every conversation, on every surface, which keeps the model's answers coherent and the firm's records joinable. The identity vault guide covers where the mapping lives.
  1. The sealed prompt goes to the provider. The reply comes back with tokens in it, and the proxy restores the originals before the employee sees it.

The entity families detected are client PII, account and government identifiers, proprietary deal information, and firm-vocabulary violations.

Files

Attachments go through the same sealing before upload. In-place redaction ships for DOCX, XLSX, and PPTX (including headers, footers, notes, and text split across formatting runs), PDF (text removed at the operator level, with escalation to rasterise-and-box when text removal leaves residue), images (detected text covered with opaque boxes, metadata dropped), and the plain-text formats (TXT, CSV, JSON, XML). Every file's record carries a hash of the original bytes and a hash of what was actually sent, so the firm can prove which version left the device.

Best effort, with a coverage record

The honest posture: redaction is best effort, and the system records its own coverage rather than promising perfection. Every redaction event records what was detected, what was sealed, and, for files, a per-file status with the reason when coverage was partial (a scanned image-only PDF, an unsupported format). Anything the system could not fully seal is forwarded with a quiet, inspectable note on the record rather than blocked, because blocking an employee mid-task is a worse failure than a documented gap. A firm that prefers strict blocking for oversized or unredactable content can turn fail-open off.

q3-client-review.docx14 entitiesRedacted
holdings-summary.pdfrasterised p.3Redacted
statement-scan.pngimage_redaction_unavailablePartial
The per-file coverage record

The one moment an employee sees anything

Routine redaction is invisible. The only employee-facing surface is a confirmation prompt on genuinely high-risk sends, for example a bulk paste dense with government identifiers, and it is written to inform rather than scold. Below that threshold, sealing happens silently and the prompt flows on.