Apple @ Work: Capping bug bounty submissions is the wrong response in the AI era of security threats

Apple confirmed it's now limiting how many vulnerability reports security researchers can submit through its bug bounty portal, according to Apple @ Work. Hit the cap and you're locked out for 30 days. The official reason is a flood of AI-generated junk reports clogging the review queue.

Here's the problem with that response. We're entering an era where attackers are using AI to discover and exploit vulnerabilities faster than ever. Automated fuzzing, LLM-assisted reverse engineering, and AI-generated exploit chains are real and accelerating. Capping legitimate researcher submissions because of spam is like locking the fire exits because too many people are pulling the alarm.

Apple's instinct makes operational sense. If ChatGPT is spitting out thousands of low-effort bug reports that waste reviewer time, something has to give. But the better answer is smarter triage on Apple's end, not throttling the researchers who actually find critical flaws. Build better filters. Use AI to screen AI-generated noise. Don't penalize the signal because of the spam.

This matters because the incentive structure is already fragile. Security researchers can sell iOS exploits on the gray market for hundreds of thousands of dollars. Apple's bug bounty payouts max out lower than that. If you add friction like submission caps and cool-down periods, you're just pushing more researchers toward less responsible disclosure or straight to brokers.

The timing is especially bad. As AI makes vulnerability discovery cheaper and faster for both attackers and defenders, you want more eyes on your platform, not fewer. The threat landscape is expanding. Closing the front door to your own security community is backwards.

What this means for you: if you're building or securing software, don't solve automation problems by limiting access. Invest in better screening and prioritization. And if you're using AI to assist with security research or code review, here's a practical prompt to try: 'Review this code for common vulnerability patterns like SQL injection, XSS, and improper authentication. For each potential issue, explain the risk, provide a proof of concept if applicable, and suggest a remediation.' That kind of structured output is useful. Mass-generated noise is not. The difference is intent and quality, and systems need to distinguish between them.