An AI security coalition needs evidence from the missing layer
The SAFE proposal invites incident learning across the AI stack. Its useful test is whether a review can proceed when a critical counterparty does not participate.
A membership list can tell me who is in a security coalition. It cannot tell me who will supply the evidence when an incident reaches a company outside it.
The Linux Foundation’s August 4 SAFE proposal invites discussion about confidential learning from AI incidents and near misses. It describes reviews across models, safeguards, tools, runtimes and human operations. It is a draft for community input, not a finished mandatory standard.
My test for the proposal would be a case with a missing participant. Can the review describe what is known, identify what evidence is unavailable and still produce a useful recommendation without turning absence into presumed fault?
The stack extends beyond the signatories
An agent incident may involve a model provider, an application builder, a runtime operator and an external service. Those parties hold different pieces of the sequence. A runtime trace may show a tool request without establishing why a permission was granted. A model interaction may show an instruction without proving what the external service actually executed.
The coalition’s composition therefore matters as a coverage question. Which evidence can participants contribute? Which parts require cooperation from someone else? What permissions govern sharing? Those are more useful questions than assuming the presence or absence of a prominent lab reveals where legal liability will land.
I would not describe the alliance as having no agent makers. Its wider ecosystem includes companies that build agent systems as well as defensive infrastructure. Nor can a public list establish why any particular company did not join. Membership is an organisational fact to verify, not a reliable mind-reading device.
The proposal itself calls for neutrality across vendors and for treatment of open and proprietary systems. That is a sensible aspiration. The practical challenge is maintaining that neutrality when the available evidence is uneven.
Rehearse an incomplete incident
For a hypothetical review exercise, give the group a runtime log, a customer report and a partial tool-response record. Withhold one counterparty’s internal telemetry. Ask the reviewers to produce a timeline with explicit gaps and a set of findings graded by the evidence available.
A strong result might establish that a request crossed an unintended boundary while leaving the original permission decision unresolved. That is still actionable. The team can recommend a control at the observed boundary without claiming to know every upstream cause.
I would also inspect what the review publishes. An uncertain interpretation should not become a definitive attribution merely because the report needs a concise summary. A later contribution from the missing party should be able to change the conclusion without erasing the earlier record.
This is a proposed evaluation of an incident-sharing process, not a claim that SAFE has already failed such a test. Its design is open for discussion, and practical access to evidence can be constrained by privacy, security and existing obligations.
The archive’s cross-company incident argument says to arrange cooperation before it is needed. This adds a harder requirement: design the shared review so it remains honest when cooperation is incomplete. No coalition can assume every relevant actor will always be available.
Judge an AI security coalition by how it handles missing evidence, not by how confidently its membership list implies complete coverage.
