‍Authors: Elaine Zhu, Avijit Ghosh, and Shayne Longpre

Cross-posted by the MIT AI Risk Initiative with permission because we contributed to FLARE-AI and support its development. See the original post here.

Today, we are releasing FLARE-AI, an open-source system that lets anyone report a flaw or incident for any general-purpose AI system, and route a single report to everyone who needs to see it. This aims to solve one of the major problems in AI flaw reporting: flaws that affect everyone are reported to only one company. At this demo stage, reports are only delivered to a few organizations that have agreed to receive reports from us, but we are working closely with them to bring routing fully online. Our paper, FLARE-AI: Flaw Reporting for AI, was developed with 49 experts across 32 organizations, and is being presented at ICML 2026.

‍

Introduction

For the past two years, our community has methodically built up the theoretical and practical foundations for AI flaw reporting. We first argued that good-faith AI security research warranted legal protections, and that coordinated flaw disclosure for AI should extend beyond just security vulnerabilities to include safety issues. We then tested those ideas in the real world with hundreds of red-teamers at DEF CON. We combined these lessons to define the infrastructure and best practices for robust third-party flaw disclosure. At each stage, we built consensus between those who report flaws and those who receive them through workshops and extensive consultations. FLARE-AI is the result of that consensus: we have built a working demo that lays the groundwork to massively accelerate AI flaw and incident reporting.

Independent researchers are the bedrock of AI safety and accountability. They identify failures that internal teams miss, like jailbreaks, biased outputs, and privacy leaks. But finding a flaw is only half the battle. To get it fixed, a researcher has to report it to the right people and convey the right information so it can be addressed. Today, each stage of this flaw and incident reporting process is broken.

After surveying the AI flaw reporting ecosystem and lifecycle, we built the infrastructure needed to reduce friction and break down silos. A demo is available at ai-reports.org. Our contributions include:

• FLARE-AI, an open-source AI flaw reporting system that balances ease of submission with the detail recipients need to triage.
• A routing system that takes a single report and automatically delivers it to every developer, coordinator, and database the flaw affects. In the current demo, recipient delivery is not fully active, with some organizations opting to receive reports from us; we are actively building these integrations.
• The first extensive survey of 12 prominent AI flaw and incident reporting systems.

‍

Reporting AI flaws today is broken

Hundreds of millions of people interact with general-purpose AI systems like ChatGPT and Gemini every day, yet it is often frustratingly difficult and unclear what a user should do if something goes wrong. We identified three major problems when studying existing options:

1. Reporting channels are hard to find. Even experienced researchers often do not know where to submit a flaw. Developers frequently maintain multiple inboxes for different kinds of reports, and public awareness of vulnerability coordinators like CERT, CISA, and MITRE is limited. The result is a disjointed and unhealthy reporting culture, where many jailbreaks end up posted on social media instead of being reported responsibly.
2. Reporting channels don’t talk to each other. Different organizations collect different information, use incompatible harm taxonomies, and operate under different rules about what can be shared. Reporting a flaw to one developer does nothing to speed reporting it to a different developer.
3. The burden of distribution falls on the reporter. Recipients share reports with other affected parties, so when a flaw transfers across systems, the person who found it has to file the same report to every developer the flaw touches. This is a salient issue as flaws are often transferrable – in that an attack on one system will likely succeed on another – and so a flaw would often ideally be reported to a dozen or more at-risk organizations. A responsible researcher might want to report a flaw they find to a dozen different organizations, but this could require a day or more of filling out static forms. That burden discourages reporting and leaves systems exposed. 

‍

Design challenges we had to solve

After surveying 12 reporting systems and talking to stakeholders across the ecosystem, we identified five recurring challenges: limited discoverability and transparency, unclear scope and incompatible taxonomies, inconsistent information collection that misses triage-critical details, lack of interoperability and coordination, and no guidance for strict-liability cases (like child sexual abuse material). These challenges guided the design of FLARE-AI.

‍

‍

‍

How FLARE-AI works

‍

Broad intake, structured triage. Instead of requiring reporters to classify their issue as a “vulnerability” or “incident,” FLARE-AI accepts all flaws, vulnerabilities, and incidents. The first two questions automatically route the report to the right workflow based on the issue.

Light for reporters, rich for recipients. We address the trade-off between simplicity and detail using conditional logic and progressive disclosure. Reporters need to answer a small, required core set of six fields, with an optional path of up to 30 fields. Questions are only shown if they are relevant.

One submission, many recipients. With one submission, a reporter can prepare a report that can be sent to multiple developers, coordination and security bodies like CERT and CISA, and incident databases like AIID and AVID, where every report is produced as a machine-readable JSON-LD. We automatically provide routing to some organizations that have agreed to receive reports directly from us.

‍

Specialized handling for the toughest cases. For strict-liability content, FLARE-AI asks about CSAM in the first step and directs reporters to appropriate authorities instead of accepting the material. This is a critical gap in many current systems.

‍

Built with the people who will use it

FLARE-AI was developed through iterative consultation with the stakeholders who report and receive these flaws: model developers including Anthropic and Google, security coordination bodies like MITRE and CERT, infrastructure providers like Hugging Face, and incident databases like the AI Incident Database. Security researchers pushed us toward a simpler experience, child safety experts championed stronger safeguards, and ecosystem coordinators emphasized interoperability. FLARE-AI embodies all of these priorities.

Our website where you can try the reporting workflow is now up and running as a demo, and we are working closely with developers, coordinators, and incident databases to enable end-to-end routing, so that incoming reports can be monitored and delivered  to the people who can act on them. It's open source, it’s live at ai-reports.org, and it’s ready for your first test report.