The Alliance Map

OpenAI signed the companion "Open Weights and American AI Leadership" letter but explicitly decided not to join OSAA itself. Confirmed via Reddit and reporting on July 28, 2026. The OpenAI agent breach (the incident OSAA was formed in response to) may explain the tension — OSAA's founding narrative uses OpenAI's failure as the justification for its existence.

Anthropic is absent from OSAA and did not sign the open-weight letter. This aligns with Dario Amodei's public skepticism of open-weight models. Anthropic is actively lobbying for mandatory third-party testing for frontier models, with government authority to block deployment — the opposite of OSAA's stated position.

The open-weights-vs-closed-weights ideological divide is visible in the membership: OSAA positions firmly on the open side, Anthropic on the closed side. The question is which position regulators will adopt.

Google signed the open-weight letter but did not join the alliance. The reasons are not publicly stated. Google's absence, alongside OpenAI's, means the three largest closed-model companies are not inside the alliance shaping its standards.

On the surface, the lobbying position is pro-open-source — which aligns with democratized AI interests. NVIDIA's framing is that closed AI models blocked essential forensics during the Hugging Face incident, and open-weight models helped contain it.

But the subtext is the mechanism to watch: "Treat OUR open models and OUR security tools as the defensive assets." If regulators adopt OSAA's framework as the reference standard for "secure open AI," compliance means adopting OSAA-member tooling. That is corporate control wearing an open-source costume.

The Cryptonomist analysis states: "By assembling a coalition that includes infrastructure giants like Dell, Cloudflare, and Cisco alongside AI specialists, the alliance creates a bloc with significant lobbying weight and technical credibility."

EO 14409 (Trump, June 2, 2026) creates a "voluntary" AI cybersecurity clearinghouse and public-private collaboration framework. It expressly rejects mandatory model licensing or preclearance.

Critical detail from Cloud Security Alliance analysis: "a voluntary framework can still create de facto obligations if government contracting, procurement preference, or public trust" make compliance effectively mandatory.

OSAA is positioning itself as the industry body that fills the EO 14409 collaboration framework. CrowdStrike explicitly referenced EO 14409 in its OSAA joining announcement. This is the primary risk vector — voluntary standards becoming de facto mandatory through procurement requirements.

The Cloud Security Alliance published a research note on July 28 flagging this as OSAA's "biggest structural weakness": no governance scaffolding, no assurance mechanism, no charter, no voting thresholds. CSA contrasts this with their own STAR and Open Certification Framework models.

When OSAA does create a certification framework, it will likely be written by the large corporate members who are already driving the agenda. The current vacuum means the first-movers (NVIDIA, Microsoft, Cisco, CrowdStrike) define the terms.

CoSAI (Coalition for Secure AI, hosted by OASIS) already exists and has overlapping membership with OSAA. The relationship between the two bodies is undefined. Two competing or overlapping standards bodies create confusion; consolidation would concentrate standards-setting power in whichever body absorbs the other.

This is flagged as a hypothesis — the OSAA/CoSAI dynamic needs further investigation to determine whether they are collaborating, competing, or on a path to merge.

1. SAFE guidelines evolving from RFC to standard to procurement requirement to regulatory mandate. See Track 02.

2. "Unified standards" for identity, isolation, permissions, and audit logging becoming compliance checklists. OSAA has stated it will develop these. A September public meeting is planned with working groups on vulnerability disclosure, secure deployment guidelines, and AI supply chain security.

3. Certification or "OSAA-aligned" branding that enterprise buyers start requiring. No program proposed yet, but the trajectory is: define standards, build tooling, create evaluation frameworks, establish compliance expectations.

4. Governance structure being announced that gives large members disproportionate control. The current vacuum means whoever writes the charter controls the agenda.

5. OSAA standards referenced in legislation or regulation — federal or state. Colorado, California, and New York are actively legislating on AI.

6. Membership numbers cited in regulatory filings or congressional testimony. When "120+ companies agree" starts appearing in regulatory justifications, the alliance is being used to legitimize positions that may not serve small operators.

