Why Some AI Findings Are In Scope—and Others Are Not

This chapter compares the categories that AI vendors accept or exclude in public disclosure policies, then separates the reasons behind those decisions. The important question is not which attack names sound technical. It is what a vendor appears to be protecting, what evidence demonstrates a meaningful effect, and whether the stated reason for exclusion answers the same question as the researcher’s report. This comparison gives the reader a way to test a scope boundary without treating any category as inherently safe or inherently vulnerable.

The public evidence has a clear pattern. Vendors are more consistent when a report is framed as a violation of a recognizable security goal—such as authorization, data access, or system integrity—than when it is framed only as a model or content behavior. That pattern is understandable, but it is not a complete solution. A prompt injection can be a harmless manipulation in one product and a path to unauthorized action in another. A hallucination can be a quality defect in one setting and a safety-critical failure in another. Category names organize the investigation; they do not finish it.

Security goals travel better than AI feature labels

The USENIX study extracted 140 AI-specific vulnerability mentions from the policies it analyzed and grouped them into AI systems, AI models, and AI features. The groups are not three levels of severity. They describe what the policy is talking about: the surrounding service and its security controls, the model and its learned behavior, or a feature such as content generation and dialogue. The distinction helps explain why some categories are accepted consistently while others remain contested.

AI system vulnerabilities are described in terms of the security goal that the product violates. Unauthorized actions, cross-customer data access, and privilege escalation are familiar examples. The study reports that system-level vulnerabilities were the most consistently accepted, with a 91% eligibility rate in its coded comparison. These issues can involve AI, but the security property is recognizable across many kinds of software. If a model-driven agent can read data belonging to a different customer, invoke a privileged tool, or change a protected account state, the vendor has a concrete boundary to validate.

This does not mean the AI layer is irrelevant. The model may be the component that interprets an instruction, chooses a tool, or generates a parameter that crosses the boundary. But the report can be judged against a property that the vendor already has reason to protect. The AI mechanism changes how the boundary is reached; it does not erase the boundary.

AI model vulnerabilities are more specific to learned systems. The study reports high eligibility rates for several model-level categories: model extraction was 90%, adversarial examples 80%, and prompt injection 71% in the comparison presented by the paper. These rates suggest that many vendors recognize risks to model intellectual property, robustness, or controlled behavior. They also show that “AI-specific” does not automatically mean “out of scope.” A model can be a protected asset, and a model-directed attack can create a familiar security consequence.