Protect data before model delivery

Masking is a setting of the active organization. When enabled, provod.ai checks supported text fields before an external model request, replaces detected values with typed pseudonyms, and reuses the transformed request for every routing attempt. If the model returns a pseudonym created for that request, the API restores the corresponding original value before responding to the client.

No automated detector can guarantee that it finds every sensitive value. Do not send a secret when safety depends only on automatic recognition.

See 152-FZ and data masking for the feature's legal boundaries, operator responsibilities, and provod.ai company details.

Enable protection for an organization

1. Select the intended organization in the workspace menu.
2. Open Settings.
3. Open Data protection and enable masking.
4. Keep only the categories that should be masked enabled.
5. Return to chat or send a request with an API key owned by that organization.

A new organization starts with masking disabled and every supported category preselected. Turning off the final category also disables the master mode. Enabling the master mode again selects every category. Members with workspace-read access can inspect the state and processing log. Changing the mode or categories requires workspace-management permission.

The mode applies to cabinet chat and compatible chat API requests for the organization. Guest chat without an organization is outside this policy.

Data that is inspected

The first version processes message and instruction text, text content parts, tool-call arguments, and textual tool results. Supported categories include people, phone numbers, email addresses, addresses, passports, Russian tax and social-insurance identifiers, bank accounts, payment cards, IP addresses, and secret-like values.

The detector may report a value from a disabled category, but the gateway discards that match before creating a pseudonym and does not include it in audit counts.

Images, audio, video, binary files, and media URLs are passed without content recognition. Document text is covered only after it becomes an ordinary text part of the request; masking is not OCR or file redaction.

Detector failure behavior

Enabled masking is fail-closed. If the detector is unavailable, times out, rejects oversized text, or returns an invalid result, the API returns 503 with code guardrail_unavailable. The original request is not sent to an external provider and no model charge is created.

When masking is off, the detector is not called and the request follows normal processing.

Protected request pricing

A successful request with masking enabled is charged at the selected model price plus a five-percent markup. The preliminary balance reservation includes the same markup. Balance history shows the model and masking charges as separate entries. There is no separate subscription or per-match fee.

If the detector stops the request before provider delivery, neither the model charge nor the markup is captured.

Verify behavior with synthetic data

Use fictional data only, for example:

Contact test.person@example.com from 192.0.2.10 and repeat both values.

Open the protection log after the request. Detected values produce a Masked event with category counts. Text without a supported value produces No match. With the detector stopped, expect Request stopped and no provider delivery.

Data retained in the log

The log contains time, request source, model, status, request identifier, detector duration, provider-attempt state, and aggregate category counts. A normal response uses source Chat; the separate service request that creates the first automatic title for a new conversation uses Chat title. Later messages do not create this request after an automatic or manual title is stored. A model shown for the service request is not the model selected by the user for the response. The log does not retain original or transformed text, detected values, surrounding context, or the pseudonym restoration map.

Records are retained for 90 days. Deleting a user or API key preserves the organization's history while clearing the relation to the deleted object.

Troubleshooting