How AI-generated reports are treated in Apple's bounty programme
Apple Security Bounty pays researchers who find and report vulnerabilities in Apple products and services — a bug bounty, in the usual industry term.
Its official guidelines carry several statements about reports involving AI. What is being restricted is not the use of AI. The line is drawn at whether a person validated the finding.
AI-related provisions in the official guidelines
"Discovered by AI without proper validation" is named explicitly
The list of ineligible reports includes this entry: theoretical issues, and issues discovered by AI without proper validation. Apple classifies these as infeasible reports.
The wording rewards careful reading. It says not "issues discovered by AI" but "issues discovered by AI without proper validation." How you found it is not in question. Submit it after a person has reproduced it and confirmed it works, and having used AI is not an obstacle.
Infeasible reports, such as reports of theoretical issues or issues discovered by AI without proper validation. ／ Reports that are incomplete or not actionable, even if you were the first to report — such as reports without a reliable way to reproduce the issue. — From the list of reports ineligible for a reward
What triggers the 180-day pause, and what it means
It is not written as an immediate pause on a single ineligible report. The condition is repeated submission, and the language is that Apple may pause processing.
The condition and the stages
A high enough standard of evidence still gets processed
What a pause involves is spelled out. You are ineligible for bounty rewards and for credit in security advisories, and your reports will not be processed.
But an exception is written in. A report that captures the applicable Target Flag, or that demonstrates the issue with a fully packaged virtualisation of iOS or macOS, will still be processed. A Target Flag is a marker Apple places in specific locations so a researcher can show that an attack — a privilege escalation, say — actually landed.
So the pause is not designed to close the gate. It is designed to raise the standard of evidence. Assertions do not get through; something that demonstrably works does.
The stated background matches. Apple says it receives many reports claiming to be about serious security or privacy issues that were generated by large language models and submitted without the required proof or validation by a person, and that investigating them can prevent it from acting quickly on genuinely critical issues.
If you repeatedly submit ineligible reports — including infeasible reports about theoretical issues or those discovered by AI without proper validation — we may pause processing your reports for 180 days. Researchers with more than two paused status periods may be permanently removed from the Apple Security Bounty program. ／ We receive many reports claiming to be about serious security or privacy issues, but that are generated by LLMs and submitted without the required proof or validation by a person. Investigating these and other ineligible reports can prevent us from acting quickly to resolve serious and critical security issues. ／ If your status in Apple Security Bounty is paused, you are ineligible for bounty rewards or credit in security advisories during this time. We will not process your reports, unless your report clearly demonstrates the security or privacy issue by capturing the applicable Target Flag or with a fully packaged virtualization of iOS or macOS. — From the pause condition, the stated background, and what applies during a pause
What Apple means by a "complete and actionable" report
So what should you submit? The guidelines set out the requirements concretely.
A working exploit, or a reliable proof of concept
What is asked for is a working exploit or a reliable PoC — a proof of concept, the minimal implementation showing the issue actually holds. Alongside it you need to explain the conditions required to start the attack and the control, data, or privilege you gain by the end of it.
And at minimum, a concise, numbered list of steps required to reproduce the issue is set as the floor.
There is a line about how to write it, too: avoid lengthy descriptions generated by AI tools. That is not a limit on volume but a standard for density — leave only what a reader can use to confirm the finding. Whether a report has run long is easier to notice once you actually count it.
Note that only the first report qualifies. For any given issue, only the first complete and actionable report Apple receives is eligible for a reward, even if it is not the first or only report received. The test is not who reported first, but who first filed a complete and actionable report. Part of why volume-based tactics do not work here is this design.
A working exploit that explains the conditions required to start the attack and the control, data, or privilege you gain by the end of the attack — or a reliable proof of concept (PoC) for the issue you’re reporting. Your report must at least include a concise, numbered list of steps required to reproduce the issue. ／ Avoid lengthy descriptions generated by AI tools. ／ Only the first complete and actionable report we receive for an issue is eligible for a reward, even if it’s not the first or only report we receive. — From the report requirements, the note on AI-generated descriptions, and which report qualifies for a reward
The reported submission cap and 30-day cooloff are not in the official guidelines
There is also reporting that Apple set a cap on how many reports can be submitted, with a 30-day waiting period once the cap is hit (9to5Mac, August 3, 2026, which credits the Financial Times). This article does not cover that.
The reason is simple: no submission cap and no 30-day figure appear in Apple's public guidelines. What the official text sets out, as above, is a 180-day pause on processing in response to repeated ineligible reports — not a limit on the number of submissions.
The two resemble each other but are different mechanisms. One is a pause conditioned on report quality; the other is a restriction on volume. Blend them and a constraint Apple has not published starts to look like established fact. If a submission cap is officially announced, we will cover it then.
Conclusion: drawing a line around plausible-looking AI output
What this text establishes is that Apple is not prohibiting AI; it is pinning the responsibility for validation on a person. How you found it does not matter. Showing that it works stays a human job. That way of drawing the line fits what a bounty programme is.
Output that looks plausible but is not correct slipping through mechanical checks happens in other fields too. An AI-assisted mathematical "disproof" that got accepted by exploiting a bug in the checker — the Collatz case — is the clearest example. Polish and correctness are different things.
In security reporting, the thing that closes that gap is reproducibility. Apple naming Target Flags and full virtualisation as the specific exceptions during a pause is that policy — demonstration rather than assertion — pushed down to the level of operations.
