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.

On September 8, 2026, NVIDIA sent a marketing email to its subscriber list with a dedicated section titled "Continue With the Open Secure AI Alliance." The email includes three explicit calls to action: fill out a prospective member form, contribute to SAFE guidelines, and "Help Celebrate on Social" across LinkedIn, X, Bluesky, and Mastodon.

The email states: "NVIDIA is proud to support a community that shares practical AI security work in the open. The Alliance's new home at the Linux Foundation will help members collaborate, learn from one another, and help shape what comes next."

The same email promotes Fal.Con 2026 — CrowdStrike's annual conference, co-keynoted by Jensen Huang and George Kurtz — as an event where "Open Secure AI Alliance Connects at Fal.Con" and "members came together in person to share insights and advance the future of AI security."

This is NVIDIA actively funneling its own marketing audience into OSAA membership. The alliance is not a neutral standards body that happens to have NVIDIA as a member. NVIDIA is the recruiting engine, the conference platform, and the marketing channel. The membership growth narrative — 120+ organizations in eight days — now has a visible mechanism behind it.

At Fal.Con, NVIDIA and CrowdStrike announced SafeMind — an agentic cybersecurity system built on NVIDIA Nemotron "open models," post-trained with CrowdStrike's proprietary threat data and paired with CrowdStrike's proprietary harnesses on the Falcon platform. Jensen Huang: "Nemotron was created for precisely that. Completely free. Incredibly fast."

