The SAFE draft asks for more than prompt logs

The Shared AI Findings Exchange (SAFE) is a draft proposal open for public comment. It is not an adopted standard, a chartered reporting body, or a live service accepting reports. On August 4, 2026, Open Secure AI Alliance participants published the request for comments so the public could review it and propose changes.

The draft shows that reconstructing an AI incident would require more than a prompt and model output. A company would need connected evidence about the model, instructions, safeguards, tools, runtime environment, monitoring, human decisions, and suppliers. This article explains those dependencies and a bounded evidence test that does not claim SAFE adoption.

What exists today is a proposal for shared incident learning

The draft proposes an independent initiative that would confidentially collect and analyze AI incidents and near misses. It would inform affected parties and convert repeated failures into shared controls. Proposed members span model developers, open-model organizations, deployers, evaluation, hosting, cloud, and tool providers, researchers, critical-infrastructure operators, affected users, civil society, and non-controlling government and standards observers.

A single company may not hold every fact when an incident crosses a hosted model, an enterprise agent, a cloud identity, and an external tool. The Linux Foundation announcement says there is no broadly adopted community framework for this type of confidential AI incident sharing.

The announcement credits contributors from Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat, and other alliance members with the initial draft. Their work does not show formal adoption by those organizations. SAFE could eventually publish reusable tests, machine-readable policies, detection rules, reference configurations, and incident-response guidance. No operating intake service or verified catalog is available in the cited material.

The proposed reporting trigger follows impact and authorization

For future members, the draft proposes reporting when an AI system accesses, exploits, disrupts, misuses, or changes a third-party system without authorization. It also covers third-party impact after bypassing a sandbox, network, identity, policy, or tool boundary, and unauthorized access to or redistribution of confidential third-party data.

An operator would also report continued targeting after the operator knows or reasonably suspects that the activity is unauthorized or outside the approved scope. Near misses would be reportable even without confirmed harm. Intent would not decide reportability: a belief that an environment was simulated might explain an incident, but would not remove the proposed duty. Reconstruction would therefore focus on what the system could reach, what it did, and when people suspected that the activity lacked authorization.

A complete reconstruction has to cross eight operating layers

An AI system acts through connected technical and human layers. The model interprets instructions, safeguards limit responses, and tools convert responses into actions. Identities, credentials, networks, and runtime configuration decide where actions can go. Monitoring, human procedures, and external providers shape detection, intervention, containment, and recovery.

The draft proposes preserving prompts, traces, tool calls, logs, configurations, model and safeguard versions, and third-party dependencies. It also calls for identities, permissions and credentials available during the run, approvals and interventions, and changed files or external items. The proposal includes containment and recovery events, a complete timeline, reproduction tests, and remediation evidence. For reconstruction, a team needs stable identities and timestamps that connect these records into one sequence.

A prompt log is one witness, not the incident record. It can show what the model received. It cannot show the effective tool permissions, an unrecorded approval, an unexpected network path, or a supplier change that invalidated an assumption.

The table pairs the draft's eight review questions with records named in the proposal and with BaristaLabs interpretations of records that could answer each question. It is a reconstruction aid, not an additional SAFE requirement.

Scroll sideways to see all 3 columns.

Draft review layer	Question for reconstruction	Records that could help answer it
Model	Whether the model recognized uncertainty, scope boundaries, and stop conditions	Model version, prompts, traces, and reproduction tests
Instructions	Whether authorization and environmental assumptions were explicit and correct	Instruction text, run configuration, approval conditions, and recorded interventions
Safeguards	Whether classifiers, policies, approvals, and action limits worked as intended	Safeguard versions, policy configuration, decisions, and intervention logs
Tools	Whether execution, publishing, spending, credentials, and permissions were constrained	Tool calls, workload identities, available permissions and credentials, and files or external items changed
Environment	Whether network paths, isolation, targets, and data boundaries were verified	Runtime and network configuration, dependency state, target records, and event timestamps
Monitoring	Whether operators could detect and interrupt unexpected behavior in real time	Logs, alerts, detection events, interruption events, and containment events
Human operations	Whether responsibility, escalation, and stop procedures were clear	Approval and intervention events, assigned owners, escalation records, and recovery actions
Supply chain	Whether a cloud, evaluation, data, or tool provider invalidated an assumed control	Third-party dependencies, provider configuration and version records, and evidence held by the provider

