When a security researcher finds a universal jailbreak that bypasses safety filters across multiple AI models, who do they tell? OpenAI, Anthropic, Google, and Meta each have separate forms with different schemas and different response expectations. Submitting to all four means duplicating work four times — and there’s no guarantee those four labs will coordinate their patches. Meanwhile, the jailbreak stays undisclosed in the time it takes to file each form individually.
This is the problem FLARE-AI (Flaw Reporting for AI) was built to solve. The project — a paper by Shayne Longpre and 17 co-authors from MIT Connection Science, CMU’s Software Engineering Institute, and collaborators across 32 organizations — was presented as a poster at ICML 2026 (arXiv: 2606.31567), with the CMU SEI publishing a companion news story in July 2026. The platform is open source and live at ai-reports.org.
The Problem: Fragmented, Siloed, Non-Standardized
The research team audited 12 existing reporting systems published by AI developers, cybersecurity groups, and AI flaw aggregators. They found five recurring design failures:
- Discoverability — reporters can’t find where to submit, even when a form exists
- Scope — each system has idiosyncratic definitions of what constitutes a reportable “flaw,” leaving reporters uncertain whether their finding qualifies
- Information collection — forms collect too little for triage (missing context the recipient needs) or too much irrelevant detail
- Coordination — recipients silo what they receive instead of routing to other relevant parties; a universal jailbreak reported to one lab stays at that lab
- Guidance for strict-liability cases — when an AI system causes verifiable harm, reporters often don’t know whether to use a developer form, a government incident registry, or both
The team validated these findings through interviews and feedback sessions with 49 experts across those 32 organizations — a mix of AI developers, independent security researchers, and ecosystem coordinators (incident registries, government agencies).
What FLARE-AI Does
FLARE-AI replaces the parallel-form problem with a single structured submission that produces a machine-readable output and optional simultaneous routing.
Structured collection. The form uses conditional logic and early classification to gather triage-relevant information efficiently. It asks different follow-up questions depending on flaw type — a jailbreak gets a different branch than a demographic bias finding or a data-poisoning vulnerability — so the resulting report contains what recipients actually need for triage, not a one-size-fits-all schema.
Machine-readable output. Reports are produced as JSON-LD — structured linked data, not a PDF or free-text email. This means recipients can ingest reports programmatically, route them to ticketing systems, and query across multiple reports for patterns. If you receive 20 FLARE-AI reports about your AI system in a month, you can aggregate them.
Stateless by default. The platform doesn’t store reports server-side unless the reporter opts in. A reporter can generate a fully-formed JSON-LD report and download it locally, then manually decide what to do with it. There’s no account required, no data tied to an identity on the platform’s side. This matters for reporters in jurisdictions where vulnerability disclosure has legal ambiguity, and for researchers who want to review and edit a report before submission.
Optional simultaneous routing. If the reporter chooses to disseminate, they can select from a curated list of dozens of AI developers, security agencies, flaw databases, and ecosystem coordinators. FLARE-AI routes the same report to all selected recipients via a mix of direct API calls and official email channels — one action, not N parallel form submissions.
Approximately 10 minutes end-to-end for a typical flaw report, according to the research.
Who This Affects
Researchers and red-teamers. If you find jailbreaks, biases, safety failures, or capability-related risks in AI models you don’t own, FLARE-AI is the reporting channel now with multi-recipient routing built in. The prior approach (scattershot emails to security@ addresses) didn’t reliably reach incident registries or government agencies that might be interested in systemic patterns.
Builders deploying AI systems. Your users, your customers, and independent researchers can now find a standardized channel for reporting flaws in your AI product — and route their reports directly to you as a registered FLARE-AI recipient. If you operate an AI product and don’t have a structured vulnerability disclosure channel, FLARE-AI’s recipient registry is one path to get there without building a custom intake pipeline.
Multi-vendor platforms. If you’re building on top of multiple foundation models (e.g., a routing layer that calls Claude, GPT-5.6, and Gemini 3.5 Flash based on task type), a flaw in your system may implicate more than one upstream provider. FLARE-AI’s simultaneous routing makes it practical to notify all relevant parties at once rather than choosing one and hoping for cross-lab coordination that rarely happens.
Agent builders. Autonomous agents introduce new failure modes — prompt injection, scope violations, tool misuse, unintended side effects — that don’t fit neatly into traditional CVE frameworks designed for software bugs. FLARE-AI explicitly accommodates AI-specific flaw types, including behavioral failures, misuse vectors, and model-layer vulnerabilities that sit outside the traditional “software vulnerability” definition.
What FLARE-AI Is Not
FLARE-AI is a routing and standardization layer, not an enforcement mechanism. It generates structured reports and gets them to the right parties; it does not compel a response from any recipient, guarantee a patch timeline, or assess the validity of a report. The value is in reducing friction and improving coordination — not adding authority.
It also doesn’t replace responsible disclosure practices for individual lab security teams. It adds a coordinated layer on top of existing direct submission paths rather than replacing them.
Builder Action Items
If you operate a deployed AI system: Register as a FLARE-AI recipient so researchers have a clear path to reach you with structured reports. The platform’s curated list of developers is public; being discoverable there is part of operating responsibly in the current AI ecosystem.
If you conduct red-teaming or security research: Bookmark ai-reports.org as the default first step when you find a cross-system issue. For single-lab findings, direct disclosure to that lab’s security team is still appropriate. For cross-system issues — universal jailbreaks, multi-model bias patterns, shared training data problems — FLARE-AI’s multi-recipient routing is the right channel.
If you’re building vulnerability management for your AI product: The JSON-LD output format means you can ingest FLARE-AI reports programmatically. Review the arXiv paper’s schema documentation to understand the structure and plan your integration. The stateless architecture means your intake pipeline receives reports without FLARE-AI holding copies of the data — relevant if you’re processing sensitive findings under NDA or similar constraints.
The AI reporting ecosystem has lagged behind the software security disclosure ecosystem by a decade or more. FLARE-AI doesn’t close that gap overnight, but it establishes a common schema and routing layer that the ecosystem has lacked. For builders deploying AI systems that users can interact with, the responsible-disclosure question is no longer “do we need this?” — it’s “are we already reachable via this channel?”