Who Actually Bans AI-Written Bug Reports: A Census of Disclosure Program Policies

Not one of the 53 vulnerability disclosure and bug bounty programs in this census bans AI-written reports outright. Zero of 53. That is the finding, and it is the opposite of what a year of headlines about AI slop would lead you to expect. The curl project ended its bug bounty on 31 January 2026 after what maintainer Daniel Stenberg called an explosion in AI slop reports, closing a programme that had produced 87 confirmed vulnerabilities and over US$100,000 in rewards (Stenberg, 2026). Six months later, we went and read what programmes had actually written down. Most of them have written nothing.

The direct answer

Do bug bounty and vulnerability disclosure programs allow AI-generated reports? Yes, in every case where the published policy says anything at all. Across a fully enumerated corpus of 53 programmes retrieved on 28 July 2026, zero prohibit AI-assisted or AI-generated submissions outright. Sixteen of 53 (30.2%) address AI in their published intake policy, and 13 of those 16 permit AI with a condition attached: a human must verify the finding, or produce a working reproduction, or in three cases disclose that AI was used at all. The remaining 36 of 53 (67.9%) are silent, meaning the published policy makes no statement about AI-generated submissions in either direction. One programme's policy could not be read without a platform account and is counted separately rather than dropped.

Those percentages describe this 53-programme corpus and nothing else. The corpus definition is in the methodology below, and it travels with every number on this page.

TL;DR: what the census found

• Outright bans (2026): 0 of 53 programmes (census dataset).

• Silence is the majority position (2026): 36 of 53 programmes, 67.9%, publish no statement about AI-generated submissions.

• Programmes with any AI clause (2026): 16 of 53, 30.2%.

• Human in the loop is the dominant rule (2026): 13 of those 16 require the reporter to personally verify the finding.

• Reproduction is the second most common condition (2026): 11 of 16 condition acceptance on a working reproduction or proof of concept.

• Mandatory disclosure of AI use is rare (2026): 3 of 53 programmes require it, namely Intigriti, Django, and FFmpeg.

• Coordination platforms are unanimous (2026): all 4 platform-level codes of conduct in the corpus carry an AI clause, against 5 of 20 vendor programmes and 7 of 29 open source projects.

• Penalties are usually stated (2026): 11 of the 16 programmes with an AI clause state a consequence, ranging from a 0.8x reward multiplier at Google to a 180-day processing pause at Apple.

• Three programmes changed status with AI named as a driver (2026): curl closed its bounty, Nextcloud suspended paid bounties, and the Internet Bug Bounty paused submissions.

• The rule is sometimes not on the policy page (2026): 3 of 53 programmes publish an AI intake rule somewhere other than the page a reporter is directed to.

• The adjacent prior art (May 2026): an academic study found 118 AI policies across 1,000 popular GitHub repositories, 74% requiring a human in the loop, but it measured code contributions, not security report intake (Hora and Robbes, arXiv:2605.16706).

Key takeaways

• The "programmes are banning AI" narrative does not survive contact with the policy text. Zero of 53 prohibit AI-assisted submissions. The programmes that reacted hardest to AI slop did not ban AI; they changed the economics. curl removed the money, Nextcloud suspended the money, Google raised the evidence bar. Removing an incentive is not the same rule as a prohibition, and the distinction matters if you are drafting a policy of your own.

• Where a rule exists, it is almost always a human-in-the-loop rule. 13 of the 16 programmes with an AI clause require the reporter to have personally verified the finding. That is the same shape the academic literature found for code contributions, where 74% of AI policies required a human in the loop (Hora and Robbes, arXiv:2605.16706). Two very different corpora, two different failure modes, one converged answer.

• Silence is a finding, not a gap in our data. 36 of 53 published policies say nothing. For a reporter, that is genuine ambiguity: the platform code of conduct may bind you even when the programme brief does not mention AI at all. For a programme owner, it is an unwritten rule waiting to be tested.

• Mandatory disclosure of AI use is the rarest requirement, and one project inverted it. Only 3 of 53 require you to say that AI was involved. FFmpeg asks for the opposite disclosure: name the human who verified the report. That is a sharper control than "did you use AI", because it attaches accountability to a person rather than to a tool.

