Redact secrets before you paste
To redact a secret is to replace a credential in text — an API key, token, password or private key — with a marker before the text is shared, so the information travels without the access. It matters because the most common way secrets leak is not an attack but a paste: a log into a support ticket, a configuration file into a chat, a debug command into a forum post. This article explains why those pastes are so hard to undo, what a scanner such as the Secret Redactor can and cannot catch, and the workflow — redact locally, share the redacted copy, rotate anything that already escaped — that keeps a helpful paste from becoming an incident.
Why secrets end up in tickets, chats and logs
Nobody pastes a secret on purpose. They paste the thing around the secret: the error log that happens to include the request headers, the configuration file that happens to hold the database password three sections down, the curl command copied from a terminal where the token is sitting in an Authorization header. Troubleshooting runs on context, and credentials live inside the context — which is why support desks, chat channels and issue trackers quietly accumulate live keys, session tokens and private keys, written by careful people in a hurry who were looking at the error message, not at the header above it.
The receiving system then makes the paste permanent in ways the sender never sees. Tickets are indexed for search, forwarded to vendors, exported to reports and kept for years; chat messages are pushed to phones as notifications, quoted in threads and summarised by bots; logs are shipped to aggregators with their own retention and their own access lists. A secret in one of these systems is not in one place — it is in every copy, backup, preview and notification the system generated, most of which the sender cannot enumerate, let alone delete. That asymmetry — one second to paste, no reliable way to recall — is the whole reason redaction has to happen before the paste, on the sender's machine, and not as a cleanup afterwards.
What a scanner can catch: shapes, checksums and structure
The good news is that real credentials are highly patterned, and pattern scanning is deterministic: the same text always produces the same findings, with no model guessing in between. Provider keys carry published shapes — prefixes, fixed lengths, restricted alphabets — so an AWS access key, a GitHub token, a Stripe key or a Slack token can be recognised on sight, the way a person recognises a phone number in a paragraph. Private keys announce themselves with their BEGIN and END armour lines, and JSON Web Tokens have a rigid three-segment structure whose first two segments always begin the same way, because they always encode the same kind of JSON.
Two checks keep the pattern layer honest. Card numbers are only flagged when they pass the Luhn checksum, a arithmetic test built into every genuine card number, which separates real cards from the far larger population of long numbers — orders, invoices, timestamps — that merely resemble them. And when shapes overlap, specific patterns beat generic ones, so a known provider key assigned to a variable is reported once, under its real type, with the right rotation instructions attached. GitHub's own secret scanning, the first source below, works on the same principle at platform scale: partners publish their token formats, and the platform matches them exactly. A local scanner is the same idea, run at the last moment where it can still help — your browser, before you press send.
What a scanner cannot catch: entropy and context
Beyond provider shapes, detection gets probabilistic. A generic rule can look for assignments — a name like password or api_key next to a value — and can demand that the value look random, measured by Shannon entropy. That catches a generated key assigned to a variable and ignores the word password in a sentence, but the boundary is a judgement call wearing a number's clothes: a strong human password and a weak machine key live on the same scale, a real secret spelled as a phrase scores low, and a random-looking build hash with no placeholder wording scores high. Entropy tells you a string is surprising; it cannot tell you the string is a credential.
Context is the larger blind spot, because most of what makes a value dangerous is outside the value. A session cookie is just letters and digits until you know the service it unlocks. A database password is harmless-looking inside a connection string split across three environment variables, and a one-time code is only sensitive for ten minutes. Scanners also cannot see across structure: a secret wrapped over two log lines, base64-encoded inside a blob, or screenshotted into an image is invisible to text patterns, however good they are. The honest summary is that a scanner reliably catches the documented, well-shaped majority — and that the preview it shows you, with hits highlighted in place, still deserves your own ten-second skim, because your eyes know the context the patterns cannot.
There is one more class the scanner is deliberately blind to, and it is next door to a trap: placeholders. Documentation values — containing words like example, test, dummy or your- — are excluded so that manuals and tutorials do not light up the findings table. Every exclusion, though, is a door: a real key that happens to contain one of those words, or a lazy real password set to a placeholder-looking value, passes silently. Treat the exclusion list as a noise control, never as a guarantee, and never mark a real credential with placeholder wording to keep a scanner quiet.
The canonical fake-example problem
Every provider publishes example credentials, and the most famous — the AWS documentation pair built around AKIAIOSFODNN7EXAMPLE — is shaped exactly like a real key, because an example that did not look real would teach nothing. Scanners therefore face a fork with no good default. Flag the canonical examples and every tutorial, textbook and training log becomes a false alarm, teaching readers to dismiss findings reflexively — alarm fatigue is a vulnerability in its own right. Whitelist them, and you have published a list of strings no scanner will ever report, which is an invitation to anyone who wants a hiding place: a real key cannot equal the example, but a note, filename or wrapper around a real key can borrow the example's camouflage.
The practical answer is the one the Secret Redactor takes: flag the shape, and let the findings table start the conversation. The canonical example contains the word example inside the key itself, yet it is flagged as an AWS key, because a provider-shaped string deserves a human glance every time — the glance is cheap, and the alternative is a silent pass for anything shaped the same way. When you write documentation, help your readers' scanners as well as your own: use obviously synthetic values, mark them with placeholder wording in the surrounding assignment, and never paste a real key into a document and edit a few characters — a partially edited real key is still a credential leak with extra steps, and scanners cannot tell it apart from the genuine article either.
Rotate, do not just delete — and share safely
If a real secret has already been pasted unredacted, the order of operations matters and deletion comes last, if at all. Assume the value has been copied — by an index, a notification, a screenshot, a colleague's quote — and treat it as public: go to the provider first and rotate the credential, revoking the old one, so the leaked string stops working no matter where it survives. Only then delete or edit the original message, as hygiene rather than as the fix. The OWASP secrets-management guidance and the gitleaks project, both listed below, exist for the two halves of this lesson: managing secrets so they are short-lived and scoped, and scanning repositories and histories on the assumption that pastes have already happened. The companion problem for browser captures is worked through in before you send that HAR file.
The safe sharing workflow is short enough to become a habit. First, redact locally, in a tool that never uploads the original — the scan belongs on your device, because sending raw text to a remote redactor would repeat the leak in the act of preventing it. Second, share the redacted copy in the ticket or chat, where it carries everything a troubleshooter needs — endpoints, timings, error shapes — except access. Third, when the other side genuinely needs the credential itself, send it through a secrets manager or an expiring, single-view share link, in a separate channel from the discussion, and say so in the ticket so nobody pastes it back. Teams that adopt those three steps stop depending on vigilance, which is the one control that always fails eventually, and start depending on a routine — and routines are what keep secrets out of tickets on the tired Friday paste as reliably as on the careful Monday one.