Shield

Veritas document hardening

Veritas hardens documents; it does not sanitize their data. Veritas cleans documents of hidden code and markings — hidden Unicode, container metadata, active content, and possible watermark signals. To sanitize a document — detect sensitive data such as names, emails, or credentials and replace it with protected tokens before the document reaches an AI provider — use the Shield sanitizer flows below (Rotate, Proxy, Gateway) or see PII Sanitization.

When your package includes Shield Veritas, open Shield → Veritas to process pasted text or up to 20 TXT, DOCX, and PDF documents in one job. Veritas removes hidden Unicode and container metadata deterministically, records a finding manifest, and makes the hardened baseline available for download. PDF output is reconstructed from extractable text; image-only PDFs are refused rather than described as inspected.

Optional safe polishing automatically applies your company’s effective Shield sanitization profile before provider egress. The provider sees only protected realistic surrogates/tokens. Veritas tests the selected model, validates every protected occurrence and its position, retries another eligible model when validation fails, restores sensitive values locally, and presents each wording change for approval or rejection. Approved documents can be downloaded individually or together with a JSON report in a ZIP. Jobs expire after the configured retention period and can be purged earlier.

For documents of at least 150 words, Elastic rewrite with expert-language protection is enabled by default. Veritas first identifies strict subject-matter terminology and standard expert statements such as definitions, legal clauses, medical instructions, citations, formulae, and number-bound findings. Each sentence is protected, rewritten, rewritten with enhanced validation, or retained for human review according to its materiality, terminology, logical anchors, and dependencies. The model returns multiple sentence candidates rather than a complete document; Veritas rejects unsafe candidates, retains the original when none passes, and assembles accepted patches locally. The review screen and JSON report show content-free protection counts. This mitigates possible statistical watermark signals but does not claim to locate secret-key watermark positions or prove their absence.

For bulk jobs, Short-document accelerator can skip the optional external AI polish separately for each document below a configurable word threshold (150 words by default). Deterministic Unicode, steganography, active-content, and metadata cleaning still runs, and the document receives an explicit coverage finding and audit record stating that no provider was contacted. The option is off by default: statistical text-watermark detectability depends on the scheme, entropy, and token count, so a short document must not be described as inherently unwatermarked.

Shield is VeriPrompt's standalone data-sanitization workflow for users who want to work with AI systems without exposing raw sensitive data.

It packages the sanitizer into three user-facing flows:

Mode	What it does	Best for
Shield Rotate	Sanitize a file or pasted text, use the sanitized version outside VeriPrompt, then restore the result later	Manual workflows with external AI tools
Shield Proxy	Sanitize, send to a provider with your own API key, then restore automatically	Faster BYOK workflows
Shield Gateway	Sanitize, route through the VeriPrompt gateway, then restore automatically	Managed, policy-driven execution

Core promise

Shield is designed for a simple use case:

1. keep regulated or client-sensitive data out of the model input
2. preserve enough structure for the AI to still produce useful output
3. restore original values after the AI step when appropriate

Coverage & limitations

Shield can only detect and protect sensitive data in readable text. It analyzes the text layer of your attachment — it never sees pixels or image content. As a result:

• Images (PNG, JPG, screenshots, photos) are not analyzed. Any personal or confidential information visible in the picture is not detected and may reach the AI provider unprotected.
• Scanned or non-OCR PDFs — PDFs that are really just images of pages, with no embedded text layer — yield no extractable text, so they are not analyzed either.

To have Shield protect an attachment, it must contain a readable text layer (for example, an OCR-processed PDF, or a native digital document). If you only have a scanned document, run it through OCR first so the text becomes machine-readable.

Unreadable attachment policy

Administrators choose what happens when an attachment cannot be analyzed, in Shield → Settings → Unreadable attachment policy:

Policy	Behavior
Warn only	The attachment is processed and a coverage warning is attached. The send is never held.
Require acknowledgement (default)	The send is held until you acknowledge that the attachment is sent unprotected.
Block	Unreadable attachments are never allowed through. There is no override.

