Isn't an incident exactly the wrong time to add process?

It's the wrong time to invent process. A pre-built pipeline removes decisions: where the draft lives, who reviews, who approves — all fixed before the incident. The 2am work shrinks to writing facts into the corpus and clicking approve on reviewed text.

Can both security and comms sign off?

Approval steps name their recipients, and a workflow can chain more than one gate — security sign-off, then communications sign-off — each recorded separately.

AI Workflows for Security Advisories

Name: Fleet
Author: Fleet

Publishing a security advisory is writing under the worst possible conditions: time pressure, legal exposure, and an audience that includes both your customers and the attacker. Say too little and customers can't assess their risk; say too much and you've published a how-to. Every word needs security review AND communications review, and the incident is still burning while you write.

The failure mode isn't bad writing — it's process collapse: drafts in DMs, review by whoever's awake, and no record of who approved the wording that went out.

How it works with an agent fleet

A Fleet workflow gives the advisory a fixed pipeline that holds under pressure: draft from the incident corpus, an adversarial disclosure review, and a mandatory approval before publication — with the whole chain recorded.

Step	Kind	What it does
`draft`	Document	“Draft the customer-facing advisory: impact, affected versions, remediation. NO exploit detail, NO internal system names.” Reads `incidents/current/*.md`, `docs/security/advisory-template.md`.
`disclosure-review`	Review	“Adversarially review: what does this disclose to an attacker? What does a customer still need to assess exposure? Flag both.”
`security-lead-ok`	Approval gate	Pauses the run for a human sign-off; records the approver, timestamp, and note.
`publish`	Publish	Shares the approved document at a link.

You build this once on the dashboard canvas; your self-hosted Fleet worker pulls the definition and runs it against your repository.

The disclosure review is prompted in both directions — over-disclosure (helps attackers) and under-disclosure (fails customers) — and the run cannot reach publish without the security lead's recorded decision on the exact text.

The fleet pattern

Draft from incident notes → bidirectional disclosure review → security-lead approval gate → publish. The pipeline is the discipline: 2am advisories get the same review chain as calm ones.

Guardrails that matter here

Publication is structurally gated — no decision record, no public link
The approval pins approver + timestamp + exact revision: post-incident review can verify what was approved versus what circulated in drafts
Self-hosted execution: incident details stay on your infrastructure throughout drafting and review

Who this is for

Security teams that publish advisories or disclosure notices and have learned — usually the hard way — that incident-time prose needs a process that doesn't depend on everyone being careful while exhausted.