Fleet 1.17.0 is out.See what's new →
FleetFleet
Use case

AI Workflows for Security Advisories

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.

genflows:
  - name: security-advisory
    steps:
      - {name: draft, prompt: "Draft the customer-facing advisory: impact, affected versions, remediation. NO exploit detail, NO internal system names.", corpus: ["incidents/current/*.md", "docs/security/advisory-template.md"], kind: report, out: advisory.md}
      - {name: disclosure-review, prompt: "Adversarially review: what does this disclose to an attacker? What does a customer still need to assess exposure? Flag both.", depends_on: [draft], kind: review, out: flags.md}
      - {name: security-lead-ok, depends_on: [draft, disclosure-review], kind: approval, out: decision.md}
      - {name: publish, depends_on: [security-lead-ok, draft], kind: publish, out: published.md}

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.

Frequently asked questions

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.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.