Why You Shouldn't Use LLMs to Draft Your App's Security Vulnerability Disclosures (And the Ethical Way to Handle Breaches)

The High-Pressure Temptation of Crisis Communication

There is no moment in a builder's life quite as stressful as discovering a security vulnerability in production. Whether it is a leaked API key, an SQL injection vulnerability, or a data breach, your heart rate spikes, the engineering team scrambles, and the security clock is ticking.

Once the patch is deployed, the hardest part of the job begins: communicating the issue to your users. Writing a public security advisory or a Common Vulnerabilities and Exposures (CVE) write-up requires absolute, unshakeable precision.

When you are sleep-deprived and facing pressure from customers, it is incredibly tempting to dump your raw terminal logs, Git commits, and sloppy Slack messages into Claude or Gemini and ask it to "write a professional, reassuring security disclosure notice."

Do not do it. When it comes to security incidents, automated crisis writing is a recipe for disaster.

Why Probabilistic Engines Fail at Technical Precision

Security disclosures are not standard marketing copy; they are semi-legal, highly technical documents where every single word carries massive weight. LLMs are fundamentally ill-suited for this task because of how they handle technical accuracy under the hood.

1. The Risk of Hallucinated Mitigations If you ask an LLM to explain how a vulnerability was patched based on your codebase, it may describe a standard, generic mitigation strategy that does not actually match your real-world fix. If users rely on your advisory to secure their own integrations, and your LLM-generated document details the wrong manual steps or configuration changes, you leave your users exposed to continued exploitation. You can learn more about how models extrapolate information in our [/glossary](/glossary).

2. Tone Deafness and Polite Obfuscation LLMs are trained to be helpful, polite, and conflict-averse. When drafting sensitive communications, they often slip into passive voice, corporate euphemisms, and defensive phrasing (e.g., *"We took proactive measures to optimise our data protocols"* instead of *"We accidentally exposed customer database credentials in a public repository"*). In security, obfuscation looks like a cover-up. Your community deserves direct, transparent, and plain-spoken facts.

3. Legal and Compliance Liability If your app handles sensitive user data, a security breach triggers strict regulatory requirements (like GDPR or HIPAA). These frameworks mandate specific timelines and precise declarations of what data was accessed. An LLM has no concept of regional regulatory compliance; it will gladly write a comforting message that might unintentionally violate your legal reporting obligations or admit to liabilities you did not incur.

The Ethical Co-Authoring Workflow for Security Notices

To handle vulnerability disclosures ethically, you must keep humans entirely in charge of the facts, the scope, and the remediation steps. However, you can still use LLMs as analytical editors to refine your draft. Here is how to do it safely:

Step 1: Write the Core Facts Manually Start by drafting the core technical details yourself. Do not use AI for this stage. Clearly write down: * **What happened:** Exactly what the vulnerability was and how it was discovered. * **The impact:** Exactly who was affected and what data was exposed. * **The fix:** What steps your team took to resolve the issue. * **Action required:** What steps, if any, your users need to take (e.g., rotating API keys, updating their SDKs).

Step 2: Use the LLM to Audit for Clarity, Not to Write Once you have your raw, factual draft, you can bring in an LLM like [Claude](/platforms/claude) to act as an editor. Instead of asking it to write the announcement, prompt it to look for gaps in your draft. For technical debugging or setting up complex prompt structures, check out our troubleshooting guides at [/platforms/claude/articles](/platforms/claude/articles).

Try using a prompt like this:

> "Review this draft of a security vulnerability disclosure. Identify any technical terms that are unexplained, point out any instructions that could be clearer for non-technical users, and ensure the tone is transparent, direct, and takes full responsibility without using corporate jargon. Do not rewrite the facts; only highlight areas for improvement."

Step 3: Run a Internal "Worst-Case" Review Before publishing, have your technical leads and your customer-facing team read the draft. Ask two questions: 1. *Is every single command, path, and version number in this document 100% correct?* 2. *Does this sound like a human taking accountability, or a robot trying to save face?*

Transparency Trumps Polished Copy

In the aftermath of a security incident, your users do not need beautiful, flowing prose or perfect marketing alignments. They need to know if their data is safe, how you fixed the issue, and how you plan to prevent it from happening again.

By keeping LLMs away from the keyboard during a crisis and writing your security disclosures with human-driven honesty, you preserve the most valuable asset your business has: your users' trust.