• Autonomy, not authorship, is where the real line sits. 8 of the 16 refuse fully autonomous or exclusively AI-written submissions while explicitly permitting AI assistance. Wireshark states the distinction most cleanly by allowing AI-generated reports while refusing agent-submitted ones. The policy question of 2026 is not whether a model helped write the report. It is whether a human stood behind it.

Methodology

The headline was written after the counts were frozen. We did not decide in advance whether the story was "everyone is banning AI" or "almost nobody has a policy". The frame was fixed first, every entry was coded against a published rubric, the distribution was computed, and only then was the headline written. The distribution reported here is the distribution we found.

Corpus definition and sampling frame

The corpus is a fully enumerated, purposive frame of 53 programmes across three strata. The frame was fixed before any policy text was read, so that finding an AI clause could not influence which programmes were included.

This is not a probability sample of all disclosure programmes, and we make no claim that it is. It is a census of a named, fully listed frame. Every percentage on this page therefore describes these 53 programmes and nothing else. We deliberately built a smaller, cleanly defined corpus rather than a larger vague one, because a percentage without its sampling frame is exactly the thing that gets a census dismissed.

Cut-off and retrieval date: 28 July 2026. Every policy was retrieved on that date.

Unit of observation

We coded the canonical published intake policy: the page a would-be reporter is directed to for submission rules. In practice that is the security policy, the programme brief, the VDP page, or the in-repo SECURITY.md, whichever the programme itself points reporters at.

Rules an operator published somewhere else, such as an engineering blog post or a dated programme-rule announcement, are recorded in a separate field and are not used to assign the stance code. That separation produced its own finding, covered below.

The rubric

Exactly one stance is assigned per programme, using the precedence prohibited > conditional-disclosure > conditional-human-in-the-loop > discouraged > silent. Secondary requirements are preserved as separate boolean fields, so a policy that requires both disclosure and verification is not flattened.

Coding rules, including how ambiguity was handled

1. A clause counts only if it references AI, LLMs, generative tooling, or autonomous agents in the context of how a report is produced or submitted. A generic proof-of-concept requirement that predates and does not reference AI is not an AI policy. Without this rule almost every programme would code as "AI policy" and the census would measure nothing.

2. AI references that define the subject matter of eligible reports are excluded. Prompt injection scope, model hallucination exclusions, and LLM token-consumption rules describe what you may report about, not how you may write it. Uber, Adobe, and OpenAI all mention AI in this sense and all code as silent.

3. No quote, no coding. Every stance other than silent, ambiguous, or not-publicly-accessible carries a verbatim clause in the dataset.

4. Where a stance could not be determined, it was coded silent or ambiguous, never guessed. In this pass, zero entries required the ambiguous code.

5. Policies behind a login were counted, not dropped. One programme, Dropbox, routes reporters to a platform brief that requires an account. It is recorded as policy not publicly accessible as of 28 July 2026 and counted in the denominator.

6. One case the rubric does not natively express is Wireshark, which allows AI-generated text while refusing agent-submitted reports. It is coded conditional-human-in-the-loop with the autonomy flag set, and the distinction is preserved verbatim in the dataset.

No programme was contacted, tested, or submitted to at any point. This is published policy text only.

The research gap this fills

There is a real, stated gap here. In May 2026, Andre Hora and Romain Robbes published AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? (arXiv:2605.16706, accepted to ICSME 2026). They analysed 1,000 popular GitHub repositories, identified 118 AI policies, and found that 78% permit AI-assisted contributions, 51% require disclosure when AI assisted, and 74% mandate a human in the loop. That paper measures code contributions. Nobody had run the equivalent for security report intake, which is a different corpus with a different incentive structure, since a bug report carries a bounty and a pull request does not. This census extends their question to that corpus.

What the distribution actually looks like

Here is the frozen result, with the denominator attached.

Two numbers carry the story. The first is the zero. Across four coordination platforms, twenty vendor programmes, and twenty-nine open source projects, not a single published policy refuses AI-assisted submissions outright. The second is the 36. Two thirds of the programmes in this corpus have not written a rule at all, which means the answer a reporter gets depends on where they happen to be reporting.

What the 16 policies with a clause actually require

