Sensitive data protection

Every core SDK reads the organization’s sensitive data policy from the authenticated application profile and applies it inside each governed action. When the policy is enabled, the SDK masks the action input before policy evaluation, before the protected action receives it, and before any content is captured. It masks application facts the same way, and it masks the output before capturing it as evidence. The value returned to your code is the action’s own result.

Put the provider call inside the governed action and the provider receives the masked input. For calls your application makes outside a governed action, use the sanitizer directly.

This is pattern-based protection, not comprehensive PHI removal. Names, street addresses, images, audio, arbitrary documents, and unsupported provider request types remain outside the guarantee. Unlabelled identifiers require a configured sensitive field name.

Supported text patterns

Email addresses and North American phone numbers
US Social Security numbers and Canadian Social Insurance Numbers with valid check digits
Payment card numbers and IBANs with valid check digits
IPv4 addresses
Common API key and bearer-token formats
Labelled Canadian health and financial identifiers
Complete string values under built-in or customer-configured sensitive field names
Customer exact-match rules and the documented portable regular-expression subset

The sanitizer walks every string in the value, including nested objects, arrays, and JSON tool arguments. It fails closed when the value exceeds 1 MB, exceeds 32 levels of nesting, the policy has expired, or a rule cannot be compiled. A governed action then returns failed with reason code sensitive_data_policy_invalid and the protected action does not run.

Postal codes are intentionally not masked by a broad pattern. They are weak identifiers and formats such as ZIP+4 can resemble an SSN. Add the exact containing field name only when your policy requires that whole value to be masked.

Configure the policy in the portal

Open Settings → Sensitive data overrides. Choose the patterns to mask, the replacement style, and any application field names whose whole value must be masked.

Replacement style	Result
Entity label	`[EMAIL REDACTED]`, `[CARD REDACTED]`, or the label from a custom rule
Same-length stars	One `*` for each character of the matched value
Erase	The matched value is removed

For Canadian healthcare and financial applications, select Use Canadian identifiers, then add application field names such as medicalRecordNumber, healthCardNumber, transitNumber, or bankAccountNumber. Field names are matched without regard to case or common separators. Values are never sent to VeriProof for detection; the SDK downloads the policy and matches locally.

Use the sanitizer directly

Each core SDK exposes the same sanitizer it uses inside a governed action. Build it from the authenticated governance profile so it follows the saved policy and its expiry.

TypeScript


import { sanitizerFromProfile } from '@veriproof/sdk-core/advanced';
 
const sanitizer = sanitizerFromProfile(await veriproof.governanceProfile());
const request = sanitizer ? sanitizer.sanitize(draft).value : draft;
await provider.send(request);

sanitizerFromProfile returns undefined when the policy is disabled. SensitiveDataSanitizer is also exported for tests that supply their own options.

Python


from veriproof_sdk.advanced import SensitiveDataSanitizer
 
profile = await vp.governance_profile()
sanitizer = SensitiveDataSanitizer(profile["sdkDefaults"]["redaction"])
result = sanitizer.sanitize(draft)
await provider.send(result.value)

.NET


using Veriproof.Sdk.Core.Advanced;
 
var profile = await veriproof.GovernanceProfileAsync(cancellationToken);
var sanitizer = new SensitiveDataSanitizer(
    profile.GetProperty("sdkDefaults").GetProperty("redaction"));
var result = sanitizer.Sanitize(draft);
await provider.SendAsync(result.Value, cancellationToken);

Java


import com.veriproof.sdk.processing.SensitiveDataSanitizer;
 
var sanitizer = SensitiveDataSanitizer.fromProfile(veriproof.governanceProfile());
var result = sanitizer.sanitize(draft);
provider.send(result.value());

Go


import "veriproof.app/sdk/go/pii"
 
sanitizer, err := pii.FromProfile(profileJSON)
if err != nil {
    return err
}
result, err := sanitizer.Sanitize(draft)
if err != nil {
    return err
}
return provider.Send(ctx, result.Value)

pii.FromProfile accepts the authenticated governance profile as JSON. The Go client applies the same sanitizer inside veriproof.Govern, which is the recommended path for application code.

The result contains the masked value, match counts by pattern or field name, and the policy version. It never contains the original matches. In Rust the sanitizer runs inside govern and has no separate entry point; keep the provider call inside the governed action.

Understand protection status

Status	Meaning
Automatic protection verified	A supported adapter owns the outbound model-call boundary and is configured with a sanitizer.
Manual sanitizer available	The core API is available, but the application owns the provider call.
Protection not verified	A saved policy exists without runtime proof that requests pass through a sanitizer.

Installing an adapter or saving a policy alone does not make an application protected. Put the provider call inside a governed action, then test a synthetic sentinel against a fake provider and assert that the raw value never reaches the dispatched request.

Run a local dry run


.\vdev.ps1 sanitize -Policy current -Input prompt.json

The command prints only the policy version, counts, duration, and success or failure. It does not send or print raw or masked prompt content. Set VERIPROOF_ENDPOINT, VERIPROOF_APPLICATION_ID, and VERIPROOF_API_KEY first. The command downloads only the current governance policy; prompt content stays on the local machine.