Continuing our work to reduce AI slop submissions and protect signal quality

At Bugcrowd, we’ve witnessed the growing impact of “sloptimism”—high-volume, low-confidence submissions that degrade signal quality and slow outcomes for both customers and high-performing hackers. As submission volumes have scaled, particularly with the rise of AI-assisted workflows, our focus has remained on reinforcing a simple principle: 

Every submission must be attributable to a responsible individual and stand up to scrutiny. 

We have continued to analyze submission patterns and implement additional safeguards to ensure that the Bugcrowd Platform remains focused on validated, high-impact research. As part of this effort, we’ve introduced four major changes to ensure that submissions are grounded in accountability, not anonymity at scale:

1. Bans on accounts engaging in submission farming or submitting ≥10 invalid reports
2. Mandatory identity verification (IDV) before submitting to Managed Bug Bounty programs
3. Submission throttling for low-performance accounts. 
4. CAPTCHA validation before submission.

We published a blog in March that dove deeper into the impacts of sloptimism and our changes around accounts engaging in submission farming. This blog post covers the second and third changes: mandatory IDV and submission throttling. 

Mandatory identity verification (IDV) for Managed Bug Bounty (MBB) participation

In May, we are implementing mandatory IDV for any hacker who wishes to submit to an MBB program. This applies to all new and existing accounts. Accounts that are not verified will still be able to access other parts of the platform (such as VDPs), but will not be permitted to submit to MBBs until verification is complete.

Why this change is necessary

Over recent months, we’ve observed a clear pattern:

• High volumes of low-quality submissions originating from newly created or rotating accounts
• Use of multiple accounts (“sock puppets”) to bypass enforcement actions or distribute submission load (submission farming)
• Attempts to use platform feedback as a reinforcement signal for training AI systems.

Without a strong identity-proofing layer, these behaviors are difficult to control at scale. IDV introduces meaningful constraints to decrease the ability to evade enforcement through account cycling, resulting in stronger alignment between submission quality and hacker reputation. 

Balancing accountability with accessibility

We recognize that IDV represents a shift from how bug bounty platforms have historically operated. Our intent is not to restrict access but to ensure that participation in higher-signal programs reflects a higher standard of accountability.

To support this, we have implemented the following controls:

• IDV is limited to MBB programs, where customer expectations and impact thresholds are highest.
• Lower-barrier entry points (such as VDPs) remain available without IDV.
• Verification is designed to be a one-time process, not a recurring burden.

This allows new hackers to build experience and credibility while ensuring that those operating in more sensitive environments are held to a consistent standard.

Submission throttling for low-performance accounts

We are also introducing submission throttling across MBB programs. This is a targeted quality control lever designed to reduce the negative impact of accounts generating large volumes of low-quality submissions, while preserving capacity for hackers consistently producing validated findings. 

At a high level, submission throttling means the following:

• Accounts identified as having low submission performance will be limited in how many reports they can have in flight at a given time.
• Once the limit is reached, additional submissions will be temporarily blocked until existing reports progress through triage.
• In-platform alerts will guide affected hackers toward improving submission quality rather than increasing volume.

This ensures that triage capacity remains focused on reports with demonstrated impact, improving turnaround times and outcomes across the ecosystem. This update is going live this week. For more information on limits, access our Submission Limit documentation.

Why this change matters

Over recent months, submission volumes have increased materially, with a disproportionate share driven by speculative or unverified reports. This has resulted in the following:

• Increased queue sizes and SLA pressure
• Delayed validation for legitimate findings
• Reduced signal to noise across programs

Submission throttling directly addresses these issues by limiting the ability to scale low-quality output, without impacting hackers who consistently validate their work.

CAPTCHA validation before submission

Additionally, all vulnerability submissions must be made through a browser with a human-verified token, ensuring accountability at the point of submission. Unlike some of the other measures, this applies across all engagement types, not just Managed Bug Bounty programs.

What these changes mean for hackers

All hackers who intend to participate in MBB programs are required to complete the IDV process before their next submission when this is implemented. Further information will be available via hacker documentation, in-platform messaging, and on the Bugcrowd blog. 

Hackers who focus on validated findings, clear reproduction steps, and real security impact will not be affected by these changes. For those relying on automation, AI-generated content, or speculative reporting without validation, these controls are designed to reset expectations and encourage a return to quality-driven research.

Looking ahead

These four major controls are part of a broader effort to reinforce accountability in submissions, protect triage capacity, preserve access for legitimate hackers, and maintain trust and a high-signal Platform for customers and hackers alike. 

We will continue to monitor the impact of these changes and refine our approach as needed. As always, we welcome feedback from the community through the HIVE or support channels.