Redefining Scope for AI Vulnerability Disclosure
The subject of this series has been the public boundary AI vendors draw around vulnerability reports: what they accept, what they reject, and what they send somewhere else. The final question is what a better definition of scope should require. The answer must be precise enough to guide testing and triage, flexible enough to handle probabilistic behavior and shared ownership, and honest about the difference between a bounty decision and the broader work of reducing AI-related harm.
The evidence supports a clear direction without supporting a universal formula. Security-goal categories are accepted more consistently than labels for model or content behavior. Public policies often lag behind the risks visible in incidents and research. Coordinated disclosure works only when a report can move from discovery to validation, remediation, deployment, and feedback. Foundation-model dependencies make the receiving vendor’s role important even when that vendor cannot change the underlying model. These observations point to a definition that follows the boundary being crossed rather than the vocabulary used to describe the crossing.
A definition that follows the boundary being crossed
A defensible working definition is this:
An AI vulnerability is a reproducible or sufficiently evidenced condition in an AI-enabled system that can be used by an attacker or unauthorized party to violate a security property or cause material, context-specific harm beyond the party’s intended authority, with the AI mechanism, preconditions, affected asset, and limits of the claim made explicit.
This is a proposed scope definition, not a settled industry standard. Its value is that it joins the parts that public policies often separate or leave implicit. It begins with a condition in a system, not with a model label. It requires enough evidence to justify structured attention, but does not assume that every AI behavior will reproduce deterministically. It asks what property or harm is involved, while retaining the context and mechanism needed to understand how the effect occurs. It also refers to intended authority, because the same model response can be harmless in one session and a serious failure when it reaches another customer’s data or a privileged tool.
The first requirement is a behavior and its preconditions. A report should describe what the system did, what input or sequence produced it, which model or feature was involved, and what account state, retrieved context, tool, or deployment condition mattered. The description should distinguish what was observed from what was inferred. For a probabilistic behavior, the report can state how often it appeared, under what conditions, and what variation remained. The goal is not to demand exhaustive internals from a researcher. It is to give the vendor a realistic path to validation.
The second requirement is a security property or material harm. The CERT definition of vulnerability centers on conditions that allow an explicit or implicit security policy to be violated. That makes confidentiality, authorization, integrity, availability, and control over protected resources useful anchors. An AI behavior may also produce a material safety or abuse concern that does not belong in the conventional vulnerability queue. The definition leaves room for that concern to be recognized, but recognition does not automatically mean a bounty is owed. The policy must explain whether the issue is a security vulnerability, an alternate safety or abuse report, an incident, a product-quality matter, or a combination requiring more than one route.
The third requirement is context. Who can trigger the behavior? Whose data, account, decision, or physical or social situation can be affected? Does the effect remain inside the researcher’s session, or does it cross into another user’s state? Is an AI output displayed as advice, used as input to an automated workflow, or allowed to invoke a tool? The USENIX study found that vendors frequently treated jailbreaking, hallucination, and harmful output differently from system-level security goals. That pattern is understandable because feature behavior is more context-dependent. It is not a reason to treat context as an escape hatch from accountability.
The fourth requirement is mechanism. The definition does not say that AI-specific mechanisms are irrelevant. Prompt injection, jailbreaks, model extraction, adversarial examples, retrieval manipulation, and unsafe output each raise different questions about testing, reproduction, evidence, ownership, and remediation. The mechanism explains how the condition works and what a vendor might change. But it does not decide eligibility by itself.