The model is open. The useful version is not. SafeMind's edge is not the model — it's "your decade and a half of security data that we can train on" (Huang's words), the proprietary agent harnesses, the Falcon platform, and NVIDIA's compute stack. CrowdStrike tested it against a "digital twin of NVIDIA's own accelerated computing infrastructure." The full stack runs NVIDIA chips → Nemotron models → CrowdStrike harnesses → Falcon platform. There is no local path in.

George Kurtz drew the line explicitly: "This isn't a copilot baked into someone else's intelligence. It's not a chatbot with a security skin. It is a frontier-class model built and trained by CrowdStrike on our data in partnership with NVIDIA." The subtext: real AI defense requires owning the model, owning the data, owning the harness. Small operators don't own any of that.

The "open model" framing is the same pattern documented in Track 03: the base is free, but the infrastructure that makes it useful is proprietary, vendor-controlled, and priced at enterprise scale. SafeMind is the infrastructure play as a shipping product — and it's being co-marketed with OSAA membership in the same email.

On September 14, 2026 — six days after the first email — NVIDIA sent a second OSAA email, this time a dedicated onboarding follow-up. The email states: "Please complete its membership form, even if you previously applied through NVIDIA." That sentence confirms what the first email implied: NVIDIA was collecting membership applications directly, not just pointing people to the Linux Foundation. NVIDIA was the original gate. The Linux Foundation is the processor.

The email names two onboarding handlers — Mike Woster and Stephano Cetola — assigned to "expedite all onboarding this week." The urgency framing ("this week") converts interest into action before the prospective member has time to ask what they're joining. The three-step funnel is explicit: (1) submit the LF membership form, (2) contribute to SAFE on GitHub, (3) visit the Alliance website. New members are channeled straight into SAFE RFC participation — the framework the community is writing for free that the alliance will eventually adopt.

The timing matters. Second email in six days. Right after the existential risk narrative push went mainstream — Anthropic researcher resignation with 100 million views, UN calling for red lines, California lawmakers demanding emergency legislation (see Track 04). The fear creates the urgency. The alliance provides the "responsible" answer. The onboarding email converts that urgency into memberships. The mechanism is running.

On September 14, 2026, Mike Woster — named in the NVIDIA onboarding email as an OSAA handler — emailed prospective members directly from the Linux Foundation. His title: Chief Revenue Officer. The funnel is now confirmed end to end: NVIDIA recruits, the Linux Foundation processes, the CRO closes.

The email reveals three things the alliance has not advertised:

• LF membership is a prerequisite for OSAA. "If your company is not yet a member of the Linux Foundation (a prereq for joining the Open Secure AI Alliance)." The "open" alliance requires membership in a specific foundation first. You cannot join OSAA without joining the LF. That is not open. That is gated.
• Free until January 1, 2028, then fees. "There will be no fee associated with the Linux Foundation membership prerequisite until January 1, 2028." Classic customer acquisition: get organizations in free during the growth phase, lock them into the ecosystem, then charge. Run by the CRO. The "open community" has a billing date.
• SAFE RFC public comment closes September 21. "The Alliance is currently accepting feedback on its RFC through September 21." Seven days from this email. After that, the window for public input closes and the RFC moves to its next phase — the phase where the alliance, not the community, decides what gets incorporated.

Woster also noted that "NVIDIA will also be discussing collective AI defense at Open Source Summit Europe in Prague on October 7" — another NVIDIA conference appearance promoting the alliance, same pattern as Fal.Con.

The sequence is now visible in full: NVIDIA's CEO announces the alliance at Black Hat. NVIDIA's marketing email recruits members. NVIDIA's onboarding email redirects to the Linux Foundation. The Linux Foundation's Chief Revenue Officer emails prospective members with a free-until-2028 offer and a comment deadline. The "open community" is a sales funnel with a billing date and a CRO.

The OSAA Directed Fund Participation Agreement and Charter (Exhibit B, effective September 1, 2026) were obtained through the enrollment process. The governance structure is documented here for the first time publicly:

• Five founding members control everything. "The Steering Committee voting members will consist of one representative appointed by each of the five founding members." The five founders are not named in the charter. They appoint the Steering Committee. The Steering Committee approves the budget, creates working groups, adopts policies, elects officers, and amends the charter. General Members — the tier most organizations join — have zero seats. No vote on governance. No vote on budget. No vote on anything.
• Steering Committee meetings are private. "Steering Committee meetings will be limited to the Steering Committee representatives, invited guests and LF staff." General Members cannot attend. The five founders make decisions behind closed doors. The 120+ member organizations are not in the room.
• The charter can be amended without your vote. "This Charter may be amended by a two-thirds vote of the entire Steering Committee, subject to approval by The Linux Foundation." That's 4 of 5 founders. They can change the rules after you join. You are bound by the changes. Your only recourse is to resign — and you still owe fees for the current period.
• Regressive fee structure. Starting January 1, 2028: up to 1,999 employees pays $5,000/year. 2,000-4,999 pays $10,000. 5,000+ pays $15,000. A 1-person company pays $5,000. A 50,000-person company pays $15,000. That is 3x the fee for 50,000x the headcount. Small organizations pay proportionally far more than large ones. On top of that, LF Silver Membership is required: $5,000 for under 100 employees. A 1-person LLC pays $10,000/year total starting 2028. A Fortune 500 company pays $20,000.
• Auto-renewal trap. Membership renews automatically on January 1 each year. To stop it, you must give written notice of non-renewal by December 1. Miss that deadline and you owe another year. Fees are non-refundable: "In no event will fees be refunded, upon a Member's resignation or otherwise."
• Irrevocable, binding obligation. "Execution of this Agreement creates an irrevocable, binding obligation for the member company to make the payments provided for and to otherwise perform in accordance with its terms." This is not a signup. It is a contract.
• The LF takes a cut. A General & Administrative fee of 9% of the first $1,000,000 raised and 6% above that goes to the Linux Foundation for "membership records, finance, accounting, and human resources operations." The neutral host is not free.
• Working groups are member-only by default. "Participation as a member of a Working Group is, by default, limited to Members only, but the Steering Committee may decide to open it to non-Members." The SAFE RFC work happens in working groups. The Steering Committee can close them to non-members at any time.

The "open community" framing collides with the governance document: five unnamed founders, private meetings, no member votes, auto-renewal, non-refundable fees, and the ability to amend the rules after you join. The 120+ member organizations are not partners in governance. They are revenue.