
More than 95% of vulnerabilities tracked under Google Project Zero’s 90-day disclosure policy have historically been fixed before the deadline. That shows responsible disclosure works when researchers and vendors cooperate. Artificial intelligence is now testing whether that same model can survive an entirely new class of security problems.
Unlike a conventional software bug, an AI vulnerability may involve prompt injection, unsafe tool use, retrieval-augmented generation (RAG), agent workflows, or model behaviour itself. Fixing it can require far more than publishing a software update.
Software Vulnerabilities and AI Vulnerabilities are Not the Same
Traditional coordinated vulnerability disclosure follows a familiar pattern: a researcher privately reports a flaw, the vendor validates it, develops a fix, coordinates public communication, and customers deploy updates.
With AI, every stage becomes more complicated. A weakness might exist in a model, the orchestration layer, external tools, memory, or retrieved documents. Sometimes the only meaningful mitigation involves retraining, redesigning permissions, or changing product behaviour.
While reviewing demonstrations of prompt injection against AI assistants for a SaaS company a few months ago, I found out that none of the examples relied on sophisticated malware. Instead, ordinary-looking text manipulated an AI system into ignoring its intended instructions. It was a useful reminder that the weakest link is not always code. Sometimes it is context.
Why Coordinated Disclosure Protects Everyone
Publishing every newly discovered AI exploit immediately may satisfy curiosity, but it can also hand criminals detailed instructions before organizations have deployed mitigations. Remaining silent indefinitely is equally problematic. Coordinated disclosure balances those competing interests.

As illustrated in the Vulnerability Disclosure Lifecycle infographic, each stage narrows the exposure window, the time a system remains vulnerable to exploitation.
- Stage 1 (Private Reporting) & Stage 2 (Vendor Validation): Contain the threat by preventing public awareness until a fix is developed.
- Stage 3 (Engineering Work): Creates the remedy, turning a known risk into a solved problem.
- Stage 4 (Coordinated Publication): Ensures transparency occurs only when the solution is ready for use.
- Stage 5 (Customer Deployment): The final step that eliminates the risk across the entire user base.
AI products often require longer remediation than conventional software. While traditional bugs are patched with code changes, AI vulnerabilities like adversarial injections or model biases, often require extensive re-training or fine-tuning.
This significantly extends Stage 3 (Engineering Work), as fixes must be rigorously validated to ensure they don’t introduce hallucinations or degrade performance. The non-deterministic nature of neural networks makes “patching” a complex behavioral adjustment rather than a simple logic fix.
Organizations including CISA, Google Project Zero, OWASP, MITRE and OpenAI increasingly recognise that AI deserves dedicated disclosure processes instead of simply inheriting traditional software security workflows.
AI Introduces Entirely New Vulnerability Classes
- Prompt injection
- Indirect prompt injection
- Model inversion
- Training-data poisoning
- System prompt leakage
- Unsafe agent tool execution
- RAG data poisoning
Each behaves differently. Some expose confidential information. Others manipulate AI decision-making or abuse connected business systems. That diversity is one reason researchers continue discussing whether every AI flaw belongs in the existing CVE ecosystem.
A Practical Example
Imagine an AI-powered customer support agent that can issue refunds. A malicious instruction hidden inside a retrieved knowledge-base article convinces the assistant to approve refunds outside company policy. The application itself has not been hacked in the traditional sense, yet real financial damage becomes possible.
If researchers publish that technique before the vendor can tighten permissions, validate tool calls and improve filtering, every deployment using similar architecture inherits unnecessary risk. Coordinated disclosure gives engineering teams breathing room while still ensuring public accountability.
The Industry is Building Common Language
MITRE ATLAS provides a shared catalogue of AI attack techniques. OWASP’s GenAI Security Project is documenting practical defensive guidance. NIST’s AI Risk Management Framework encourages organizations to manage AI risk across the entire lifecycle rather than treating security as a final deployment task.
OpenAI’s coordinated disclosure initiatives also acknowledge another emerging reality: advanced AI systems are increasingly discovering vulnerabilities in third-party software themselves. That creates new responsibilities for AI companies as both software providers and security researchers.

Building on the Vulnerability Disclosure Strategies illustration, the following table breaks down the specific impact of each approach on key ecosystem participants.
As shown in the comparison, coordinated disclosure remains the most balanced path. It prioritizes customer safety without gifting attackers an advantage, fostering a transparent, responsible relationship between vendors and the public.
Further reading
- Google Project Zero – Vulnerability Disclosure FAQ
- OWASP GenAI Security Project
- CISA Coordinated Vulnerability Disclosure
- MITRE ATLAS
- OpenAI Coordinated Disclosure
- NIST AI Risk Management Framework
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.


