SAFE RFC: OSAA's aviation-style AI incident exchange is an open draft, not yet a system

On 4 August 2026, as Black Hat USA opened in Las Vegas, the Linux Foundation published a Request for Comments for the Shared AI Findings Exchange (SAFE) Working Group — a proposal for organisations to report AI security incidents and near misses into a confidential shared channel, learn from them collectively, and publish defensive controls derived from what failed. The initial draft was developed by contributors from Cisco, CrowdStrike, Hugging Face, NVIDIA and Red Hat, among other alliance members, the Linux Foundation said in its announcement. It was opened for community review through the Open Secure AI Alliance's GitHub repository the same day. The entry describes no harm: it is a policy record, filed in the archive with an info severity grade and an A confidence grade, and its subject is a process rather than an event. The record's severity grade, confidence rating and source list sit in the AI incident archive, alongside the entries filed around it.

The draft asks members to report four things, and to ignore why

The August text is short on rhetoric and specific about triggers. Under a heading called the Reporting Compact, it asks members to agree — as a condition of membership — to report an incident when they become aware or reasonably suspect that an AI system they operate has done one of four things: accessed, exploited, disrupted, misused or modified a third-party system without authorisation; caused third-party impact by escaping or bypassing a sandbox, network, identity, policy or tool boundary; accessed third-party confidential information without the consent of its owner; or kept probing, accessing or modifying a production target after the operator knew, or reasonably suspected, that the activity was unauthorised or outside the approved scope.

Then comes the sentence that does most of the work: "Intent does not determine whether an event is reportable. Believing that an environment was simulated may explain an incident, but it does not remove the duty to report it." That clause reads as addressed to the case where a system is running in what its operator believes is a sealed test environment and treats live infrastructure as part of the exercise: the operator's belief about the environment may explain the event, but it does not remove the reporting duty. The draft also asks members to report near misses, not only events that produced confirmed harm, and to deliver a preliminary control-failure analysis within 30 days.

The clock: immediate, 72 hours, four business days, ninety days

The draft's notification table is the most concrete thing in it, and the first row is not a deadline at all: the directly affected organisation is to be told immediately. Every deadline runs from the moment the member becomes aware of facts giving reasonable grounds to suspect a reportable event — not from the moment an investigation concludes. The table below is reproduced from the 4 August draft; the October revision keeps the same intervals.

Three of those rows are about telling other people, and four are about telling SAFE itself. The distinction matters because the framework is explicitly not a disclosure regime: the draft says "These timelines do not replace any supplier obligation to notify affected parties, customers through existing Coordinated Vulnerability Disclosure best practices, or applicable contract and other legal obligations to notify regulators or law enforcement." What SAFE adds is a parallel obligation to a body that is not a regulator — and a three-tier disclosure model in which only the last tier, the public safety report, is meant to be broadly shareable.

Eight control layers in August, eleven in October

Reviews are structured around the operating stack rather than around the model alone. The August draft listed eight layers and asked one question of each — did the model recognise uncertainty and stop conditions; were authorisation and environmental assumptions explicit; were classifiers, approvals and action limits working; were credentials, permissions and execution constrained; were isolation and data boundaries independently verified; could operators detect and interrupt in real time; were escalation paths and kill procedures clear; did a cloud, evaluation, data or tooling partner invalidate assumed controls.

The October revision, dated 21 October 2026 and committed to the repository the next day, adds three layers: the serving path, authorisation at the moment of commitment, and workflow composition across a sequence of actions. It also turns the review into a graded assessment with four permitted answers — pass, fail, insufficient evidence, not applicable — and states in its change log that these findings do not establish general system safety or legal compliance. The progression is worth reading as a description of what the authors learned to worry about: not whether the model behaved, but whether the model that answered was the model that was configured, whether permission still existed when the action landed, and whether the sequence as a whole stayed inside the scope that started it.

Aviation, but which part of aviation?

The record's own framing — a system modelled on NASA's Aviation Safety Reporting System — follows the Linux Foundation's announcement rather than the draft. The announcement describes ASRS as "a voluntary, confidential reporting system, designed to analyze and respond to flight accidents in a manner that allows the industry to learn and improve." Neither the August draft nor the October revision names ASRS anywhere; the draft says only that SAFE "should adopt the strongest features of confidential safety-reporting systems." That is a small difference with a practical consequence: the announcement sets an expectation the text does not yet commit to.

The analogy drew comment inside the RFC process itself. An early pull request opened on 5 August, by a contributor writing in a personal capacity, argues that "the ASRS analogy has a missing institutional element" — that ASRS works in significant part because reports are received, processed and de-identified by NASA, "a public, non-regulatory and non-commercial third party—not by the FAA as regulator and not by the airlines whose operations are being reported." The pull request, which also draws on the 1998 internet governance process, remained open on 30 October. Whether SAFE's operator can play the NASA role is an unresolved design question rather than a settled feature: the October text places the working group under the Alliance's own governance, with conflict-of-interest disclosure, recusal and an appeal route to the Alliance Steering Committee.

