Apple’s AI slop filter may be catching real macOS bugs

TL;DR: AI is making vulnerability discovery cheaper, but bounty programs that respond with blunt submission caps risk filtering out the exact serious reports they were built to catch.

What actually happened with Apple’s bug reporting cap?

Decrypt reported in “Apple’s AI Slop Problem Left a $200K macOS Exploit Unreported” that a Milan start-up says it found a full-takeover flaw in macOS using ChatGPT, then could not submit it because it had already hit Apple’s new submission cap.

That is the whole tension in one sentence.

Apple, like every major software vendor, is trying to protect its security team from junk reports. AI makes that problem worse. A model can help someone generate plausible-looking vulnerability writeups, stack traces, exploit sketches, and “security concern” reports at high volume. Some will be nonsense. Some will be duplicates. Some will be low-impact issues dressed up as critical bugs.

But Decrypt’s report points at the other side of the tradeoff: if a cap blocks a real full-takeover macOS flaw, the filter has failed in a way that matters.

We do not have enough public detail here to judge the vulnerability itself. We do not know the exploit chain, affected macOS versions, reproducibility, whether Apple later received the report through another path, or whether the $200,000 figure maps cleanly to Apple’s bounty rules for this class of issue. The claim is from the start-up, as reported by Decrypt. Treat it as a serious signal, not a settled technical postmortem.

Still, the operator lesson is clear. AI has changed the report volume problem faster than it has changed the trust problem.

Is AI-assisted vulnerability research mostly slop?

No. And yes.

AI-assisted security work now includes a lot of garbage because the cost of producing “security-shaped text” has collapsed. That is not the same as the cost of producing a working exploit collapsing. The gap matters.

A real vulnerability report has evidence. Repro steps. A minimal proof of concept. A clear impact statement. Version details. Crash logs or traces. Boundaries. What it does not do. The better reports reduce reviewer work.

AI can help with that. It can also do the opposite. It can pad uncertainty with confident language, hallucinate impact, confuse similar APIs, and turn weak hunches into long submissions. If a bounty desk is measured by queue length and triage cost, it will naturally defend itself.

Apple’s reported cap is one defense. It is also a crude one. A cap assumes that submitter volume is a good proxy for report quality. Sometimes it is. A brand-new account firing off 40 vague AI-written reports in a day probably deserves friction. But a cap can also punish a small team doing a focused burst of research, especially if AI lets them test more ideas and document more findings.

The better pattern is not “no limits.” It is staged trust. Let unknown researchers submit a small number of full reports, but provide an escape hatch for high-severity claims. Ask for a lightweight severity pre-check. Require a minimal reproducible artifact before it enters the main queue. Auto-close obvious junk, but preserve a path for “this looks catastrophic and I can prove it.”

What should Apple and other vendors change?

The boring answer is workflow design.

Vendors need intake systems built for AI-era volume. That means treating submissions less like email and more like structured incident reports. The system should force clarity: affected product, version, exploit preconditions, attacker position, proof artifact, expected impact, and safe reproduction steps. If those fields are empty or vague, the report should not consume much reviewer time.

But there also needs to be a “break glass” route for potentially critical bugs. Not a VIP lane for famous researchers only. A narrow lane for reports that include enough concrete proof to justify human review even when a submitter has hit a quota.

The hidden risk for Apple is reputational. If researchers believe a serious macOS bug can be blocked by anti-slop mechanics, they may stop trying the official path first. That is bad for users, bad for Apple, and bad for the whole bounty market.

For builders running security intake, I would copy the lesson, not the drama. Add friction to low-evidence reports. Do not add blind caps without an exception path. If you use AI to help triage, make it sort for missing evidence and duplicates, not decide severity alone. And if you are the researcher using ChatGPT, make the model earn its keep by shrinking the reviewer’s job: produce a clean repro, isolate impact, remove fluff, and keep the claim narrower than your excitement. The catch most people miss is that AI does not just create more bugs or more slop. It creates more ambiguity, and your process has to resolve that before your humans burn out.