Reading the 16 as a group is more instructive than reading them individually, because they converge.

Human verification is the near-universal condition

Thirteen of the 16 require a person to have verified the finding. HackerOne's Code of Conduct states the model explicitly, requiring human experts to investigate, validate and confirm potential vulnerabilities before submission, and it makes the point that using AI does not change the requirement to provide a reproducible proof of concept (HackerOne, 2026). Bugcrowd's Researcher Code of Conduct, updated 25 November 2025, requires researchers to manually review and validate any report created with GenAI help, and states that reports found to have been submitted without human review are subject to rejection (Bugcrowd, 2025).

This matters more than it first appears, because platform codes of conduct bind every programme hosted on them. A Shopify or Uber brief that says nothing about AI still sits underneath HackerOne's rules. Silence at the programme level does not always mean absence of a rule.

Reproduction is the second condition, and it is where the evidence bar moved

Eleven of the 16 condition acceptance on a working reproduction. GitLab's programme brief is the clearest example of a rule written in direct response to volume: it attributes a new reproduction-artifact requirement to an increase in low-quality AI-generated submissions, and states that reports lacking sufficient and verifiable evidence are closed as N/A (GitLab, 2026). Cloudflare's brief carries a section headed "AI-generated and low-effort reports" that welcomes AI assistance but requires the final report to demonstrate that the researcher understands the vulnerability and has produced a working reproduction (Cloudflare, 2026).

Nextcloud goes furthest on evidence: it accepts only issues the reporter has reproduced themselves, proven by screenshots, and closes low-effort AI-generated reports as spam with a 10-point reputation deduction (Nextcloud, 2026). Apple's guidelines rule out infeasible reports including issues discovered by AI without proper validation, and note that many reports arriving are LLM-generated and submitted without the required proof or validation by a person (Apple, 2026).

Disclosure of AI use is the road not taken

Only 3 of 53 require it. Intigriti's Community Code of Conduct asks researchers to be open and transparent about the use of AI and to disclose when and how AI was used (Intigriti, 2026). Django's security policy has a dedicated AI-Assisted Reports section requiring reporters to disclose which AI tools were used and what they were used for, and states that reports appearing to be unverified AI output will be closed without response (Django, 2026).

FFmpeg inverts the requirement in a way no other policy in the corpus does. Rather than asking reporters to declare AI use, it asks every report to include the name or alias of the human reviewer who verified it, alongside a note that the project has seen a spike in AI-generated false positives and a flat statement that automated submissions are not accepted (FFmpeg, 2026). Naming a person is a harder commitment to fake than ticking a box about tooling.

The autonomy line

Eight of the 16 refuse fully autonomous or exclusively AI-written submissions while permitting AI assistance. Wireshark states the split most precisely, allowing AI-generated reports subject to direct communication with the reporter while declaring agent-submitted reports unacceptable (Wireshark, 2026). llama.cpp permits AI in an assistive capacity only and does not accept reports written exclusively by AI, alongside a hard requirement for a working proof of concept (llama.cpp, 2026).

The Linux kernel has the most detailed AI intake guidance in the corpus, under a section titled "Responsible use of AI to find bugs". It sets requirements on report length, insists on plain text rather than Markdown decoration, asks reporters to evaluate impact against the kernel threat model rather than inventing theoretical consequences, and requires a tested reproducer, noting that a report whose reproducer does not work should have its validity seriously questioned. It also changes the disclosure clock: a bug identified with AI assistance must be treated as already public (Linux kernel documentation, 2026).

Silence is the majority position, and it is uneven

Every coordination platform in the corpus has written a rule. HackerOne, Bugcrowd, Intigriti and YesWeHack all address AI-assisted submissions in their researcher-facing codes of conduct. YesWeHack names the violation category directly, listing program spamming and AI slop together, and defines it to include submitting reports based on AI-generated hypotheses without manual verification, enforced through a seven-point ethical score that can end in a permanent ban (YesWeHack, 2026).

