A Bug Bounty Policy Is More Than a Scope List

This chapter treats an AI vulnerability-disclosure policy as an interface between researchers and the organization that must evaluate their reports. The question is not how many AI attack names appear on the page. It is whether the policy tells a researcher what they may test, what they should demonstrate, where the report goes, how it will be judged, and what happens when the issue does not fit a conventional bounty category. That makes policy design part of vulnerability scope itself.

A list can look precise while leaving the important decisions unstated. “Prompt injection out of scope” does not say whether a prompt-induced disclosure of another customer’s data is excluded. “Model safety issues accepted” does not say what evidence, impact, or route the vendor uses. A short policy can be more useful than a long one if its examples expose the boundary and its process gives an unfamiliar report somewhere to go.

Scope must identify more than a product name

The first job of a policy is to identify the system boundary. A product name is rarely enough for an AI service. The relevant asset may be a public model, a private model endpoint, a retrieval layer, a plugin, a tool interface, a training artifact, a customer account, or the data that connects these components. A useful scope statement tells the researcher which products or services can be tested and which kinds of behavior are relevant to those assets.

The second job is to identify eligible behavior. The strongest public policies described in the AI-vendor study did more than list AI products. They gave examples of eligible vulnerabilities, described security impacts, named in-scope interfaces, or stated that the categories were not exhaustive and would be reviewed case by case. This allows a researcher to connect a new mechanism to a familiar property. A policy can say that unauthorized access, cross-customer data exposure, privilege escalation, or meaningful state change is eligible even when the route involves a model. It can then add examples of prompt injection, model extraction, or unsafe output without pretending that every instance of those labels has the same impact.

The third job is to state preconditions and impact scenarios. A researcher needs to know whether an issue must affect another user, a protected account, a vendor asset, or a deployed workflow. This is especially important for AI features because a behavior confined to the tester’s own session may be treated differently from one that reaches someone else’s data or causes an external action. The policy does not need to predict every product integration. It should explain the kind of boundary that turns a model behavior into a security report.

The fourth job is to explain exclusions. “Out of scope” can refer to an asset, an attack method, an expected product behavior, a lack of demonstrable impact, a prohibited testing technique, or a different reporting channel. These are not the same.