Back to Chromium

AI-generated security bugs FAQ

docs/security/ai-generated-security-bugs-faq.md

149.0.7827.25.4 KB
Original Source

AI-generated security bugs FAQ

Chrome Security Team, April 2026

AI models are getting increasingly good at finding and exploiting security vulnerabilities, and it is vital that we find and fix these bugs sooner than attackers can. As such, all Chrome engineering teams are and will be seeing an influx of security bugs generated by AI models, both externally submitted (via our Vulnerability Rewards Program) as well as internally generated.

In this document, we respond to frequently asked questions regarding this situation.

Googlers can also refer to the internal version of this FAQ.


What is the current guidance for remediating security bugs?

For now, please prioritize remediating:

  • S0 security bugs within 1 week
  • S1 security bugs within 4 weeks

For more information, please see go/chrome-slo.


What if I disagree with the severity of my security bug?

Not all AI-generated security bugs have had their severity confirmed by a member of the Chrome Security team. As such, if you have familiarized yourself with Severity Guidelines for Security Issues and you believe the severity of your bug is incorrect, please change it to what you believe is correct and add a justification comment along with the change.


Why are some of these reports invalid? How do I get fewer invalid reports?

You can improve the AI tools' ability to understand your code and discourage it from filing invalid bugs.

Adding a SECURITY.md file to your directory that describes your security boundaries will be read by the tools and will cause bugs to be filtered out based on this. You can refer to examples in the code base, or even get Gemini to help you write one if you explain your security boundaries to it. This is documented in security-for-agents, and can help weed out attacks you don't consider possible. The Chrome Security team can also help if you have any questions about security boundaries.

Closing invalid bugs is also helpful. We periodically use bugs marked as Working as Intended or Not Reproducible as training and evaluation cases for improving AI based tooling.


Why don't the bug reports have a Proof Of Concept (POC)?

This is actively being worked on – most issues now have POCs attached as a follow-up step to the initial report, but you still might see some without a full POC.

Regardless of the POC being there or not, we ask you to initially treat this as a full security issue.


How should we handle bugs behind disabled feature flags?

Bugs behind disabled feature flags are only launch-blocking. Please add the bug to the Security_Impact-None hotlist (hotlistid: 5433277) to disable SLO tracking, or leave a comment if you do not have access. Note that features available via an active Origin Trial are considered shipped.


My bug seems like a duplicate, should I close it?

If you happen to be aware of or have access to existing duplicates, feel free to mark AI-generated security bugs as duplicates, or mark other bugs as duplicates of them.

However, don't worry about searching widely for duplicates – unless you have security bug access, which is restricted to members of the Chrome Security team, existing duplicate bugs filed in other components or areas may not be visible to you.


What if I can't fix the bug because the root cause is in an external dependency?

If a vulnerability requires an external third party to fix their code, and we can't patch around the vulnerability as a temporary fix, mark the bug with the Status_ExternalDependency hotlist (hotlistid: 5438152), or leave a comment if you do not have access.


Do AI-generated security bugs have special requirements around being made public?

No, we should treat these in the same way and with the same care as human-reported vulnerabilities. They will be made public 14 weeks after being fixed. It is OK to make a bug public if it's determined that it's not a vulnerability (i.e., the report describes a functional bug instead).


How should I think about fixing vulnerabilities vs the underlying functional bugs that may lead to vulnerabilities?

For certain types of vulnerabilities, e.g., memory-safety issues, it may be desirable to quickly mitigate the security issue without solving all related functional issues. For example, if a bug describes hitting a DCHECK (which could be triggered by a compromised renderer), a security mitigation fix would be to convert that to a CHECK.

See go/security-mitigation-explainer for some possible security mitigation fixes. If you land a security mitigation fix, you can close a bug. A follow-up bug to fix the underlying logic issue could then be filed, but will be lower-priority than addressing other open S0s and S1s.


Can Chrome Security help answer a question about a bug assigned to me?

We're here to help, but please do not assign the bug to a Chrome Security team member or [email protected]. Instead, reach out over chat to one of the current shepherds or email [email protected] directly.