The company-wide default can be overridden per scope on a Data Protection Profile (Company → Project → User). In chat, the policy surfaces as a warning banner with a Send anyway option (when acknowledgement is allowed). On the external Shield API there is no interactive prompt: Warn only returns the warning in the response and the X-Shield-Coverage-Warning header; Require acknowledgement returns 422 unless you pass acknowledge_unprotected_attachments: true; Block always returns 422.

How Shield works

Original file/text
  -> detect sensitive values
  -> replace with surrogate tokens
  -> wrap provider-bound replacements in nonce-scoped protected references
  -> qualify the selected model using the safe manifest
  -> run AI workflow on sanitized content
  -> strictly restore only exact protected references in the result

Examples of surrogate tokens:

• [PERSON_1]
• [EMAIL_ADDRESS_2]
• [PHONE_NUMBER_1]

Tokens or realistic surrogates

Shield can render masked values two ways before they reach the AI: as opaque placeholder tokens ([PERSON_1]) or as realistic surrogates — natural-looking, type-faithful fakes such as Nora Wren_1 or iris.dale@example.org_1. Realistic surrogates read like ordinary text, so the model produces higher-quality output, and Shield still restores the real values in the response. Set the default in Shield → Settings → Replacement style, with per-category and per-prompt overrides. See Replacement style: tokens vs realistic surrogates for the full comparison and a before/after example.

For provider transport, Shield surrounds these safe replacements with nonce-scoped references. An AI answer may omit any protected value. When it does refer to one, Shield restores it only if the complete reference is preserved exactly; ordinary phrases, bare shifted dates, and approximate token variants never trigger restoration. Shield Proxy and Shield Gateway first run an exact-copy qualification and then replay it with the task in the same provider session. Shield Rotate's Copy for AI and download actions create a self-contained provider_handoff containing the preservation rule, finite safe-value manifest, and protected document. The readable preview is never used by those actions. Direct sidecar API integrations should send protected_document together with protection_manifest and use strict restoration.

If a user manually adds or removes a redaction, Shield invalidates the occurrence-bound handoff instead of guessing new reference positions. The document must be sanitized again before it is sent externally.

Case IDs

Every Shield run creates a case ID such as sh_3kX9mPqR7wLn.

Use a case ID to:

• reopen the case within its retention window
• download the sanitized version again when still available
• submit an AI response for restore
• review basic case metadata such as timestamps and status

Data handling

Shield uses two storage layers with different purposes:

• Shield case metadata: case ID, timestamps, status, document type, and usage counters
• Sanitizer session data: encrypted token mappings, encrypted sanitized document, and a per-session encryption key

What is not stored

• Original source documents are not persisted as raw documents by Shield
• BYOK provider keys are passed through for execution and are not stored as Shield case content
• Restored AI responses are returned to the user rather than retained as case payloads by default

Expiry vs purge

These are different events and should not be confused.

Event	Meaning
Case expired	The restore window has ended. Restore is no longer guaranteed.
Session purged	Sensitive session data has been explicitly deleted.

Expiry

Shield cases have a TTL. After that window:

• the case may still exist as metadata
• restore should be treated as unavailable
• the underlying sanitizer session may already be gone or may be cleaned up shortly after by backend retention jobs

Explicit purge

When a case is explicitly purged, Shield removes or breaks access to the sensitive session layer:

• encrypted token mappings are deleted
• the encrypted sanitized document is deleted
• the per-session encryption key is deleted
• only minimal case metadata is retained for audit and billing purposes

Explicit purge is irreversible.

Choosing the right Shield mode

Use Shield Rotate when you want the clearest privacy story and are comfortable with a manual handoff.

Use Shield Proxy when you already manage provider keys and want the convenience of sanitize-run-restore in one step.

Use Shield Gateway when you want VeriPrompt routing, policy enforcement, and managed execution on top of the Shield workflow.

Use Protected Handoff when your company works in a vendor chat (Claude, ChatGPT, Gemini, Copilot): drag the protected files into the chat and paste the answer back, with no case ID.

Related docs

• Protected Handoff
• PII Sanitization
• BYOK (Bring Your Own Key)
• AI Gateway
• PII Sanitization API
• Watermark Avoidance