A private key is the one thing you cannot half-redact

Of the eight categories PromptScrub detects, private keys are simultaneously the easiest to find and the most damaging to leak. That combination shapes how the rule works.

Easy to find

A PEM block announces itself:

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAtR2Zk8pQmYqEXAMPLEabcdefghijklmnop
qrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcd
-----END RSA PRIVATE KEY-----

Fixed opening line, fixed closing line, base64 in between. There is no ambiguity, no vendor variation to chase, and nothing else in normal text looks remotely like it. One pattern covers every key type: RSA, DSA, EC, OPENSSH, and the generic PRIVATE KEY form.

We ran the block above through the rule. It matched all 163 characters, from the first dash of the header to the last dash of the footer. Not the base64 body alone, not the first line: the entire block.

Why the whole block matters

Matching the body only would leave the header and footer visible. That is enough for a reader to know a key was there and what type it was, and it leaves a partial artifact that looks like it might be usable.

More practically, PEM blocks span multiple lines, and a rule that stops at the first newline catches one line of a fifty-line key. The pattern matches across newlines deliberately, from BEGIN to END, so a whole key becomes a single finding rather than fifty fragments.

Partial masking is disabled for this type

Other categories support a partial mask: emails keep their domain, cards keep the last four digits. Private keys do not, and it is the only type where we override the user's chosen strategy.

The reason is that there is no safe fragment of a private key. Unlike a card number, where the last four digits are printed on every receipt and are conventionally not secret, every part of a key is key material. Showing the first eight characters of the base64 is not a helpful preview; it is a leak of eight characters of the secret and an invitation to assume the rest is safe.

So the key is replaced whole, in every strategy. If you select partial masking for a document that contains a key, you get partial masking on the emails and a fully replaced key.

How keys end up in pasted text

Almost nobody pastes a private key deliberately. They arrive as passengers:

• An SSH client error that prints the offending key file.
• A cat of a config directory pasted wholesale to show a directory listing.
• A Kubernetes secret manifest, where the key sits in the same YAML as the setting you wanted help with.
• A CI log with debug output enabled.
• A Terraform plan that includes a key in the diff.

In every case the person is focused on the error message and the key is thirty lines above it, outside the part they are reading. This is the failure mode automated detection is genuinely good at: you skim, the rule does not.

If you have already pasted one

Rotate it. Not "consider rotating it". Rotate it.

A key that has been transmitted to a third-party service is outside your control regardless of that service's retention policy or intentions. Rotation is usually a few minutes of work and it converts an unknown, unbounded risk into a closed incident. Deciding whether the exposure "probably mattered" costs more time than rotating, and the analysis is not reliable.

That advice has nothing to do with our tool. It is what you do about a key that left your machine, by any route.