On August 4, 2026, participants in the Open Secure AI Alliance released as an RFC a proposal to establish a "Shared AI Findings Exchange (SAFE)" for sharing AI system incidents and near-misses across organizations. If adopted, notification to affected organizations would occur as soon as possible, notification to customers likely affected based on credible evidence would occur within 72 hours, and initial reporting to SAFE would occur within 4 business days. Can problems caused by AI agents be turned from something closed off within each company's internal investigation into defenses based on shared evidence and deadlines? The value of the proposal will be determined by how it operates going forward.
SAFE brings deadlines to incident sharing
The cases the SAFE draft requires to be reported include instances where an operational AI system accessed a third party's environment without authorization, or broke through boundaries such as a sandbox to affect the outside world. This also includes acquiring or redistributing a third party's confidential information without consent. If an operator knows or reasonably suspects that an activity is unauthorized or outside the scope of approval, and exploration or changes to the production environment continue after that point, it must be reported.
The proposal does not let the perpetrator's own perception—such as believing they were in a test environment—serve as grounds for avoiding a report. In addition to incidents where damage has been confirmed, near-misses that did not result in actual harm are also covered. The design starts from whether a third party's boundary was crossed or nearly crossed, rather than from intent or whether damage was confirmed.
Notification and disclosure proceed along the following timeline.
| Deadline | Response required by SAFE draft |
|---|---|
| As soon as possible | Notify directly affected organizations |
| Within 72 hours | Notify likely-affected customers based on credible evidence |
| Within 4 business days | Submit initial incident report to SAFE, treated as confidential |
| Within 14 days | Issue broader customer advisory information as needed |
| Within 30 days | Publish a fact-based interim report, accounting for legal and investigative constraints |
| Within 90 days | Publish remediation status |
| Weekly | Provide machine-readable updates while significant risk remains |
This schedule does not replace contractual, statutory, or regulatory reporting obligations. Limited exceptions are allowed in cases where public disclosure could lead to immediate misuse or harm an investigation, while prompt communication to affected parties is still required. SAFE is not a proposal to create a new regulatory channel, but a mechanism to increase the industry's learning speed in parallel with existing obligations.
An 8-layer review that doesn't reduce incidents to the model alone
The RFC examines incidents by dividing them into 8 control layers. It starts with whether the model recognized uncertainty or stop conditions, then moves through instructions and safeguards, on to tools and the execution environment. It further covers monitoring and human operations, as well as the supply chain, including cloud infrastructure and evaluation platforms.
AI agents use credentials, call external tools, and operate over networks. Even if a model makes an unexpected decision, external harm can be contained by restricting permissions, limiting destinations to an allowlist, and stopping anomalous behavior. Conversely, even if the model itself passes testing, an incident can occur if isolation of the evaluation environment or human stop procedures break down. The 8-layer review is a breakdown table designed to prevent the cause from being reduced to the single phrase "model performance."
The evidence needed for investigation has also been specified in concrete terms. This includes prompts, execution traces, tool calls, and logs, as well as the versions of the model and safeguards, and the permissions and credentials available at execution time. It also preserves the points at which humans approved or intervened, files created or modified, and events from detection through recovery. Because a complete timeline, reproduction tests, and evidence confirming remediation must all be assembled, operations that merely explain the outcome after a failure and stop there are not permitted.
Within 30 days, an interim analysis of which controls failed must also be submitted. This opens up the explanation "the model ran amok" into verifiable questions: which boundary was breached, where detection failed, and who was unable to stop it.
Three stages from confidential sharing to public countermeasures
Disclosure under the SAFE draft occurs in three stages. First, indicators of compromise and containment procedures are urgently shared confidentially with trusted participants. Next, analysis and recommendations with parties made difficult to identify are shared with members as operational information. Finally, excluding sensitive information, root causes, prevention measures, and adoption status are published publicly as a safety report.
In its announcement, the Linux Foundation cited NASA's aviation safety reporting system as a precedent. To encourage candid reporting, SAFE also intends to respond to good-faith errors in a non-punitive manner and to anonymize reporters as needed. However, intentional or criminal acts are excluded from this protection. It separates confidential review for the purpose of learning from the legal rights held by affected parties or regulators.
The outcomes of incident review are not limited to reports. As long as sensitive evidence is not leaked and no new dangers are created, reusable tests and machine-readable policies are published. Detection rules, reference configurations, and response procedures are also collected into a version-controlled catalog. For example, in the case of unintended access to a live system, outbound communication would be denied by default, with destinations restricted via an allowlist. Signing evaluation configurations and confirming isolation before execution are also candidate countermeasures.
Affected organizations may correct factual errors, but they do not have the authority to reject lessons learned or recommendations. Furthermore, the draft calls for independent operation such that no single company or industry dominates conclusions, and it treats open and closed AI under the same procedures. The RFC is designed to combine neutral operation with limits on veto power, so that shared evidence is reflected in reproducible countermeasures.
The adoption hurdle a coalition of over 120 must clear
According to NVIDIA, participating organizations in the Open Secure AI Alliance exceeded 120 as of August 4. The Alliance's launch was announced on July 27, and the SAFE draft came out about a week later. Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat, and others were involved in drafting the initial proposal.
As the number of participating organizations grows, it becomes easier to spot trends in incidents that span different models, clouds, and security products. However, numbers alone do not guarantee the effectiveness of the system. The RFC does not specify a timeline for formal adoption, the number of votes required, the staffing and budget of the organization receiving reports, or how to handle members who fail to meet deadlines. Where confidential information will be stored, and how confidential review will coexist with existing legal obligations, also remain matters for future design.
Of particular note is that the draft contains both principles framed as "should" and a reporting agreement that members agree to and framed as "must." As the RFC transitions into formal membership requirements, the test will be whether an operating body can be created that companies can actually entrust with incident information and execution logs, while keeping the strong deadlines intact.
The assessment will be determined by operations after the RFC is adopted. Will participating organizations report cases within common deadlines, and will they be able to publish tests and detection rules built from that evidence? Only once that point is reached can SAFE's goal—turning one company's near-miss into a defense that others can test before it becomes a production incident at their own organization—be confirmed as something that actually operates.