IncidentScribe

Why your security team won’t let you paste incidents into ChatGPT — and the postmortem debt that creates

2026-05-27 · ~6 minute read

The standing ban

If you’re an SRE at a regulated bank, a healthcare company, a defence contractor, or any post-2023 enterprise buyer that took an opinion on cloud AI, your organisation has a policy that prohibits pasting incident data into ChatGPT, Claude, Gemini, or any cloud LLM. Most of these policies were written in 2023 after the first round of public LLM-side leaks. Each one has been tightened in the years since.

The ban isn’t about being precious. Incident data is the dirtiest text in your organisation. It is full of:

Your security team is right to forbid pasting it into a third-party API. The exposure surface is too wide to argue with. Even a vendor with the best zero-retention policy is one configuration mistake or one breach away from exposing what you paste.

The cumulative case

The ban hardened with every public LLM-side incident. A non-exhaustive timeline of moments that mattered to enterprise security teams:

By 2026, the policy posture at most regulated buyers is no longer “be careful with cloud LLMs.” It is “if your text could surface a customer name, a credential, a dependency version, or any internal hostname, do not paste it into any cloud LLM, ever.” Incident data fails that test on every dimension at once.

What everyone else built anyway

In the same period, the cloud incident-management market converged on the opposite assumption: that buyers want AI to draft postmortems, and that they’ll accept shipping incident data to the vendor’s cloud to get it. Every major vendor shipped a feature:

All of them require shipping incident data to the vendor’s cloud. None of them ships an on-device option. The implicit assumption is the same in every case: the buyer who’s our customer is OK with cloud LLM exposure for incident data.

That assumption is true for a meaningful slice of the market. It’s catastrophically false for everyone the policy timeline above touches. The regulated-buyer slice has effectively been priced out of the postmortem-AI wave. The vendors didn’t build for them. The buyers can’t use what got built.

The postmortem debt this creates

A postmortem is high-leverage and time-pressured. The team that can write a good one within 48 hours of the incident captures the truth while it’s still fresh; everything past that becomes a reconstruction. Without AI help, the buyers who can’t use cloud LLMs have three options, each of which produces debt:

  1. Write it by hand at 2am on a Tuesday — late, after the on-call shift, with no AI assist. The doc gets written, but it’s tired and short.
  2. Skip the draft and start from a template — Confluence template plus bullet points, no real timeline reconciliation. The doc looks complete but says nothing.
  3. Defer it to a calendar-week-later meeting — by then the slice of memory that distinguished a near-miss from a customer-visible event is gone, and the doc becomes a sanitised summary instead of a real post-incident artifact.

The third option is the most common at regulated buyers. It also creates the largest debt: action items don’t get owned, contributing factors don’t get named, and the same class of incident recurs. The on-call rotation knows the pattern but can’t articulate it because no postmortem ever captured the prior cases sharply enough.

This is what we built IncidentScribe for.

What’s actually possible on-device in 2026

The product equation changed in 2025 when Apple shipped Foundation Models — a usable on-device LLM on Apple Silicon. Not a research model, not a toy: a production runtime with schema-constrained decoding, a 4096-token context window per call, and per-call latency in the low seconds on M-series hardware. It runs without an internet connection. It doesn’t ship your input anywhere.

That’s enough surface to draft a structured postmortem from a 50,000-line Slack export, on the buyer’s Mac, with App Sandbox enforcing the network boundary. The architecture has to work around the 4096-token ceiling — you can’t fit the whole incident into one prompt — but that’s a design constraint that pushes you toward a timeline-first pipeline anyway, which produces a better postmortem than a one-shot AI summary regardless.

The result: a five-section postmortem (Summary, Timeline, Root Cause, Contributing Factors, Action Items) drafted from your raw Slack export, PagerDuty dump, or log file. Every drafted claim cites the timeline events that justify it; every event cites the source line. App Sandbox enforces “nothing leaves your Mac” mechanically — there’s no API, no telemetry, no third-party SDKs in the bundle.

Where this leaves you

If you’re an SRE at a buyer whose security policy forbids cloud LLMs, you’ve spent the last two years watching a market wave you can’t participate in. The vendor demo videos all start with “imagine this — AI drafts your postmortem from your Slack channel” and you tune out because you know your security team isn’t going to sign that pop-up. The wave isn’t for you.

IncidentScribe is the postmortem drafter for the buyers cloud AI can’t reach. It runs on a Mac you already have, against incident data that never leaves it. The pipeline is structured. The drafts are cited. The drafter never sees raw incident text — only the validated timeline extracted from it, which means fabricated participants and timestamps get dropped before they ever reach the draft.

If you’ve been writing postmortems by hand at 2am for two years because the vendor option isn’t available to you: try the on-device option. $19/month for Individual, $190/year with a 14-day free trial. Mac App Store only.

Open in Mac App Store