PromptScrub

What a redaction tool cannot see in your text

PromptScrub currently ships 8 rule groups containing 28 distinct patterns. Seventeen of those patterns exist just to recognise API keys, because every vendor invents its own shape: sk- for OpenAI, ghp_ for GitHub, AKIA for AWS, xox for Slack, glpat- for GitLab, and so on down the list.

That density is worth understanding, because it explains both what this method is good at and where it stops.

What patterns catch reliably

A rule works when the thing it looks for has a shape that is decided by someone other than the writer. An AWS access key ID starts with AKIA and runs exactly twenty characters because Amazon says so. A JWT has three base64url segments separated by dots, the first two starting eyJ, because the specification says so. A PEM private key sits between two lines of dashes with fixed wording.

These are machine formats. Nobody writes them by hand, nobody varies them for style, and a regular expression that describes one is right essentially always. This is where automated redaction earns its place: the tool never gets bored, never skims, and finds the sixth key in a log file as reliably as the first.

What patterns cannot catch, ever

Now consider a sentence from a real message:

Falcon slips to Q3 and we are not telling the board until the numbers firm up.

There is nothing here for a pattern to match. No format, no prefix, no checksum. Every word is ordinary English and the sentence is indistinguishable in shape from "Falcon lands in Q3 and we are thrilled to tell everyone". What makes the first one confidential is not how it is written but what is true about the world: that Falcon is an unreleased product, that the board has not been told, that you are not the person authorised to say so.

No amount of rule-writing reaches this. It is not that the rules are immature; the information a pattern operates on simply does not contain the answer. Anything whose sensitivity comes from context rather than format is outside the method entirely:

Where tools quietly make this worse

The failure mode is not the miss itself. It is what a clean result does to your attention.

A tool that reports "no sensitive data found" has told you something narrow: none of its configured patterns matched. What you hear is closer to "this is safe to send". The gap between those two statements is where the actual leak happens, and the more reliable the tool is on machine formats, the more it earns the trust that makes the gap dangerous.

This is why the summary line in PromptScrub says "nothing sensitive found by the enabled rules" rather than "your text is safe", and why the checklist below sits on the home page instead of in a help article. The wording is deliberate. A tool that oversells its own certainty is worse than no tool.

The five-point check

After scrubbing, before sending, read your text once more looking for meaning rather than format:

  1. Real names of clients, colleagues, or candidates.
  2. Unreleased numbers such as revenue, growth, headcount, or pricing.
  3. Project code names your company treats as confidential.
  4. Anything under NDA: contracts, negotiations, legal matters.
  5. Other people's private details they did not agree to share.

It takes about fifteen seconds on a typical message. If that sounds like a lot of effort for something a tool was supposed to handle, that is the honest shape of the problem: the part a machine does well takes no effort at all, and the part left over is exactly the part that needs a person.

Use both, for what each is good for

The division of labour is clean. Let the rules handle the mechanical formats, where they are close to perfect and you are unreliable, especially in a long file at the end of a long day. Handle the meaning yourself, because you are the only one who can.

A tool that claimed to do both would be lying about the second.