Below the platform layer, coverage drops to roughly a quarter and stays there. Microsoft, Meta, Mozilla, AWS, Shopify, Atlassian, Adobe, Canonical, OpenAI, Anthropic and Uber all publish intake policies with no AI clause. So do CPython, Node.js, Kubernetes, OpenSSL, Rust, PostgreSQL, Ruby on Rails, Git, WordPress, LibreOffice, the Apache Software Foundation, systemd, OpenSSH, Zephyr, Envoy, containerd, Grafana, Home Assistant, Mastodon, Electron, VLC and GNOME.

That list is worth sitting with. It includes the projects that carry a large share of the internet's traffic and build pipelines. Their silence is not evidence that they are untroubled by AI-generated reports; it is evidence that the policy layer has not caught up with the submission layer.

One adjacent detail sharpens the point. OpenSSL publishes a separate AI Code and Documentation Contribution Policy governing how AI may be used in code contributions, while its security policy says nothing about AI in report intake. The same organisation wrote a rule for one channel and not the other, which is precisely the gap between the existing literature and this census.

The rule is often not where the reporter is looking

Three of the 53 programmes publish an AI intake rule somewhere other than the policy page a reporter lands on. This is a small number with an outsized practical consequence.

Google's OSS VRP rules page never names AI. What it does carry is a raised evidence bar: memory corruption reports for the top two project tiers require exact OSS-Fuzz reproduction steps or an already merged patch. The reason for that bar is published separately, in a dated operator post from 19 March 2026 that describes a massive surge in AI-generated reports and reports seeing AI-generated submissions containing incorrect information or hallucinations about how a vulnerability might be triggered (Google Bug Hunters, 2026). A widely repeated claim that Google stopped accepting AI-generated vulnerability reports in March 2026 does not survive a reading of either document. Google raised the proof requirement and retiered the rewards. It did not ban AI.

GitHub's programme page carries no AI clause. Two dated operator posts do. On 15 May 2026 GitHub published its position that researchers must validate the output of their tools before submitting, whether those tools are scanners, static analysis or AI assistants, and stated plainly that it welcomes AI in security research (GitHub, 2026). On 22 July 2026 it announced a HackerOne signal requirement on the public programme, framed as reducing the volume of low-effort and AI-generated reports (GitHub, 2026).

curl is the third and the anchor case. Its vulnerability disclosure policy file contains only a mild instruction not to paste large AI-generated explanations. The operative rule lives in Stenberg's post, which states that the project continues to immediately ban anyone who submits AI slop (Stenberg, 2026). A reporter reading only the policy file would meet a style guideline. A reporter reading the blog would meet a ban.

The three status changes, and what they were actually about

Three programmes in the corpus changed status during 2026 with AI named as a driver. None of the three responded by banning AI.

curl closed its bounty. Stenberg's figures, verified against his own post: 87 confirmed vulnerabilities and over US$100,000 paid across the programme's life, a historical confirmed-report rate above 15%, and a collapse to below 5% starting in 2025. He attributes the decline to three combined trends, of which AI slop is one, alongside falling human report quality and a shift toward poking holes rather than helping. The programme officially stopped on 31 January 2026. Reporting continues via GitHub private vulnerability reporting or email, with no monetary reward (Stenberg, 2026). We covered the triage economics of that decision in detail in our analysis of the curl bug bounty shutdown.

Nextcloud suspended paid bounties. Its programme page, last updated 22 April 2026, states that the paid bounty programme is temporarily suspended because of the volume of AI-generated illegitimate reports, with no financial rewards for any submission regardless of severity. Intake stays open, valid reports are still triaged, fixed and credited, and the project says it hopes to restart once a reliable way to filter low-effort reports exists (Nextcloud, 2026).

The Internet Bug Bounty paused submissions. Its framing is the most interesting in the corpus because it is not a slop complaint. The programme states that AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed, and that the balance between findings and open source remediation capacity has substantively shifted (Internet Bug Bounty, 2026). That is a claim about discovery outpacing the ability to fix, not about hallucinated reports. It is the same pressure from the other direction, and it is the one that should worry defenders most.

Note the pattern across all three: the lever pulled was money or intake capacity, never a prohibition on the tooling.

The full coded census

Every row below carries a policy URL and a retrieval date of 28 July 2026. The complete dataset, including the verbatim clause for each coded entry, the stated penalty, and the coding notes, is published under CC BY 4.0 at policies.csv and policies.json.

Programmes with an AI clause (16 of 53)

