Operational notes Observatory

Open Secure AI Alliance: what is a supplier’s membership actually worth?

7 min read

Breakwater of stacked concrete blocks facing the open sea, with a headland on the horizon, in black and white
A barrier is judged by the blocks that make it up and the gaps that remain, not by how many hands helped lay them.

On 27 July 2026 NVIDIA announced the Open Secure AI Alliance, to “build and share open tools that promote responsible use of and trust in AI”. The technical core sits in one sentence of the statement: “contributors are building an open defense stack for agents — from identity and isolation to safe model formats, multi-model scanning and secure coding workflows”. That is: identity, isolation, safe weight formats, multi-model scanning, protected development.

The announcement lands six days after the intrusion carried out by an agent against Hugging Face became public, and just after the response from the US Congress. We have covered that incident. What matters here is something else: who is in, and who is not.

The line-up

In the NVIDIA blog post I counted 37 organisations listed as inaugural partners: NVIDIA, Adobe, Cadence, Capital One, Cisco, Cloudera, Cloudflare, Cognition, CrowdStrike, Databricks, Dell Technologies, DoorDash, Elastic, HPE, Hugging Face, IBM, LangChain, the Linux Foundation, Microsoft, NAVER, NetApp, Nous Research, OpenClaw, Palantir, Palo Alto Networks, Red Hat, Reflection AI, Salesforce, SAP, ServiceNow, Siemens, SK Telecom, Snowflake, SpacexAI, Synopsys, Thinking Machines Lab, TrendAI. The list is introduced by “including” and may not be exhaustive; Infosecurity Magazine speaks of “nearly 40” companies.

Look at who they are: infrastructure, security, cloud, enterprise software, open source foundations. The organisations that host agents, run them and must defend them. Plus last week’s victim.

Missing are the builders of the most widely used frontier models. Google, Anthropic and OpenAI do not appear on the initial list of signatories, as Infosecurity Magazine noted on 28 July. None of the three has publicly stated why it is absent. Record it as a fact and stop there: an absence is not a refusal, and ascribing an unexpressed position to anyone would be a trial of intentions.

The point is a CISO’s, not ours. Kevin Kirkwood, CISO at Exabeam, told the same publication: “The major frontier model developers need to be at the table, and the industry needs agreed rules for liability when an agent exceeds scope.” Better tools help defenders; better governance, he adds, “keeps the defensive tools from becoming part of the problem”.

An alliance is not a regulator

I looked for three things, in the blog post and the form it links to: admission criteria, verification mechanisms, consequences for a member that fails to deliver. There are none. No stated timelines, no binding commitments, no audit, no published charter. Contributions are voluntary, not obligations. Nor is there an official alliance website: the only entry point is a contact form on NVIDIA’s domain, asking for job title, company size, a logo in SVG or PNG and the contributions already made to the community.

The announcement says the initiative “builds on the leadership” of the Linux Foundation’s Akrites initiative and OpenSSF community work. The Linux Foundation is among the inaugural partners, but nothing states that the alliance is hosted by it: this is inspiration, not hosting. The difference matters, because a hosting foundation brings a charter, governance and rules of admission. Here there are none.

The practical consequence. “Our supplier is a member of the Open Secure AI Alliance” is not a guarantee you can put in a contract or show to a supervisory authority: no body exists that could declare a member in breach, because there is nothing to breach.

What is usable instead

The individual technical artefacts, because they are concrete and can be demanded in writing. From the announcement:

  • HPE contributes to SPIFFE/SPIRE: zero-trust identity that cryptographically verifies agents and services, so that only authorised workloads reach enterprise resources.
  • Hugging Face has offered Safetensors to the PyTorch Foundation: a weight storage format with a guarantee of no remote code execution on load.
  • IBM and Red Hat, with Lightwell, extend open source supply chain security through digitally signed patches.
  • Microsoft brings MDASH, a multi-model agentic scanning harness that orchestrates specialised agents to discover and prove exploitable bugs.
  • NVIDIA contributes open models, weights and data plus agent harness research, and the NOOA project (NVIDIA Labs Object-Oriented Agent), on GitHub, to make agent behaviour easier to test, trace, audit and govern.
  • SpacexAI has open sourced the Grok Build coding agent and says it plans to open the weights of the Grok line.

Turn them into clauses. Cryptographic identity for every agent, not shared credentials. Weight formats that execute no code on load. Patches with a signing chain verifiable back to source. Model scanning before deployment, not after. Isolation and a limited blast radius. The contract rule applies here too: a use limit that is neither written nor verifiable does not exist. Do not buy the alliance: buy the requirements, and ask for the proof.

One technical caveat. Gene Moody, field CTO at Action1, observes that once a model runs in isolation its safety controls “become just another layer of software” and “can be modified, removed, retrained, or replaced altogether”. That holds for any open source tool. The guarantee lies not in the tool’s existence but in the version running on your premises and in whoever maintains it. A name on a list of projects says nothing about which version you have in production.

The second-order consequence

It is a recurring pattern. After an incident, the industry produces an open defence stack. The tools are real and useful, but they shift the work — and with the work, the risk — onto whoever installs the system and keeps it running. Whoever puts an agent into service remains the party that answers for what it does, and the model supplier’s absence from the common defensive effort does not lift that: an agent’s permissions are a design decision, not a configuration setting.

Hence the question for a supplier that cites its membership: what happens when that tool is not enough? That is where you learn whether an obligation exists or only a contribution. John Strand, owner of Black Hills Information Security, observes that many of these initiatives are “trying to establish industry standards before governments step in with legislation or regulation”, and that “whether those efforts are enough remains to be seen”.

The perimeter as a fact, not a promise

One detail in the statement is worth the rest of it, and it is NVIDIA telling it: during the incident the closed AI tools, unable to tell an attacker from a defender, blocked the forensic analysis, and Hugging Face ran an open-weight model on its own infrastructure to analyse more than 17,000 actions and contain the intrusion. It is an interested account — NVIDIA argues for open models — but the fact holds: the defenders had to work on their own premises.

An agent’s blast radius can be limited in two ways. By configuration, which depends on who wrote it and which version of the tool is installed that day. Or by construction: an agent running in a closed, dedicated environment has a finite list of credentials it can use, networks it can reach and systems it can touch — written down, checkable, and showable to an auditor. No alliance is needed to obtain it.

We always deliver in two modes, never only one: on-premise in the client’s environment, or CSIDIA dedicated cloud — an environment reserved for the single client, access over a dedicated VPN, data centre in Italy, premises staffed directly by us. In both cases the perimeter is a verifiable architectural choice: it is how we work.

Want the written list of what an agent will be able to touch in your systems, before you install it? Let’s talk.

Sources