How the PiiBlocker Allowlist Stops False Positives

The Allowlist is a list of words and phrases that PiiBlocker leaves alone, even when a detector would normally flag them. It exists for terms that look like personal data and are not: your organisation's name, a ward or department, a software product, a drug brand. Entries match the whole term exactly, so adding "Raman Ward" does not stop "Raman" on its own from being masked. That exactness is also where the one real risk sits. This guide covers when to use it, how matching works, and what to try instead. Short version: the Allowlist entry on our support page.

Why false positives happen

PiiBlocker finds names with a named-entity model that runs in your browser, and finds structured data such as card numbers and email addresses with pattern checks. Names are the hard part. A name detector works from context and shape, and plenty of ordinary terms have the shape of a name. Hospital wards are named after people. So are law firms, university buildings, software products and medicines. To a detector, "Raman Ward is full" and "Raman is unwell" look alike.

When that happens you get a false positive. The extension highlights the term, asks you about it, and swaps it for a placeholder that tells the AI nothing useful. One false alarm is a small cost. The same false alarm in every prompt, every day, teaches people to click through the dialog without reading it, and that habit is a bigger risk than the original noise. The Allowlist is there to remove the repeat offenders.

How Allowlist matching works

Entries match the whole term exactly. If you add "Raman Ward", PiiBlocker stops flagging "Raman Ward". It still flags "Raman" when the word appears alone, and it still flags "Raman Patel", because neither of those is the term you listed.

This is deliberate. A looser match would be more convenient and much less safe, since a short entry would quietly switch off protection for every longer phrase that contains it. Exact matching means each entry does one narrow job, and you can read down your list and know what it lets through.

Two practical consequences follow. First, add the term the way it appears in your prompts, including the second word that makes it specific: "Raman Ward", "Harrison Wing", "Marlow and Finch". Second, if a term shows up in several forms, add each form as its own entry. Several precise entries are safer than one broad one, and they are easier to review later.

What to add, and what to leave off

Good Allowlist entries have two things in common. They come up often, and they could never be a person you are writing about. Typical examples:

• Your organisation's name and the names of its sites
• Wards, departments, teams and buildings named after people
• Software products, suppliers and drug brands that read like surnames
• A standing phrase from your email signature that keeps getting flagged

Leave off anything that might also be a real person in a future prompt. A first name, a common surname, or a short word that doubles as one are all poor candidates, however annoying the false alarms are. The test is simple. Imagine the entry appearing in a message about a client, a patient or a colleague. If it could be their name, it does not belong on the list. For those cases, make the decision in the dialog each time. It costs a click and keeps the protection.

The single-name risk

The Allowlist has one failure mode worth stating plainly. If you allowlist "Raman" because it is a ward, a patient called Raman will also pass through unmasked. The extension cannot tell the two apart, because you have told it not to look.

This matters most in the places where PiiBlocker is used most: clinics, law firms, HR teams and anyone handling client records. There, the same word often is both a place and a person, sometimes in the same week.

Three habits keep the risk small. Prefer two-word entries to one-word entries, so "Raman Ward" goes on the list and "Raman" does not. Review the list every few months and remove entries for projects, wards or products you no longer deal with. And when a single name keeps causing false alarms, accept the extra click. A false positive wastes a moment. A false negative sends a real name to a third party, and it cannot be recalled.

Alternatives to the Allowlist

The Allowlist is the narrowest fix, which is why it is usually the right one. The other options, ordered by how much protection they give up:

Decide in the dialog. For names and other soft items, PiiBlocker shows what it found before sending and you choose what gets masked. There is nothing to set up and nothing is switched off.

Turn a category off. Detection settings can stop a whole category. That ends every false alarm of that type and every true detection with it. It suits a category you never handle, and it is a blunt tool for a handful of noisy terms.

Use a dictionary-only tool. Extensions such as Privacy Protector for ChatGPT mask only the words you list, so there are no false positives to manage. The trade is that they catch nothing you did not think of in advance. Our comparison of masking extensions covers the differences.

Rewording the prompt also works, once.

Frequently asked questions

Does an Allowlist entry stop part of a name being masked? No. Entries match the whole term exactly. Adding "Raman Ward" does not stop "Raman" on its own from being masked.

Is it safe to allowlist a first name? Usually not. If you allowlist "Raman" because it is a ward, a patient called Raman will also pass through unmasked. Add the two-word form, "Raman Ward", and leave the single name off the list.

What is the difference between the Allowlist and turning a category off? The Allowlist exempts only the terms you list and leaves the detector running for everything else. Turning a category off in Detection settings stops all detection of that type, so that data goes through unmasked.

Where is the Allowlist stored? In the free version, in your browser with your other PiiBlocker settings. The free version makes no network calls, so the list is not sent anywhere.