Programmes whose published policy is silent on AI (36 of 53)

Policy not publicly accessible (1 of 53)

Dropbox routes reporters to a programme brief that requires a platform account to read, so its programme-specific rules could not be coded as of 28 July 2026. Reporters are still bound by the platform code of conduct, which is coded separately in this census.

What this means for defenders

The census answers a policy question, but the operational implication is about evidence, not authorship.

1. Write the rule where the reporter reads it. Three programmes in this corpus keep their AI rule on a blog while their policy page stays silent. If you run a VDP, put the rule on the intake page. A rule a reporter cannot see is a rule you cannot enforce.

2. Require evidence, not declarations. The census shows the industry converging on human verification and working reproductions rather than AI-use disclosures, by 13 to 3. That is the right instinct. Asking "did you use AI" is unenforceable. Asking for a reproduction you can run is self-verifying, and it filters bad human reports at the same time.

3. Copy FFmpeg's inversion if you can. Requiring the name of the human reviewer who verified the report puts accountability on a person. It costs a reporter nothing to comply and everything to fake.

4. Assume your remediation capacity is the binding constraint. The Internet Bug Bounty paused not because reports were wrong but because valid discovery outran the ability to fix. If AI-assisted research raises your true finding rate, triage throughput and patch velocity become the bottleneck, not intake volume. Plan the fix pipeline, not just the filter.

5. Do not confuse an unvalidated finding with a validated one in your own tooling either. The same standard the census found in these policies is the one to hold your vendors to. When you evaluate autonomous testing, ask what proportion of output arrives with a working reproduction attached, which is the subject of our work on the acceptable false positive rate for autonomous pentesting and our AI pentest benchmark results. The questions to ask an AI pentest vendor cover the same evidence bar from the buyer's side.

This is also, candidly, the standard we hold ourselves to. Stingrai's autonomous web application testing agent, Snipe, is built so that a finding arrives with a proof-backed reproduction and, where applicable, an AutoFix pull request and a PR-gating check, rather than as a narrative claim a human then has to debunk. The policies in this census are all reaching for the same property from the receiving end: a finding that a person can reproduce is worth triaging, and one that cannot be reproduced is not. If you want that standard applied to your own attack surface, our web application penetration testing and PTaaS engagements are built around it.

Frequently asked questions

Do bug bounty and vulnerability disclosure programs allow AI-generated reports?

Yes. Across a census of 53 published bug bounty and vulnerability disclosure policies retrieved on 28 July 2026, zero prohibit AI-assisted or AI-generated submissions outright. Sixteen of the 53 address AI in their published policy, and 13 of those permit AI with a condition attached, most often that a human must verify the finding. The remaining 36 of 53 say nothing about AI in either direction. Every figure and verbatim clause is published in the open census dataset.

Which programs ban AI-written bug reports outright?

None in this corpus. Zero of 53 programmes prohibit AI-assisted submissions with no path to acceptance. The nearest equivalents are partial refusals inside otherwise permissive policies: Wireshark refuses agent-submitted reports while allowing AI-generated ones, and llama.cpp refuses reports written exclusively by AI while permitting AI in an assistive capacity.

Which programs require you to disclose that you used AI?

Three of 53. Intigriti's Community Code of Conduct asks researchers to disclose when and how AI was used. Django's security policy requires reporters to state which AI tools were used and for what. FFmpeg requires the report to name the human reviewer who verified it, which is the inverse form of the same control.

Did curl ban AI bug reports when it closed its bug bounty?

curl closed the bounty rather than banning AI in its disclosure policy. The policy file asks reporters not to paste large AI-generated explanations. The stronger rule, an immediate ban for anyone submitting AI slop, appears in Daniel Stenberg's post of 26 January 2026, which also records 87 confirmed vulnerabilities and over US$100,000 paid across the programme's life and a confirmed-report rate that fell from above 15% to below 5% starting in 2025. The bounty stopped on 31 January 2026 and reporting continues without monetary reward. See our full analysis of the curl decision.

Did Google stop accepting AI-generated vulnerability reports in 2026?

