OpenAI Safety Bug Bounty: Check harm, scope and authorization

OpenAI’s Safety Bug Bounty focuses on consequential abuse and agentic failures. Its live program scope excludes general disallowed model responses, rather than promising a payout for every policy bypass.

The OpenAI-owned engagement on Bugcrowd describes risks in products that act for a user or access data as that user. Its examples include agentic tools, connectors, and MCP integrations. The relevant question is whether a reproducible flaw can cause material harm and an OpenAI-side remediation, not merely whether a model produced an objectionable answer. (OpenAI Safety Bug Bounty program rules)

OpenAI Safety Bug Bounty: Check harm, scope and authorization

The live scope includes indirect prompt injection or untrusted-content attacks that misuse an integration to access, exfiltrate, or transform sensitive data from a researcher-owned victim account, or perform a harmful action under that account. It also includes authorization and permission bypasses and materially misleading confirmations for tool actions. Reports confined to flaws in third-party services without OpenAI-side remediation are excluded. (OpenAI Safety Bug Bounty program rules)

That gives a report a practical boundary. Identify the product, integration, permission, or confirmation behavior that failed; show the authorized test account’s state and the resulting unauthorized access or action. A strange completion with no demonstrated impact is a different observation from a tool action that crosses a permission boundary.

The related discussion of prompt injection and data exfiltration concerns the broader mechanism. Program eligibility still comes from the named engagement’s own rules.

A content violation is a separate category

Bugcrowd’s OpenAI scope explicitly lists content and model-response issues as out of scope. It also distinguishes apparent proprietary information from qualifying exposure and excludes ordinary system prompts or other inference-time context except for the specified reasoning category. A response that looks sensitive therefore needs an evidentiary check before it becomes a qualifying finding. (OpenAI Safety Bug Bounty program rules)

Other programs have different boundaries. Microsoft’s AI bounty names eligible Copilot products and vulnerability criteria, with specific participation and reporting requirements. Those rules apply to that program; its targets and reward criteria should not be imported into an OpenAI submission. (Microsoft AI bounty rules)

0Din’s scope lists guardrail jailbreak categories and says such submissions must cover at least two testing categories. That is a concrete example of a program whose published categories differ from OpenAI’s general content-response exclusion. It does not establish that the same report is eligible, or receives the same award, elsewhere. (0Din program scope)

The useful decision is to match the demonstrated failure to a named program before building a report around a headline reward. Neither a broad safety label nor a successful benchmark attack supplies those terms.

Keep a private bio campaign separate from the public scope

OpenAI’s dated GPT-5.5 Bio Bounty listing describes a specific challenge: GPT-5.5 in Codex Desktop, five bio-safety questions, invitation-based access, and NDA-covered findings. It lists an application window opening April 23, 2026 and a June 22, 2026 deadline, with a $25,000 first-success award and discretionary smaller awards. That record describes the named campaign and period, rather than a current entitlement to join a private campaign or a general public jailbreak reward. (Dated GPT-5.5 Bio Bounty listing)

A private invitation, product limitation, and disclosure agreement materially change what a researcher may do with a finding. The public engagement’s scope should not be inferred from that campaign’s challenge, and the old listing should not be used to claim current model or payout terms for a later campaign.

Make the reproduction useful to the owner

For a report within the live public scope, preserve the exact product and integration configuration, the test account’s authorized permissions, the untrusted input, the attempted operation, and the observed effect. Record unsuccessful attempts as well as successful ones so the owner can assess reproducibility. These are proposed reporting practices derived from the scope’s realism, feasibility, harm, and remediation requirements; no exploit test was performed for this article. (OpenAI Safety Bug Bounty program rules)

The related attack success rates discussion concerns how a rate is measured. A program’s eligibility threshold and a research benchmark’s success definition are separate records. Do not turn a rate from one into a guarantee of a reward from the other.

The table organizes the published criteria; it does not promise acceptance or prescribe a particular exploit.

Authorization and disclosure remain part of the scope

The program requires testing on owned or explicitly authorized accounts and warns that OpenAI cannot authorize research on third-party systems. Its safe-harbor language is conditional on compliance with the policy. It also requires explicit permission for disclosure through the engagement’s process. Read those conditions for the actual test instead of treating a bounty page as unrestricted permission. (OpenAI Safety Bug Bounty program rules)

The related input validation and output filtering discussion covers defense mechanisms, rather than a testing authorization or submission rule.

The public program offers a route for qualifying agentic, permission, integrity, and other consequential abuse findings. A general model-content jailbreak, a private bio campaign, and a security vulnerability have different scope and reporting records. The report should identify that record, demonstrate the failure within its boundaries, and leave award decisions to the program owner.