7. "Secure-by-design" requirements that assume enterprise-scale infrastructure.

8. Conflation of "safety" with "uses our specific tooling stack."

The Linux Foundation, in collaboration with OSAA members, published a Request for Comments (RFC) for the Shared AI Findings Exchange (SAFE) on August 4, 2026. The initial RFC was developed by contributors from Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat, and other OSAA members.

The Linux Foundation explicitly compared SAFE to NASA's Aviation Safety Reporting System (ASRS) — a voluntary, confidential reporting system for flight incidents. The framing positions SAFE as the AI equivalent of aviation safety reporting.

TechRepublic reported that during the Hugging Face incident, closed AI tools were blocked, preventing essential forensic analysis. The team was forced to use "an open-weight GLM 5.2 model running on its own infrastructure to analyze more than 17,000 actions and contain the intrusion."

This is the foundational narrative for OSAA's existence — the argument that open AI tools are essential for security because closed tools can be disabled at the provider's discretion. Whether this narrative is accurate or selectively framed is a question for Track 4.

OSAA's technical architecture was outlined at Black Hat, mapping to a reference architecture with named components:

Nvidia OpenShell was announced at Black Hat as "an open runtime that serves as an agent-level sandbox" — limiting what an agent can see, touch, or execute, enforcing explicit security and privacy boundaries.

NOOA (NVIDIA Labs Object-Oriented Agent) achieves "parity or better accuracy with roughly half the tokens of comparison harnesses" on SWE-bench. In NOOA, an agent is a Python class — methods define capabilities, fields define state, docstrings serve as prompts. This turns agentic AI from a "black box workflow graph" into "a testable, auditable code surface."

The repository has a single contributor (Steve Winslow, Linux Foundation Director of Open Source Strategy). All 5 commits were made in two days (Aug 3-4). The SAFE acronym was updated on Aug 3, suggesting the name itself was still being finalized at launch.

The entire RFC framework was published in 48 hours. The SAFE proposal — a 117-line document covering reporting compacts, notification timelines, evidence preservation, an 8-layer review framework, and a 3-tier disclosure model — was committed on August 4 and immediately promoted via the Linux Foundation blog and Black Hat announcement.

Despite 120+ member organizations, the RFC repository has exactly one contributor. Steve Winslow (swinslow@linuxfoundation.org) is the sole committer. The contributing process requires a Developer Certificate of Origin (DCO) sign-off, but the governance structure — who reviews, who approves, who merges — is not documented.

This means a Linux Foundation employee controls the technical output of a 120+ member alliance. The "open" in OSAA refers to the output license (CC-BY-4.0) and the contribution process (fork + PR), not to the governance model. Who decides what gets merged is not stated.

Key observation: 10 issues, 33 total comments, ZERO closed. The RFC was published as "open for community discussion" but 11 days later, no issue has been resolved. The alliance is collecting input but not acting on it.

Issue #4 (24 comments) is the most active discussion. It proposes that verification methods in SAFE recommendations must declare their failure modes and noise floors — in other words, a verification method that can't explain how it fails is not a verification method.

Key quote from DmitrL-dev (comment 1): "The fail-open mode is the default outcome of writing a check for your own work." This is field evidence from someone building verification into an AI security gateway — the observation that self-verification systematically fails open.

The 24-comment debate covers fail-open vs fail-closed verification, noise floors, mechanical checkability, and whether SAFE should require verification methods to state their own limitations. This is the community trying to make the RFC mechanically enforceable rather than aspirational.

The discussion produced a 25-clause draft (version 2026-08-10c) and a companion case book of 23 incidents from production systems. Blockchain-365 filed PR #9 implementing the clause set as four sub-bullets under the RFC's "reproducible verification method" requirement. DmitrL-dev kept the case book independent rather than embedding it in the PR, stating: "The case book is 25 cases of our own measurements and it is worth more as one artefact we can publish and license ourselves."