No. Google raised the evidence bar and retiered rewards on its Open Source Software VRP, requiring exact OSS-Fuzz reproduction steps or an already merged patch for memory corruption reports in its top two project tiers. The reason, published on 19 March 2026, was a surge in AI-generated reports containing incorrect information or hallucinations. Separately, the main Google VRP report-quality table lists AI slop as a factor that can rate a report's quality Low, applying a 0.8x multiplier to the reward.

What is the most common rule about AI in disclosure policies?

A human-in-the-loop requirement. Of the 16 programmes in the census with an AI clause, 13 require the reporter to have personally verified the finding and 11 require a working reproduction or proof of concept. Only 3 require disclosure of AI use. The pattern matches what researchers found for AI policies governing code contributions, where 74% of 118 policies across 1,000 GitHub repositories mandated a human in the loop (Hora and Robbes, 2026).

What penalties do programs state for AI-generated reports?

Eleven of the 16 programmes with an AI clause state a consequence. They range from a reward reduction, in Google's case a 0.8x quality multiplier, through report closure and reputation loss, in Nextcloud's case a spam close with a 10-point deduction, to time-limited or permanent exclusion. Apple may pause processing a researcher's reports for 180 days and permanently remove researchers with more than two paused periods. Django, Intigriti and YesWeHack all state that repeated low-quality submissions can end in removal or a ban.

How many bug bounty programs have no AI policy at all?

36 of the 53 programmes in this census, or 67.9%, publish no statement about AI-generated submissions. Silence is uneven across the corpus: all 4 coordination platforms have a rule, against 5 of 20 vendor programmes and 7 of 29 open source projects. A silent programme brief does not always mean no rule applies, because the platform hosting the programme may impose one.

Which programs paused or closed because of AI-generated reports?

Three in this corpus changed status with AI named as a driver during 2026. curl ended its bug bounty on 31 January 2026. Nextcloud suspended paid bounties, per a programme page last updated 22 April 2026, while keeping intake open. The Internet Bug Bounty paused new submissions, citing AI-assisted research expanding discovery faster than open source remediation capacity, which is a capacity argument rather than a report-quality one.

How was this census built and how often is it updated?

The frame of 53 programmes was fixed before any policy text was read, across three strata: 4 coordination platforms, 20 vendor programmes, and 29 open source projects. Each programme's canonical published intake policy was retrieved on 28 July 2026 and coded against a published rubric, with a verbatim clause required for any non-silent code. The dataset is licensed CC BY 4.0 and carries a dated revision log. The re-check cadence is quarterly, with the next pass scheduled for 28 October 2026. Corrections are welcome at hello@stingrai.io.

Can I reuse this dataset?

Yes, under CC BY 4.0 with attribution to Stingrai. The machine-readable files are policies.csv and policies.json. Each row carries the programme, stratum, policy document, policy URL, stance code, condition booleans, stated penalty, verbatim clause, coding notes and retrieval date.

References

1. Stingrai. AI-Generated Vulnerability Report Policy Census, v1.0. July 2026. https://www.stingrai.io/data/ai-report-policy-census/policies.csv. The primary dataset behind this post: 53 programmes, coded stances, verbatim clauses, policy URLs and retrieval dates, CC BY 4.0.

2. Hora, Andre and Robbes, Romain. AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? arXiv:2605.16706, May 2026, revised July 2026, accepted to ICSME 2026. https://arxiv.org/abs/2605.16706. Analyses 1,000 popular GitHub repositories, identifies 118 AI policies for code contributions, and reports 78% permissive, 51% requiring disclosure, 74% requiring a human in the loop.

3. Stenberg, Daniel. The end of the curl bug-bounty. 26 January 2026. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/. Maintainer's account of closing the curl bounty, with lifetime programme figures and the confirmed-report rate decline.

4. HackerOne. Code of Conduct. Retrieved 28 July 2026. https://www.hackerone.com/policies/code-of-conduct. Platform-level rules including AI-assisted research and submission standards and hackbot operating principles.

5. Bugcrowd. Researcher Code of Conduct. Updated 25 November 2025, retrieved 28 July 2026. https://www.bugcrowd.com/resources/essentials/code-of-conduct/. Includes the responsible use of GenAI tools section and the human review requirement.

