PII detection

Turn this on and qRaptor scans both the prompt going to the model and the reply coming back, looking for personal data. What it does when it finds some is up to you.

Turning it on

In the policy wizard’s Content Policy step, switch on Enable PII Detection. Two controls appear beneath it.

Choosing an action

PII Action decides what happens when personal data is found:

Action	Effect
Redact	The value is replaced before the request continues — `sarah@example.com` becomes `[EMAIL_REDACTED]`. The agent still answers; the model never sees the original.
Block	The request is refused and the user gets a message saying so.
Warn	The request proceeds unchanged; the detection is recorded.
Log Only	The request proceeds unchanged; the detection is recorded quietly.

⚠️

Warn and Log Only do not redact anything. They record that personal data was present and let it through to the provider. Choose Redact if the point is to keep the data from leaving.

Choosing types

PII Types to Detect lists what can be found:

Type	Notes
Email Address
Phone Number	US and international formats
Social Security Number
Credit Card
PAN Card	Indian permanent account number
Aadhaar	Indian national ID
IP Address
Medical Record Number
Bank Account	Opt-in — see below

Select All picks everything except Bank Account. Clear empties the list — and as the hint under the picker says, leaving it empty detects every supported type except Bank Account. An empty selection is not “detect nothing”; it’s the default set.

💡

Selecting specific types is worth doing when you know your data. An agent that legitimately handles order numbers will be happier with Email and Phone selected than with everything on.

Bank Account is deliberately opt-in

Bank Account matches any run of 9 to 18 digits. That also matches order numbers, timestamps, primary keys and plenty of other legitimate content, so it’s excluded from Select All and only applies if you tick it explicitly.

What detection can and can’t do

Detection is pattern-based. That works well for anything with structure — an email address, a credit card number, an IP — and less well for anything without.

ℹ️

Names, postal addresses and dates of birth are not offered. There is no reliable pattern for them, and a detector that guessed would either miss most of them or redact ordinary words. If your agent must not receive names, keep them out of the prompt rather than relying on detection.

Numeric types are blunt by nature. A bare nine-digit number could be a Social Security Number, a phone number or an Aadhaar. Expect some over-matching on number-heavy content, and test with realistic data before you rely on it.

Where it applies

On the way in

The new message a user just typed is scanned first. With Block, this is where the request is refused.

On conversation history

Earlier turns replayed as context are scanned too, but they’re filtered rather than refused — the offending text is removed and the conversation carries on. Without this, one message containing personal data would break every later turn in the same conversation.

On the way out

The model’s reply is scanned with the same rules, including replies that stream in token by token.

Common issues

PII isn’t being redacted — check the action. Warn and Log Only are pass-through by design.
A name or address came through — expected. There’s no detector for those; see above.
Legitimate numbers are being redacted — Bank Account is probably on. Turn it off, or select only the types you need.
Nothing is happening at all — the policy may not be attached, published or saved. See Troubleshooting.

Blocked content — refusing requests on specific words or patterns.