Independent coverage drew a second, narrower distinction. Infosecurity Magazine, reporting on 6 August, noted that the Linux Foundation's post does not mention AI agents specifically — the agentic framing belongs to NVIDIA's companion post, which argues that "an AI agent isn't just a model. It's a system," and lists harnesses, sandboxes, guardrails and evaluation tooling contributed by alliance members. The draft's triggers, read literally, are about systems acting outside authorisation; the announcement's pitch, read literally, is about agents.

What commenters said about who carries the cost

One of the most specific published objections to the draft as written came from a founding member of the alliance rather than an outside critic. Stephen Sargent, founder and chief technology officer of Avondale.AI, submitted a position statement by email on 7 August — a day the document says the Linux Foundation's legal team acknowledged it — and published it on 9 August. He opens by supporting the mission and then argues the compact does not scale by organisation size: "The RFC doesn't distinguish between an organization with 50,000 employees and a small team." A four-business-day report plus a preserved forensic bundle could, in his assessment, consume more staff time than a small operator can spare; his recommendation is a tiered framework, with confidential reports and delayed or anonymised publication the default below a size threshold.

A second objection is about disclosure rather than deadlines: he argues that "public disclosure IS a form of enforcement" for small operators, because a large firm's report is a footnote and a small firm's becomes the headline, and asks that de-identified reporting be the default below a size threshold. A third is about the review framework rather than the clock: the eight-layer model assumes segregated enterprise teams, so in a one-person deployment "the operator does everything" and a missing layer is read as a control failure when it is simply a different operating model. His fourth is about the phrase "minimum interoperability and assurance practices," which he reads as a route from voluntary reporting to de facto mandatory tooling. The position statement is one member's view, published by that member. The Linux Foundation's 4 August announcement predates it and does not address the question. A later pull request, opened on 5 October and still open on 30 October, proposes an evidence template for operators without a security operations centre — an acknowledgement that the concern landed, and a candidate rather than an adopted fix, with its author stating it "does not establish SAFE adoption or legal sufficiency."

What changed between 4 August and 30 October

The repository's history is the best available record of what the RFC actually produced, and it is more legible than the news coverage suggests. The first commits landed on 3 August; the draft and an expanded readme were committed at 00:14 and 00:19 UTC on 4 August. Then the repository went quiet for ten weeks. On 14 October the alliance added a charter and a members file and rewrote the readme to make the repository the SAFE working group's home; interim chairs were recorded that day as Paul DiOrio of NVIDIA and Josh Boyer of Red Hat. On 21 October the working group published SAFE v1, with a change log whose first entry is that the text "removes 'proposed' from SAFE's description" and identifies it as an established Alliance working group.

Two things about that state are worth separating. The repository's readme now carries the line "Status: Approved — Approved by the Steering Committee," which is the closest thing to a ratification statement in the public record; the charter, by the same repository, still reads "Under development. The SAFE charter will be published here once approved by the Steering Committee." The change log labels the October text "SAFE v1" and describes what it changes, but does not say who ratified it, on what vote, or on what date. A reader who wants to know whether SAFE is now an approved specification, or a working group whose governing charter is still unwritten, will not get a clean answer from the documents.

What is established, and what is not

• Established: a Request for Comments for the Shared AI Findings Exchange was published on 4 August 2026 — the Linux Foundation dated its announcement to that day — and the organisations named as contributors in it are Cisco, CrowdStrike, Hugging Face, NVIDIA and Red Hat, named alongside "other members of the Open Secure AI Alliance".

• Established: the draft contains a reporting compact with four triggers, a notification table running from immediate to 90 days, an evidence-preservation list, a layered review framework, and a three-tier disclosure model. The full text is public in the repository and its history is public with it.

• Established, with attribution only: the alliance's size — "more than 120 organizations" — is NVIDIA's own figure, repeated in Infosecurity Magazine's report of 6 August. None of the coverage reviewed shows an independent membership audit, and the repository's members file lists two contributors and two interim chairs, not 120 organisations.

• Not established: that anyone has filed a report under the compact. The public record on 30 October shows commits, pull requests and issues; it does not show an incident report, a pilot, a first case, a comment deadline, a voting rule or a ratification date. The framework describes an obligation members "agree to" as a condition of membership, which is not the same as an obligation anyone has yet discharged.

• Contested: whether the ASRS comparison holds without a neutral public operator, argued against in an open pull request; whether the reporting burden is proportionate for small operators, argued against in a founding member's position statement; and how much of the framework is agent-specific versus general AI security, a distinction the Linux Foundation's text and NVIDIA's text draw differently.

None of that makes the record wrong, and the archive's A grade is defensible on its own terms: the primary documents agree with each other about what was published, when, and by whom, and the draft is readable in full. What the grade cannot carry is the thing a reader most wants — whether the mechanism works. For that there is no evidence either way, because the mechanism has not yet had a case.