6. Intigriti. Community Code of Conduct. Retrieved 28 July 2026. https://kb.intigriti.com/en/articles/5247238-community-code-of-conduct. Contains the use of AI section, including the disclosure requirement and stated sanctions.

7. YesWeHack. Platform Code of Conduct. Retrieved 28 July 2026. https://helpcenter.yeswehack.io/en/articles/396541-platform-code-of-conduct. Defines program spamming and AI slop as a violation category within a seven-point ethical scoring system.

8. Apple. Apple Security Bounty Guidelines. Retrieved 28 July 2026. https://security.apple.com/bounty/guidelines/. Sets report completeness requirements, ineligibility for AI-discovered issues without validation, and the 180-day processing pause.

9. Google Bug Hunters. Streamlining Google's OSS VRP: Key Rule Updates. 19 March 2026, with an April 2026 update. https://bughunters.google.com/blog/ossvrp-rule-updates-2026. Documents the surge in AI-generated reports and the OSS-Fuzz reproduction or merged patch requirement.

10. Google Bug Hunters. Google and Alphabet Vulnerability Reward Program (VRP) Rules. Retrieved 28 July 2026. https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules. Report quality table listing AI slop under the Low quality tier at a 0.8x reward multiplier.

11. GitHub. Raising the bar: Quality, shared responsibility, and the future of GitHub's bug bounty program. 15 May 2026. https://github.blog/security/raising-the-bar-quality-shared-responsibility-and-the-future-of-githubs-bug-bounty-program/. States GitHub's validation expectation for AI-assisted findings.

12. GitHub. Next chapter: Restructuring GitHub's bug bounty program. 22 July 2026. https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/. Announces a signal requirement framed as reducing low-effort and AI-generated report volume.

13. GitLab. GitLab bug bounty program policy. Retrieved 28 July 2026. https://hackerone.com/gitlab. Ties a reproduction-artifact requirement directly to an increase in low-quality AI-generated submissions.

14. Cloudflare. Cloudflare bug bounty program policy. Retrieved 28 July 2026. https://hackerone.com/cloudflare. Contains the AI-generated and low-effort reports section and the human-readable proof of concept requirement.

15. Nextcloud. Nextcloud program policy. Last updated 22 April 2026, retrieved 28 July 2026. https://hackerone.com/nextcloud. Records the paid bounty suspension and the AI-generated reports reproduction and penalty rules.

16. Internet Bug Bounty. Internet Bug Bounty program policy. Retrieved 28 July 2026. https://hackerone.com/ibb. States the submission pause and attributes the shift to AI-assisted research expanding discovery relative to remediation capacity.

17. Django Software Foundation. Django security policies, AI-Assisted Reports. Retrieved 28 July 2026. https://docs.djangoproject.com/en/dev/internals/security/. Requires disclosure of AI tools used, verification, and avoidance of fabricated content.

18. FFmpeg. FFmpeg Security, Reporting vulnerabilities. Retrieved 28 July 2026. https://ffmpeg.org/security.html. Requires human verification, the name of the human reviewer, and states that automated submissions are not accepted.

19. Linux kernel documentation. Security bugs, Responsible use of AI to find bugs. Retrieved 28 July 2026. https://www.kernel.org/doc/html/latest/process/security-bugs.html. Sets length, formatting, impact evaluation and reproducer requirements for AI-assisted reports.

20. Wireshark Foundation. SECURITY.md. Retrieved 28 July 2026. https://github.com/wireshark/wireshark/blob/master/SECURITY.md. Distinguishes AI-generated reports, which are allowed subject to direct communication, from agent-submitted reports, which are not accepted.

21. llama.cpp maintainers. SECURITY.md. Retrieved 28 July 2026. https://github.com/ggml-org/llama.cpp/blob/master/SECURITY.md. Permits AI in an assistive capacity only and requires a working proof of concept.

22. curl project. Vulnerability disclosure policy. Retrieved 28 July 2026. https://github.com/curl/curl/blob/master/docs/VULN-DISCLOSURE-POLICY.md. The in-repo policy text, which addresses AI-generated explanations as a communication guideline.

Dataset licence: CC BY 4.0. Attribution: Stingrai, Who Actually Bans AI-Written Bug Reports (2026). Next scheduled re-check: 28 October 2026.