Coordinated Vulnerability Disclosure for AI Models — A Field Still Making Its Rules
In November 1988, the Morris Worm brought down roughly 6,000 machines — about 10% of the internet at the time — and the response was immediate: DARPA spun up the CERT Coordination Center within weeks. For the next three decades, software security matured around a clear process for vulnerability disclosure. Researchers find a bug, notify the vendor, wait for a patch, then disclose publicly. The CERT/CC Guide to Coordinated Vulnerability Disclosure codifies this process; ISO/IEC 29147 formalizes it as an international standard for vulnerability disclosure practices. Together, they underpin billions of dollars of bug bounty programs and have become the baseline expectation for responsible disclosure in the software industry.
AI models fit into almost none of this framework cleanly.
Why Traditional CVD Doesn’t Translate
Classical coordinated vulnerability disclosure (CVD) rests on a few unstated assumptions that feel obvious for software and fall apart entirely for AI:
There is a patch. When a buffer overflow is found in OpenSSL, engineers write a fix, cut a release, push the update. The vulnerability has a version boundary: pre-fix and post-fix. For a large language model, there is no equivalent operation. A jailbreak that causes a model to ignore its safety training isn’t a two-line code change — it may reflect properties baked into the model’s weights during pretraining. Addressing it typically requires retraining or fine-tuning, which takes weeks to months, involves significant compute, and may introduce regressions in unrelated behaviors. Some properties may not be removable at all without degrading model capability.
Severity is objective. CVE scores use CVSS — a numerical formula based on attack vector, complexity, and impact. “Impact” in classical vulnerability analysis means data confidentiality, integrity, or availability. For AI model vulnerabilities, severity is context-dependent in ways that resist numeric scoring. A jailbreak that elicits unsafe content is a critical vulnerability for a consumer chatbot deployed with children; it may be a lower-priority research observation for an enterprise API with strict access controls. The same prompt that causes catastrophic harm in one deployment context causes none in another.
The vulnerability has a fixed scope. Traditional CVEs describe vulnerabilities in specific software versions. Model vulnerabilities are fundamentally different: a prompt injection technique that works on one model version often transfers to fine-tuned variants, different model families, and entirely different organizations’ deployments. When Anthropic researchers discovered that many-shot jailbreaking scales with context window length, they weren’t describing a bug in a specific Claude release — they were describing a property of transformer architectures at scale.
There is a vendor. Traditional CVD assumes a clear vendor to notify. With AI, this gets complicated. Is the “vendor” the organization that trained the foundation model? The company that fine-tuned it for a specific application? The platform hosting it? The enterprise customer who configured the system prompt? Prompt injection through a malicious webpage affects the agent, but the remediation pathway might span three organizations.
The Current Landscape
Major AI labs have started building disclosure infrastructure, but the landscape is fragmented and inconsistent.
Anthropic
Anthropic operates a bug bounty program on HackerOne, expanded in 2024 to include a model safety focus. The program explicitly rewards “universal jailbreak attacks” — those that can consistently bypass safety guardrails across a wide range of harmful topics, particularly in CBRN (chemical, biological, radiological, and nuclear) domains and cybersecurity. Bounties reach up to $15,000 for novel universal jailbreaks. This is a meaningful signal: Anthropic has recognized that generic prompt tricks are a different threat class than targeted jailbreaks, and has oriented their bounty program around the higher-severity end of that spectrum.
What remains less consistent across programs: defined timelines for disclosure after a vulnerability is reported, SLA commitments for acknowledgment and response, and public disclosure of resolved findings (analogous to traditional CVE records). This isn’t incompetence — it reflects genuine uncertainty about what “resolved” means when you can’t simply ship a patch.
OpenAI
OpenAI publishes a Coordinated Vulnerability Disclosure policy covering both traditional security vulnerabilities and “safety and abuse issues” — an explicit acknowledgment that model behavior vulnerabilities are a real category worth a formal process. Their main bug bounty runs through Bugcrowd and focuses on security vulnerabilities in OpenAI’s products and infrastructure; separately, their safety program provides a channel for reporting classifier and safety-system issues. It’s worth noting that jailbreaks and pure model-behavior findings have historically occupied an ambiguous space in terms of bounty eligibility, which illustrates the broader definitional challenge. OpenAI also publishes an outbound CVD policy governing how they disclose vulnerabilities they discover in third-party software — a mature step that treats them as a responsible member of the broader security community, not just a recipient of reports.
Google’s AI Vulnerability Reward Program, launched in October 2023 and significantly expanded in October 2025, represents one of the most structured attempts to define what constitutes a compensable AI vulnerability. The program distinguishes between traditional security vulnerabilities in AI infrastructure (in-scope, standard rewards) and model behavior issues, with specific criteria around what qualifies as a genuine safety-relevant finding versus expected model limitations. The explicit scoping is useful: it forces a definitional question the field has been avoiding.
MITRE ATLAS
While bug bounty programs operate from the defender’s side, MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) attempts to build a shared vocabulary for AI attacks — effectively the AI equivalent of MITRE ATT&CK. ATLAS catalogs adversary tactics and techniques against AI-enabled systems, drawing from real-world attack observations and red team demonstrations.
ATLAS provides something crucial that CVD infrastructure currently lacks: a shared taxonomy. Traditional CVD depends on everyone using the same vocabulary for what a vulnerability is. When a researcher files a report about “prompt injection,” does the vendor’s security team understand whether that means a direct injection into the model’s input, an indirect injection from retrieved web content, or a jailbreak that modifies the model’s instruction-following behavior? ATLAS starts to build that shared language.
The framework continues to mature — ATLAS comprehensively covers adversarial ML attack patterns but has gaps in coverage of emergent agentic system vulnerabilities, where multi-step agent behaviors create attack surfaces that don’t exist in single-model deployments.
NIST AI RMF
The NIST AI Risk Management Framework (AI RMF 1.0, 2023, with a Generative AI profile released in 2024) addresses AI vulnerability management in its “Govern” and “Manage” functions. The framework explicitly recognizes that AI systems have risks distinct from traditional software and calls for organizations to establish processes for monitoring, detecting, and responding to AI incidents. However, the AI RMF deliberately avoids prescribing disclosure timelines or mandatory reporting — it’s a governance framework, not a disclosure protocol.
The CVE Program’s Cautious Steps
The CVE Program itself has begun examining how AI-related vulnerabilities fit into its assignment processes. The questions are fundamental: Does a jailbreak in a foundation model constitute a CVE? Does the same jailbreak warrant separate CVEs for each fine-tuned variant it affects? The CVE Program’s 2024 blog post on this topic is notable primarily for its honesty: the answers aren’t clear, and the community is actively working through them.
The Maturity Gap in Practice
Consider what happens today when a security researcher discovers a novel jailbreak technique that works reliably against a major foundation model:
- The reporting channels are fragmented — per-lab programs exist (Anthropic, OpenAI, Google), but there is no AI-specific coordinated multi-vendor intake for techniques that cross organizational boundaries. CERT/CC coordinates multi-vendor disclosures generally, but the AI field lacks the tailored norms, taxonomy, and institutional relationships that make such coordination effective for model-behavior vulnerabilities specifically.
- They have no expectation about response time — is 90 days the right window before disclosure? 30 days? 180 days? For traditional software, 90 days has become the de facto standard (Google Project Zero’s policy). For AI model behavior issues, no equivalent norm exists across the industry.
- Even requesting a CVE assignment is uncertain — the CVE system requires a Coordinating Numbering Authority (CNA) to scope and assign the record, and it remains unclear whether pure model-behavior vulnerabilities qualify under current CVE criteria at all.
- Even if a lab acknowledges the finding, “fixing” it may take months and involve a new model release — not a security patch to the running deployment.
- When they eventually disclose, the same technique may work on a dozen other models the researcher never tested.
This creates genuine harm in both directions. Researchers sit on potentially dangerous techniques for extended periods with no clarity on when public disclosure is appropriate. Labs may be slow-walked into complacency by the absence of a clear deadline. And the broader research community doesn’t benefit from shared knowledge of what’s been discovered.
What Good Would Look Like
Building a workable CVD framework for AI models doesn’t require abandoning the existing one — it requires adapting it for the specific properties of model vulnerabilities.
Acknowledge the retraining problem explicitly. A 90-day disclosure window makes sense when a patch is feasible in days and deployment takes hours. When addressing a model vulnerability requires retraining — weeks to months of work — the disclosure timeline needs to reflect that reality. A tiered approach based on remediation complexity is more honest than applying a software-era deadline to a model-retraining problem.
Separate infrastructure vulnerabilities from model behavior vulnerabilities. A SQL injection vulnerability in an AI lab’s API is a traditional software vulnerability — it should follow traditional CVD processes. A jailbreak against the model’s safety training is a different category that requires AI-specific handling. Current programs blur these categories, which leads to confusion about both reporting and response expectations.
Build a shared taxonomy before it becomes urgent. The absence of agreed vocabulary for AI vulnerability classes means every disclosure negotiation involves definitional arguments. MITRE ATLAS is the right foundation for this; the field needs the equivalent of what CWE and CVE did for software — a stable reference taxonomy that lets researchers, labs, and the public reason about findings consistently.
Require minimum disclosure transparency. At minimum, labs should commit to: acknowledging receipt of a valid vulnerability report within a defined window; providing a realistic response timeline; and publishing an anonymized summary of resolved findings (without premature release of the full attack technique). “Resolved” should be defined in advance — either a mitigation has been deployed, or a defined maximum timeline has elapsed and full disclosure proceeds regardless. This avoids the failure mode where “not yet mitigated” becomes a perpetual shield against transparency.
Address the multi-vendor problem. When a technique affects models across multiple organizations, coordinating disclosure requires a neutral third party — the AI equivalent of CERT/CC. MITRE ATLAS could evolve into this role, or a new institution may emerge. The key is that the coordination mechanism exists before a major vulnerability makes its absence costly.
The Call to Action
For security researchers: Use the formal programs that exist — Anthropic’s HackerOne program, OpenAI’s Bugcrowd program, Google’s AI VRP. They’re imperfect but they’re the legitimate channel, and using them creates the data that labs need to mature their processes. When no formal channel exists for a finding, document your disclosure attempts: your timeline matters if the issue is eventually disclosed publicly.
For AI developers and operators: Publish a disclosure policy before you receive a report. Define what categories of findings you consider in-scope. Set an acknowledgment SLA. Name a contact. For web-accessible deployments, a security.txt file at /.well-known/security.txt is a standard, low-effort signal to researchers. For API-only or embedded deployments, equivalent information in your API documentation or developer portal serves the same function. A clear disclosure policy is a two-hour project that signals you’re operating professionally and creates a legitimate channel for researchers who find issues in your deployment.
For the field: The institutions that need to develop — an AI-specific CVD coordination body, standardized severity scoring for model behavior vulnerabilities, CVE-equivalent records for AI findings — will only emerge if practitioners push for them. OWASP’s LLM Top 10 is a useful starting point for framing what the vulnerability classes are. MITRE ATLAS provides the adversarial taxonomy. The missing piece is the process infrastructure that connects them.
Software security spent twenty years after the Morris Worm building the CVD ecosystem that now handles thousands of disclosures a year with established norms. AI security is somewhere in 1990 by that measure — the institutions aren’t fully formed, the vocabulary isn’t fixed, and the process fights are still happening. That’s where the field is, and acknowledging it honestly is the first step toward building what’s missing.