2 min readBy Rexaris AI
Mask, block or route: choosing the right action for sensitive data
Three actions cover almost every data policy for external LLMs. Picking the wrong one either leaks data or kills adoption.
Every AI data policy ends in a verb. The gateway found a card number, an email address or a block of proprietary code in a prompt. Now what? In practice three actions cover almost everything, and the art is matching the action to the data class and the destination.
Mask: when the model does not need the value
Most prompts that contain personal data do not need it. "Prepare a summary for Ivan Petrov, ivan@bank.com" works just as well as "Prepare a summary for <PERSON_1>, <EMAIL_1>". The model never sees the real values, and the placeholders are restored inside the perimeter when the response comes back.
Masking is the default for PII going to external providers. It keeps the workflow intact and the exposure near zero. The one thing to watch is consistency: the same entity must map to the same placeholder within a conversation, otherwise the model loses track of who is who.
Block: when no form of the data may leave
Credentials are the clearest case. An AWS key, a database password or a private key has no useful masked form, and the mere shape of a leaked secret is a problem. The rule is simple and absolute:
Data class = CREDENTIALS → BLOCK
Payment card data under PCI scope is usually treated the same way for external destinations. Block, log, tell the user why.
Route: when the data is fine, the destination is not
Confidential documents are different. The content is legitimate work; the problem is sending it to a third party. If you run an internal model (Qwen, Llama or anything OpenAI-compatible behind vLLM), the policy becomes:
Data class = CONFIDENTIAL AND Destination = External → ROUTE to Internal LLM
The user asked a question. The policy decided where it could be answered. Nobody had to open a different tool.
A simple decision table
| Data class | External provider | Internal model |
|---|---|---|
| Public | Allow | Allow |
| PII | Mask | Allow |
| Confidential | Route internal | Allow |
| Credentials | Block | Block |
Start with a table like this, make it concrete for your data classes, and turn each row into a rule. Then run it in audit-only mode for a week before enforcing. The surprises will be in the rows you thought were obvious.