🔒 Sanitizing a Postmortem for Public or Cross-Customer Sharing With AI

A colleague nearly published a public postmortem with an internal hostname, a Slack username, and the name of the specific customer whose traffic pattern triggered the bug—all sitting in a code snippet he’d copied verbatim from the incident channel. He caught the hostname. He missed the customer name, buried in a log line three pages down. Legal caught it twelve minutes before publish. That’s the thing about sanitizing a postmortem: the dangerous stuff isn’t in the obvious places, it’s in the pasted snippets and the offhand log lines, and a human re-reading their own document goes blind to it.

Sharing postmortems externally—public status-page write-ups, or a sanitized version shared with one customer that can’t leak another’s identity—is genuinely valuable. It builds trust and it teaches the wider community. But the failure mode is leaking a secret, a customer identity, or an internal detail an attacker can use. This is a tedious, high-stakes scanning task where humans are unreliable and AI is genuinely good, as a first pass.

What actually needs to come out

Before you reach for a tool, know your categories. Sanitizing isn’t just find-and-replace on names.

Identities. Customer names, individual employee names, account IDs, email addresses. For cross-customer sharing, any mention of a customer other than the recipient is a breach.

Infrastructure detail. Internal hostnames, IP ranges, region/AZ specifics, service names that map to your topology, queue names, database identifiers. Individually harmless; collectively a recon map.

Secrets and tokens. API keys, connection strings, anything that looks like a credential pasted into a log. These should never have been in the doc, but they get copied in from incident channels constantly.

Sensitive specifics. Exact request volumes that reveal business scale, security-relevant details about how a control failed, or anything that makes the next exploit easier.

What to keep. The lesson. The timeline shape. The detection gap. The fix. Sanitizing should remove identifying detail while preserving everything that makes the postmortem worth reading. Over-sanitize and you publish mush.

A prompt that flags, but doesn’t silently delete

The mistake people make is asking AI to “remove all sensitive info,” which produces a quietly redacted document you can’t audit—you don’t know what it pulled or whether it missed something. I make it flag and propose, leaving the actual cut to me. Trust but verify, with the verify built in.

You are sanitizing an internal postmortem for EXTERNAL sharing.
Audience: <public / specific customer named ___>.

Scan for and FLAG (do not silently delete) every instance of:
- Customer or company names (esp. any customer other than the audience)
- Individual person names, usernames, emails
- Internal hostnames, IPs, region/AZ identifiers, internal service names
- Anything resembling a secret, token, key, or connection string
- Exact volume/scale figures that reveal business size
- Security details that would aid an attacker

For each finding, output: the exact quoted text, its category, and a
SUGGESTED replacement (e.g. "Customer A", "an internal service",
"<redacted>", or a rounded band). Do NOT remove the lesson, timeline
shape, detection gap, or fix. Output a table. Then list anything you
are UNSURE about under "NEEDS HUMAN REVIEW".

The NEEDS HUMAN REVIEW bucket is the most important part. The model will be confident about obvious things and unsure about ambiguous ones (“is prod-checkout-7 an internal hostname or a generic label?”). I want those surfaced, not guessed.

What the flag table looks like

Quoted text	Category	Suggested replacement
Northwind's bulk import job	Customer name	”a customer’s bulk import job”
db-payments-prod-2.internal	Internal hostname	”the primary payments database”
04:12 — paged @amartin	Person/username	”04:12 — on-call engineer paged”
peak 47,300 req/s	Scale figure	”tens of thousands of requests per second”
AKIA... in pasted log	Secret	"" — rotate this key

NEEDS HUMAN REVIEW: Is us-east-1b worth removing? It reveals AZ but may be fine for a public RCA. The phrase “as we’ve seen with this customer before” implies prior incidents—consider cutting the implication.

That last secret row does double duty: it flags the leak and reminds me that a real credential ending up in a doc means the credential is compromised and needs rotating regardless of whether you publish. The AI surfaced it; a human acts on it.

Read it once more as the recipient

After the AI pass and my edits, I do one thing no tool can do for me: I read the whole document imagining I’m the specific person who shouldn’t be able to learn anything they shouldn’t. For a cross-customer share, that’s a competitor. For a public RCA, that’s an attacker. If I can reconstruct your topology or identify another customer from what’s left, it’s not sanitized yet. The model is excellent at catching the literal strings; the human catches the inferences—the “and another large customer was also affected” that, combined with public knowledge, points at someone.

The division of labor holds: AI does the exhaustive scan no tired human does reliably, and a human owns the final judgment on what’s safe to ship and signs off. A leaked postmortem doesn’t just embarrass you—it can break a contract or hand someone a map. That’s why this is the one section where I never let the tool have the last word.

The sanitizing prompt sits with the rest of my incident-comms snippets in the prompts library, and it complements the external-facing work covered across the postmortems category. For the underlying template these all build on, see the blameless postmortem guide.

Let AI catch every string. You catch every inference. Then ship it.