What AI Vendors’ Disclosure Policies Actually Say
This chapter examines the public evidence about how AI vendors receive and classify vulnerability reports. The key task is to interpret the numbers without treating a policy document as a complete picture of an organization’s security practice. The study behind these findings can show how often vendors publish a channel, name AI risks, or explain eligibility; it cannot show every private test, informal decision, or generic policy that might accept an AI report without naming it. That distinction is essential for turning policy statistics into a fair judgment about scope.
The evidence is still valuable. A written policy is the boundary that an outside researcher can see before they test or report. It tells them whether there is a route into the organization, what kind of evidence may be useful, and whether the vendor has thought about the behavior they are investigating. When that boundary is absent or silent, the uncertainty does not disappear. It moves to the researcher, the receiving team, and eventually the users who depend on a timely response.
What the study measured—and what it could not see
The USENIX study analyzed vulnerability-disclosure policies from 264 AI vendors. Its definition of an AI vendor focused on companies with substantial AI capabilities, including frontier-model providers, generative-AI applications, and AI or machine-learning training infrastructure. That choice gives the sample a meaningful connection to the subject of AI security rather than treating every company that adds a chatbot to a website as equivalent. It also means the findings should not automatically be generalized to niche products, smaller companies using off-the-shelf components, or every organization that deploys an AI feature internally.
The study reports that 36% of the sampled vendors had no public vulnerability reporting or disclosure channel. The remaining 64% had some form of channel, but those channels varied. Around 40% operated a public bug-bounty program, 16% operated a non-paying vulnerability-disclosure program, and some vendors provided only a dedicated email address or other informal route. The practical difference is more important than the labels. A bounty program may tell a researcher how rewards and severity are handled; a non-paying program may still provide a structured route and some legal or procedural protection; an email address may provide access but little guidance about what happens next.
Only 18% of the vendors explicitly mentioned AI issues in their disclosure documents. This is not the same as saying that 82% rejected AI vulnerabilities. A vendor can include an AI-powered product in ordinary scope and judge reports according to general security criteria. It can also accept or fix an AI issue without having updated its public wording. The measured finding is narrower: explicit recognition is uncommon in the public documents examined. That matters because a researcher cannot reliably infer the vendor’s intended interpretation from a policy that says nothing about AI.
The study also found that policies mentioning AI tended to include more of the structural elements that make a disclosure program usable. For example, 88% of those policies included a clear scope-in definition, 79% described vulnerability-ineligible conditions, 65% made a service commitment, and 67% included some safe-harbor language. The comparison suggests that explicit AI recognition often appears alongside a more developed policy, rather than acting as an isolated sentence added to an otherwise empty page. It does not establish that mentioning AI causes better security or faster remediation. The study did not measure those outcomes.
Reward data are more limited still. After excluding private programs, programs that did not accept AI vulnerabilities, and programs without monetary rewards, the study examined a small set of public programs with accessible reward information. Twenty used a unified pricing structure for AI and traditional vulnerabilities, while 13 offered separate price ranges. These figures help show that vendors are experimenting with how to value AI findings, but they should not be read as a market-wide price comparison. Reward design is only one part of scope, and the denominator is much smaller than the 264-vendor sample.
The study’s methods also bound what the results can mean. It focused on public policy language and could not observe internal testing, red teaming, private bounty programs, or decisions made under generic terms. The incident and research comparisons use their own selected datasets, each with visibility and sampling biases. A public incident database may overrepresent harms that receive attention, while quietly fixed technical flaws may never become public. A literature sample from technical security venues may emphasize model attacks over human-centered harms. These limits are not ceremonial disclaimers. They tell us exactly how far a percentage can travel.
The denominators also answer different questions and should not be blended. The 36% figure concerns the existence of a public reporting or disclosure channel. The 18% figure concerns explicit AI language. The policy-element percentages concern the subset of documents that mentioned AI and therefore say something about completeness within that subset, not about all AI vendors. The reward figures concern an even smaller group selected for public, monetary, AI-relevant pricing information. A reader who treats all of these as measurements of one underlying quality score would create a conclusion the study did not make.
That discipline changes what additional evidence would be useful. To learn whether silence hides generic acceptance, researchers would need controlled review of the relevant policies plus records of how vendors handled representative reports. To assess whether proactive wording improves security, they would need report-level measures such as acknowledgement time, triage quality, remediation, and deployment, not just the presence of a dedicated page. To compare security and safety coverage, they would need incident data that includes quiet technical fixes as well as visible public harms. Until that evidence exists, the public-policy study is strongest as a map of what researchers can reasonably know before they report.
The strongest conclusion is therefore about external visibility. Many AI vendors do not give researchers a clear public answer about where an AI-related report belongs. That is a governance gap even when some of those vendors have competent private security processes. More evidence about internal handling, response times, report quality, and remediation would be needed to conclude that a particular policy position produces better security.
The flow is a measurement model, not a claim that every vendor belongs to only one operational reality. The public document or missing channel is what the study can observe. The internal practice that may sit behind it is partly invisible.
Three policy positions create three kinds of uncertainty
The study classifies the 264 vendors into three broad positions. Forty-six vendors, or 17% of the sample, were placed in a proactive-clarification profile. These vendors acknowledge AI vulnerabilities in their disclosure programs and take steps to clarify how reports should be handled. One subtype actively supports AI submissions with explicit scope, examples, dedicated evaluation, or testing resources. Another integrates AI vulnerabilities into an existing policy without treating them as a separate class. A third provides a back channel: AI issues can be reported, but not necessarily through the ordinary vulnerability or reward process.
The difference among those proactive subtypes matters. A separate channel can make ownership clear, but it may also signal that the issue will not receive a bounty or a conventional security response. Integration into a general policy can reduce unnecessary duplication and preserve an outcome-based standard, but only if the general terms are intelligible when applied to model behavior. Active support can give researchers more guidance, yet a highly specific list may become obsolete as products and attack paths change. “Proactive” therefore describes clarification, not a guarantee that every report will be accepted or fixed.
The largest group was silent: 115 vendors, or 44%. Their policies did not update publicly to address AI vulnerabilities. Silence can mean several things. The vendor may believe traditional security terms already cover its AI products. It may accept AI reports in practice but have no public language for them. It may rely on a bounty platform’s taxonomy or a separate internal team. Or it may simply have no mature process. The public document alone cannot choose among these explanations.
That uncertainty nevertheless has a practical effect. A researcher who sees no AI guidance must decide how much testing is authorized, whether a model behavior can be framed as a conventional security issue, and what evidence will be considered actionable. If they guess incorrectly, the cost may be wasted research, a rejected report, a dispute over testing conduct, or a delay while the issue is routed internally. Silence is not evidence of rejection, but it is evidence that the external interface is incomplete.
The restrictive profile included 103 vendors, or 39%. The study groups together vendors with no identifiable vulnerability-disclosure channel and vendors that explicitly refuse some AI vulnerability reports. Those cases are operationally different, even if both are difficult for an outside researcher. A missing channel provides no declared route. An explicit exclusion provides a route or policy but establishes a boundary that may be broad, temporary, or limited to particular kinds of AI behavior. Treating the two as identical would hide an important distinction in what the researcher can do next.
These positions are not a scorecard for vendor quality. A restrictive policy may reflect a product whose AI behavior is handled through a safety team, a temporary exclusion while the program is being designed, or an organization that has not built a public process. A proactive document may still have ambiguous definitions or poor follow-through. The study’s classification is best understood as a map of public expectations: how much interpretive work the vendor asks an outside researcher to perform before submitting a report.
That map changes the meaning of “scope.” In a mature conventional program, scope may be communicated through affected assets, vulnerability types, prohibited testing, reporting requirements, and reward tiers. AI makes the same fields interdependent. If a vendor names a model as an in-scope asset but excludes jailbreaks, the researcher must know whether a jailbreak that reaches a private tool is still excluded. If a vendor welcomes “model safety concerns” through an alternate address, the researcher needs to know whether the report will receive technical validation, whether evidence can be shared safely, and whether there is any escalation when the concern affects users outside the tester’s session.
The public policy is consequential even when it is incomplete because it shapes the first move in the disclosure process. Clear permission encourages testing within defined boundaries. A secure channel protects sensitive evidence. A service commitment sets expectations about acknowledgement and communication. An explanation of exclusions lets a researcher adjust the claim rather than repeatedly submit the same misunderstood report. Conversely, a vague or missing interface can suppress useful information before the vendor has a chance to evaluate it.
The evidence therefore supports a restrained but important conclusion. AI vendors are not operating under one settled model of vulnerability scope. Some explicitly adapt their programs, some rely on inherited software-security language, and some offer no dependable public path. The study does not tell us which position is universally best, and it does not prove that explicit wording alone reduces harm. It does show why the next question must concern the substance of the boundary: what kinds of AI behavior do vendors recognize as security-relevant, and what assumptions lead them to exclude the rest?