Quick answerRun a security bug bounty and a brand-safety finding channel as two related but separately scoped programs, not one combined bucket. A security finding involves data exfiltration, unauthorized actions, or multi-tenancy breaches, and belongs in the main bounty with its full reward tiers. A finding where the agent produces discriminatory, dangerous, or off-brand content with no data leak and no unauthorized action is a different risk category entirely, real, and worth rewarding, but at a lower tier and triaged by trust-and-safety rather than security engineering, since the fix is usually a policy or training change, not a security patch.
The gap most security bounty programs leave wide open
Our post on how to structure an ongoing external bug bounty program for your AI agent explicitly scopes out submissions where the agent simply gave a wrong or off-brand answer, treating that as a product-quality issue rather than a security finding. That scoping decision is correct for a security program, a wrong answer is not a data breach, but it leaves a real gap: a researcher who gets the agent to produce discriminatory, dangerous, or reputationally damaging content through clever prompting has found something genuinely worth knowing about, even though nothing was exfiltrated and no unauthorized action occurred. Leaving that finding with nowhere to go means it either never gets reported, or gets reported informally and never triaged with any urgency.
Why this is not simply an extension of the security bounty's scope
A security finding and a brand-safety finding get fixed by different teams through different mechanisms. A security finding, a jailbreak that leaks another customer's data, gets patched by tightening a technical control. A brand-safety finding, the same jailbreak technique but the payload is getting the agent to say something offensive rather than leak data, gets fixed by a policy, training, or prompt change owned by trust-and-safety or content policy, not by security engineering. Folding both into one program with one triage owner means whichever team is not a natural fit for the finding ends up handling it anyway, slower and less confidently than the team that should own it.
Set a separate, lower reward tier, not a separate program from scratch
Building an entirely new bounty program for brand-safety findings is more infrastructure than the volume usually justifies. Instead, add a clearly labeled second track to the existing bounty submission form: same intake, same researcher relationship, but a distinct reward tier priced below the security tiers, since the business impact, while real, is generally smaller and more recoverable than a data breach or unauthorized transaction. Route brand-safety submissions to a trust-and-safety reviewer at triage time rather than a security engineer, so the right team sees it first. This split mirrors the reasoning behind keeping An internal red-team pass before launch separate from ongoing external testing: different finding types need different owners, not one team stretched across both.
Define brand-safety scope as precisely as the security program defines its own
A vague brand-safety category invites the same noise problem the security program avoids by being precise about what counts. Scope it narrowly: outputs that are discriminatory toward a protected class, outputs that give dangerously wrong guidance in a health, safety, or financial context without technically constituting a policy bypass, and outputs that would embarrass the brand if screenshotted and shared publicly. Explicitly exclude ordinary factual mistakes and subjective tone complaints, which belong in your regular quality feedback loop, not a rewarded bounty channel.
Watch for findings that start in one track and belong in the other
Some submissions will look like a brand-safety finding on the surface, an offensive response, but turn out to route through a genuine policy-bypass technique that could just as easily be pointed at a security-relevant boundary. Have the trust-and-safety reviewer flag any submission that used a technique-level bypass, not just a persuasive-sounding request, back to the security team for a second look, since the technique itself may generalize to a higher-severity target even if this particular researcher's payload did not. A pattern of these crossover reports is itself a signal worth checking against when an AI agent's security posture needs a full re-audit, not just routine monitoring.
FAQ
Should brand-safety findings go through the same bug bounty program as security findings?
Use the same intake form and researcher relationship, but a separate, lower reward tier and a different triage owner, trust-and-safety rather than security engineering, since the two get fixed through different mechanisms.
What counts as a brand-safety finding rather than a security finding?
Discriminatory, dangerous, or reputationally damaging output produced with no data exfiltration and no unauthorized action. If any data left its authorized boundary or an action executed outside intended scope, it is a security finding regardless of how it was framed.
Should ordinary wrong-answer submissions be rewarded at all?
No. Keep those out of both tracks and route them to your regular quality feedback process; rewarding them dilutes the incentive structure for both real security and real brand-safety findings.