The layers are dependent. A model can recognize uncertainty while a tool has excessive permission. A safeguard can work as configured in the wrong environment. An operator can stop a run yet lack provider records that explain the initial access. A complete trace from one component does not establish a complete incident account.

The proposed intervals set a cadence for notification, not proof of recovery

The draft calls for notice to the directly affected organization as soon as possible, notice within 72 hours to customers with credible exposure, and a confidential initial SAFE report within four business days. It proposes a broader customer advisory within 14 days when warranted. A preliminary factual report would follow within 30 days, subject to security, legal, and investigative constraints. The draft then calls for remediation status at 90 days and weekly machine-readable updates while material risks remain unresolved.

This sequence would make evidence collection begin during containment. The four-business-day report is an initial report, not a final finding. The 30-day report does not end the investigation, and a 90-day status does not prove the remediation works. Meeting a proposed communication point would not prove that harm is contained or the failure cannot recur.

The intervals would not replace supplier duties, coordinated vulnerability disclosure, contracts, regulatory notices, law-enforcement notices, or other legal obligations. Those duties can have different owners and schedules. Our Akrites analysis covers the separate work of coordinating a vulnerability report. SAFE proposes a broader job: learning from an event across organizations and the full operating stack.

One bounded rehearsal can expose missing evidence now

Choose one existing, non-sensitive incident or failed test from a single AI workflow. Use an event that is closed or contained, and do not recreate harmful access. Test whether current records and owners can reconstruct what happened.

For each of the eight questions, ask the current owner to produce the evidence that existed at the time. Use existing prompts, traces, tool records, identity and permission data, configurations, alerts, approval events, recovery records, and supplier information. Do not write the account from memory and then search for supporting records.

Build one timeline from the evidence. Check whether the records identify the same run, versions, workload identity, tool actions, human interventions, environment, and dependencies. Record a gap when evidence is missing, timestamps do not align, an owner is unknown, or a provider holds a fact the team cannot obtain. Do not hide those boundaries in a polished narrative.

Decide which gaps are worth fixing for that workflow. Give priority to missing evidence that would block identification of affected systems, containment, notification, or remediation tests. A low-impact record that is costly to retain can remain a documented limit. The rehearsal supports a local decision about evidence and ownership. It does not establish compliance, certification, conformance, adoption, or production safety.

A successful rehearsal answers the questions for one prior event with the surviving evidence. The same records might not exist during a larger incident, and a supplier might not respond in time. A completed remediation also does not prove the intended business outcome. Fix a material gap and repeat the evidence request before expanding the workflow's access or autonomy.

The proposal does not yet specify how SAFE would operate

The RFC uses firm terms such as “must” for future member duties, but those terms belong to a proposal. The public material does not establish who will operate intake, how membership will be approved, or when a reporting duty could take effect. The repository was created on August 3, and the snapshot records its latest push on August 4. Those dates show an early public process; repository activity does not show adoption.

The proposal does not define a machine-readable report format, the test for “credible exposure,” or how confidential evidence would be secured, retained, accessed, and deleted. It would let affected organizations correct factual errors without veto power over lessons or recommendations. The current text also leaves the dispute process and final verification model unresolved.

The Linux Foundation announcement compares the proposed reporting approach with NASA's Aviation Safety Reporting System. That analogy explains the ambition for confidential learning. It does not provide evidence that SAFE has equivalent governance, legal treatment, participation, or operating maturity.

Teams can use the draft as a demanding set of reconstruction questions while keeping its status clear. The useful result is a supported account of one event and a decision about which missing records or owners to fix. A complete-looking report without connected evidence only hides uncertainty.

Book an AI opportunity assessment to decide whether incident evidence, access controls, operating ownership, supplier boundaries, or a broader workflow redesign should come first.

Sources

• Open Secure AI Alliance, “Shared AI Findings Exchange (SAFE)” draft RFC
• Linux Foundation, “Proposing the SAFE Working Group: An Open Community Effort to Improve AI Security,” August 4, 2026
• Open Secure AI Alliance RFC repository