Thirty-Seven Logos Are Not a Security Program

The launch post for the Open Secure AI Alliance names 37 companies. It ends with a link to a contact form. I went looking for the part in between: the rules, repositories, and people responsible for turning those names into shared security work.

NVIDIA announced the alliance on July 27 with a strong argument: defenders should be able to inspect, adapt, and run capable AI systems on infrastructure they control. The coalition includes cloud providers, security vendors, model developers, enterprise-software companies, and open-source foundations. It says members will develop and share an open defense stack for agents, including identity, isolation, safe model formats, scanning, coding workflows, harnesses, and evaluations. Nextgov independently reported that the group has 37 members and intends to advocate for continued access to open AI models.

I agree with the premise. I am less ready to applaud the organization.

The incident made the case

The alliance points to Hugging Face’s July 16 security disclosure. An autonomous agent framework exploited two code-execution paths in a dataset-processing pipeline, reached node-level access, collected credentials, and moved across internal clusters. Hugging Face recorded more than 17,000 attacker actions.

During the response, commercial model APIs blocked forensic prompts containing real exploit payloads and command-and-control artifacts. Hugging Face moved the analysis to the open-weight GLM 5.2 model on its own infrastructure. That kept sensitive incident data inside its environment and let responders perform work that hosted safety filters had mistaken for an attack.

This is unusually good evidence for local model access. It does not prove that every frontier model should be released without conditions. It proves that a defender cannot make an external provider’s policy boundary, availability, or data-handling terms the only route to understanding an intrusion. Incident response happens at an ugly edge where benign and malicious commands look identical without context. A provider is allowed to be cautious about that ambiguity. A security team is allowed to need a tool that still works.

The strongest argument against open frontier systems is also real. Releasable capabilities do not distinguish defenders from attackers. Weights can be modified, safeguards can be removed, and capable systems can lower the labor required to search for vulnerable software. Keeping the most dangerous capabilities behind monitored services can add friction and provide a place to enforce policy.

But secrecy is a control, not a security architecture. Attackers can use stolen accounts, weaker local models, purpose-built tools, or the same closed services until a classifier notices. Meanwhile, defenders may need to process credentials, malware, and customer data that should never be uploaded to someone else’s API. I do not want policy to treat local execution as suspicious by default. I want it paired with isolation, workload identity, auditable actions, safe artifact formats, and coordinated disclosure.

Those are exactly the layers the alliance says it cares about. I want to see whether it will build them together or place a new banner over work its members were already doing.

Show me the machinery

There is real code attached to the launch. NVIDIA released NOOA under Apache 2.0, with source, tests, contribution instructions, a security policy, evaluation material, and an inspectable agent harness. Hugging Face’s Safetensors repository has public governance and maintainers around a format designed to load model weights without pickle-style code execution. SPIFFE and SPIRE already provide standards and tooling for cryptographic workload identity.

I would rather see those artifacts than another declaration that openness is important. People can fork them, test them, criticize them, and repair them. That is already more useful than a member list.

The alliance’s announcement does not yet give me a public charter, decision process, technical roadmap, project directory, contribution path, or definition of what it means by “open.” Maybe those pieces are coming. Launch day is early. Still, the missing details matter because the word has become slippery around AI.

The Open Source Initiative’s Open Source AI Definition asks for the freedoms to use, study, modify, and share a system. For machine-learning systems, it also requires code, parameters, and enough information about training data for a skilled person to build a substantially equivalent system. Many systems marketed as open provide downloadable weights without all of that. Open weights can still be enormously useful for private deployment and incident response, but they are not the same promise. An alliance that wants to influence regulators should label that distinction instead of letting every member bring its preferred meaning of “open.”

There is a nearby example of the specificity I want. The Linux Foundation’s Akrites initiative, which the alliance cites as prior leadership, names a shared Security Incident Response Team, a standardized coordinated-vulnerability-disclosure process, confidentiality rules, upstream remediation, a maintainer-of-last-resort role, and the standards it expects to use. Those commitments can fail, but at least outsiders can tell what failure would look like.

The Open Secure AI Alliance should publish a similarly testable ledger. It should identify the projects it governs, the people who accept vulnerability reports, and the repositories where outside maintainers can earn authority. Shared threat models and evaluations should be easy to find. Contributions should distinguish new funding and engineering time from projects that existed before the alliance. If a member quietly abandons its pledge, the public record should show that too.

A coalition of large vendors can do work that a loose volunteer community cannot. It can fund long security reviews, maintain boring infrastructure, coordinate disclosure across products, and put engineers on fixes after the launch attention has moved elsewhere. The companies also benefit from shaping regulation, reducing dependence on competitors, and expanding demand for hardware and services. That does not invalidate the work. It means the public should judge the coalition by its output rather than its member count.

I want this alliance to succeed because its central claim is right: defenders need tools they can inspect and control. The first release gives me several useful artifacts and a convincing incident. What it has not given me yet is a public institution.

Thirty-seven logos make a formidable press image. I will trust the alliance more when someone outside those companies can find its repository, read its rules, report a flaw, and watch the patch land.