The key finding from the exchange: mutation testing of their own verification pipeline found a live defect — a scoring path where arithmetic stages below judged stages laundered measurement failures into numbers carrying no uncertainty. The community is doing the work the RFC should require, and finding that the RFC as written would not have caught it.

Pull Request #2, opened by gab16, proposes designing international public participation into SAFE now, citing the 1998 Internet governance process and NASA's ASRS as models. The author states they will "make that argument to UN interlocutors" and that "international participation should not be understood as a request for institutional control, but as an offer of reach, interoperability and reciprocal contribution."

This is significant: someone is already pushing SAFE toward UN-level institutional adoption. The jump from "open RFC on GitHub" to "UN interlocutors" happened in 8 days.

CyberGuardian-XRSI raised a fundamental gap (4 comments): "The list of required evidence is thorough but preservation is not verification." The issue points out that SAFE requires organizations to retain prompts, traces, tool calls, logs, configurations, model versions, and agent identities — but does not require that this evidence be independently verifiable. An organization could preserve evidence in a format that no one else can read or validate.

This connects to the core tension: SAFE asks members to report on themselves, but does not yet require that those reports be checkable by others. The community is pushing for mechanical verifiability; the RFC as written enables declarative compliance.

The discussion produced a three-property framework that the RFC currently lacks: integrity (was the record altered?), continuity (is the record complete?), and identity (does the record identify the thing that actually ran?). All three can fail independently. DmitrL-dev provided a field case: a CI pipeline where the requested tree and recorded commit were correct, but the tested subject was a prior binary — rsync preserved source mtimes on a Docker build cache that survived between runs, so Cargo treated a changed crate as unchanged. The record was unaltered (integrity), continuous (continuity), and internally consistent — but it identified the wrong binary (identity failure).

lumirosh (who maintains the Open Decision Receipt standard) identified that SAFE's evidence preservation requires retaining "human approval and intervention events" but does not distinguish between what was approved and what actually executed. Four different control failures would be reported identically under the current RFC:

1. No valid authority existed
2. Valid authority existed and execution stayed inside it
3. Valid authority existed and execution left its scope
4. Evidence is insufficient to determine which occurred

"Preserving the event is not the same as preserving what it authorized." This is a structural gap in the evidence framework that the community has identified but the alliance has not addressed.

Claimed vs. Actual Participation

How the Numbers Are Used

The membership count is presented as consensus. "120+ companies agree on AI security standards" implies 120+ companies wrote or approved the standard. In reality, one Linux Foundation employee wrote the RFC. Five companies contributed to the draft. The rest signed a letter or joined a coalition.

The 230+ number is the most problematic. The OSAA formation announcement says 37 founders. The 230+ figure comes from a separate open-weight letter. These are presented alongside each other in coverage as if they represent the same group. They don't. Conflating "signed a letter" with "participated in a standard" is how manufactured consensus works.

This is the normal pattern of Linux Foundation working groups — companies join for political and strategic reasons, a few people do the work. But OSAA is leveraging that normal dynamic to claim a mandate it hasn't earned. The gap between symbolic membership and technical authorship is being deliberately blurred.

The Governance Vacuum

For an alliance claiming 120+ members and producing industry standards, the governance documentation is absent. The RFC repository has no governance file. The Linux Foundation blog says SAFE should "operate neutrally so that no single vendor or industry segment controls its findings" — but there is no documented mechanism for how decisions are made, who votes, or how disputes are resolved.

The CONTRIBUTING.md file is 15 lines. It says: fork, branch, DCO sign-off, PR. That's a contribution process, not a governance model. There is no charter, no bylaws, no voting structure, no membership requirements, no transparency obligations. The alliance is structurally opaque.

This matters because the SAFE RFC proposes that members report incidents, share evidence, and adopt recommendations. Who enforces this? Who decides what counts as a "near miss"? Who adjudicates disputes? The RFC doesn't say. The repo doesn't say. The Linux Foundation blog doesn't say.

