Skip to main content

Request masking

Request masking is finding and hiding sensitive data in requests before sending them to the model.

The service recognizes basic data types, such as email, phone number, passport number. You can select the required types and configure recognition of custom data types.

Recognition is based on regular expressions. Text values in POST requests to the following endpoints are checked:

  • /chat/completions — message text, text parts of multimodal content, function arguments, and the prediction field;
  • /images/generations — text in the prompt field.

Masking can be used in one of two modes — data replacement or request blocking.

We do not recommend using masking as the only data protection mechanism. Restrict access to API keys and do not transmit sensitive information unnecessarily.

To use masking, enable it. Masking is enabled separately for each AI router.

Recognized data types

The service includes rules for recognizing the following data types:

  • email addresses;
  • Russian and international phone numbers;
  • bank card numbers with Luhn algorithm checksum verification;
  • SNILS with checksum verification;
  • 10- or 12-digit INN with checksum verification;
  • Russian passport series and number;
  • AI Router API keys.

You can also configure recognition of custom data types. To do this, create a regular expression to recognize the required data and specify it in the ticket when enabling masking.

Masking modes

Masking works in one of two modes:

  • data replacement — detected data is replaced with placeholder tokens. Suitable for working with data that may contain sensitive information;
  • request blocking — the request is blocked upon the first detected occurrence. Suitable for working with data that must not contain sensitive data even before being sent to the model.

Data replacement

Detected sensitive data in the request is replaced with placeholder tokens like [ЗАМЕНЕНО:<тип_данных>]. The model receives the request with replaced data.

If different occurrences of the same data type are encountered, they receive sequential numbers, for example, [ЗАМЕНЕНО:email_1] and [ЗАМЕНЕНО:email_2]. For numeric values, separation by hyphens and spaces is ignored.

note

For example, the request "Write to ivan@example.com, cc: manager@example.com. Reply to ivan@example.com." will be processed and sent to the model as "Write to [ЗАМЕНЕНО:email_1], cc: [ЗАМЕНЕНО:email_2]. Reply to [ЗАМЕНЕНО:email_1]".

When replacing data, the API response will not contain additional data or headers. Modifying the handling of successful responses is not required.

Request blocking

Upon the first detected occurrence, the entire request is rejected. The AI router returns a guardrail_rejected error with HTTP code 422 in JSON format and does not send the request to the model. If the request is streaming, the error is returned before the SSE stream starts.

The response returns the request ID in the x-gateway-request-id header. Save it in application logs for diagnostics.

When processing the response, check the error.code field. Do not retry a request with the guardrail_rejected code automatically without modifying the content.

Errors

If the AI router failed to apply rules and the request cannot be sent without verification, the client receives an error with HTTP code 500:

{
  "error": {
    "type": "server_error",
    "code": "internal_error",
    "message": "Guardrails could not be applied to this request",
    "request_id": "sel-aig-<request_id>"
  }
}

Where <request_id> is the request ID.

For an error with code 500, configure a limited number of retries with increasing backoff after each error. If the error persists, submit a ticket and specify the request ID in it.

Limitations

Verification does not guarantee detection of all personal or sensitive data.

Since verification is based on regular expressions, the value will remain unchanged if it is:

  • split across multiple fields or parts of the message;
  • encoded;
  • transliterated;
  • written in words instead of digits;
  • located inside an image or file.

False positives are possible. For example, the Russian passport recognition rule may recognize another 10-digit identifier as a passport.

Enable request masking

  1. If you want to use masking in the request blocking mode, make sure that your client handles the guardrail_rejected error with HTTP code 422 and the Content-Type: application/json header, including for requests with stream: true.

  2. Submit a ticket to enable masking. In the ticket, specify:

    • AI router ID, you can copy it in the control panel: in the top menu, click Products → AI router → on the AI router card under its name, click ;
    • masking mode — data replacement or request blocking;
    • data types to be masked;
    • if you need to configure recognition of a custom data type — the regular expression to search for this data type;
    • if data replacement mode is selected — the desired placeholder name.