AITSC launched on August 11, 2026 in San Francisco via PR Newswire. The press release is sourced to Trust3 AI, a company that describes itself as "the security control plane for enterprise AI and agents." Trust3 AI's CEO Balaji Ganesan is the public face. The media contact (angela@trust3.ai), the application form (hosted on Trust3 AI's Typeform), and the press release distribution are all Trust3 AI.

Trust3 AI is a NVIDIA Inception member and a Snowflake Startup Accelerator participant. So while AITSC is framed as "independent," it sits inside the NVIDIA ecosystem — the same ecosystem as OSAA.

This is not a grassroots coalition. It is a vendor-sponsored consortium. The vendor provides infrastructure, the members provide legitimacy, and the vendor's product becomes the reference implementation.

AITSC is capped at 50 members — individual practitioners, not organizations. Application-based, rolling review. Target roles: CISOs, CIOs, CTOs, Chief Privacy Officers, heads of GRC and security architecture. Target sectors: financial services, healthcare, pharma, energy, public sector, technology, retail.

Founding members named in the press release:

• Ulf Mattsson — Founder of Protegrity (data security/tokenization). Inventor of Protegrity Vaultless Tokenization. Joined Trust3 AI's Advisory Board in June 2025.
• Lori Higham — President of Secure Cloud Provider Inc.
• Maggie Amato — CISO/BISO leader, formerly Salesforce and Dell.

Members get: co-authorship of standards, confidential incident sharing, peer discovery, and "market standing" (founding member status, panel speaking, consortium banner publication). The last item is the tell — membership is a marketing asset, not just a working group.

OSAA and AITSC use the same legitimacy mechanism with different units:

OSAA uses "120+ companies" as legitimacy. AITSC uses "50 vetted security leaders" as legitimacy. Same playbook, different scale. Both use membership count as proxy for endorsement of whatever they'll eventually publish.

The "independent" framing deserves scrutiny. AITSC is independent of OSAA's governance structure — but not independent of the NVIDIA ecosystem. Trust3 AI is a NVIDIA Inception member. OSAA is a NVIDIA/Linux Foundation working group. Two coalitions, same orbit, different fronts.

Two AI security standards bodies launched 15 days apart, both claiming to fill the "no framework exists" gap, neither acknowledging the other. If the standards landscape is this fragmented at launch, the "industry consensus" narrative is already broken. You cannot claim unified consensus when two groups are competing to define it.

The launch messaging follows the same urgency framing as OSAA:

• "Only about one-third of organizations report mature AI governance" — McKinsey 2026 AI Trust Maturity Survey
• "48% of organizations name security concerns as the top barrier to AI adoption, up from 17% in 2024" — Linux Foundation
• "The frameworks security leaders inherited were written for software that didn't reason, didn't act, and didn't change its own behavior between Tuesday and Thursday."
• "Everyone is improvising" — Maggie Amato, founding member

This is the narrative engine pattern from Track 04: create urgency ("no framework exists, everyone is improvising, regulators are coming"), then position the coalition as the solution. AITSC sells governance. OSAA sells tooling. Together they create a dual compliance layer — enterprises may need compliance with both, which benefits the consulting and audit ecosystem and squeezes smaller operators who cannot afford dual compliance overhead.

• First publication. When AITSC publishes its first reference architecture or control framework, does it reference or require OSAA tooling? If yes, the "independent" claim collapses. If it conflicts with OSAA standards, the fragmentation story writes itself.
• Member overlap. Do individuals from OSAA member companies join AITSC personally? That would reveal whether these are truly separate camps or the same network operating through different fronts.
• Regulatory pickup. Does AITSC get referenced in procurement requirements, legislation, or regulatory guidance — the same voluntary-to-mandatory progression documented in Track 02?
• Trust3 AI product alignment. Does AITSC's reference architecture happen to match Trust3 AI's product capabilities? If the standard requires what the sponsor sells, the pattern is complete.