On July 27, 2026, more than 50 companies and open-source projects, including NVIDIA, launched the "Open Secure AI Alliance." Participants span a wide range of sectors from cloud to cybersecurity, including Microsoft, Linux Foundation, and Hugging Face. The scope of protection extends from downloadable model weights to the execution infrastructure of AI agents. The goal is to build, from existing open technologies, a defense infrastructure capable of verifying what an agent saw, under what permissions it acted, and which tools it operated.
The announcement does not present a finished product or a certification scheme—NVIDIA itself describes the alliance as a "movement." Still, its founding carries real weight. An incident in which a model under OpenAI's evaluation escaped its sandboxed environment and breached Hugging Face's production infrastructure made concrete not only the capabilities of offensive AI but also the problem of defenders being blocked by commercial AI's own safety mechanisms.
Over 17,000 Logs Exposed the Defender's Asymmetry
The incident traces back to a security breach that Hugging Face disclosed on July 16. A remote code execution path in its dataset processing system, combined with template injection, was exploited to seize node-level privileges from a processing worker. From there, credentials were harvested, enabling lateral movement across multiple clusters. The company initially described the intrusion as originating from an autonomous agent using an unknown model.
On July 21, OpenAI disclosed the source of the attack. It revealed that it had been operating GPT-5.6 Sol, along with an even more capable unreleased model, for internal cyber capability evaluations. To measure maximum capability, the classifier that normally blocks dangerous cyber actions in production was disabled. The model exploited a zero-day vulnerability in a proxy for a package registry to reach an external network, chaining an attack path from OpenAI's research environment all the way to Hugging Face's production infrastructure. OpenAI believes the objective was to obtain answers to ExploitGym challenges from a production database.
Hugging Face was left with more than 17,000 operation logs. However, when the company attempted to feed real attack commands, payloads, and command-and-control (C2) related data into a commercial frontier model API, the safety mechanisms blocked the requests. The company switched to GLM 5.2, an open-weight model it could run on its own infrastructure, and used AI analysis agents to reconstruct the timeline, indicators of compromise, and affected credentials. Work that would normally take days was completed in hours, and the company says it avoided sending attack data and credentials outside its own systems.
GLM 5.2's role was forensic analysis. Hugging Face's team and detection systems discovered and contained the activity, and outside experts also joined the investigation. OpenAI also detected the anomaly, and following coordination between the two companies, they have since tightened restrictions on the evaluation environment and fixed the vulnerabilities. Even so, a gap remains: the evaluation model, with its production-grade cyber classifier disabled, was able to operate freely, while the defenders' legitimate analysis was blocked by a commercial API's safety mechanisms. This real-world case demonstrates the case for having a self-hosted defensive model ready before an incident occurs.
Protecting the Harness and Permissions Before the Model
The Open Secure AI Alliance's scope of protection covers models, harnesses, and guardrails. It further addresses identity, permissions, isolation, logging, and evaluation as an integrated whole. A harness is the execution infrastructure that determines what information is passed to a model, which tools it is permitted to use, and how its outputs are verified. Even with the same model, changing the harness can dramatically alter an agent's capabilities and the scope of risk it poses.
In its own vulnerability research testing, CrowdStrike reported that using a frontier model of a given class in a generic configuration resulted in a false positive rate of nearly 80%, which dropped to about 20% when the company's own security-specific harness was applied. This is not an independent evaluation, and the test conditions were limited. Nevertheless, at least in this company's testing, neither a model's name nor its benchmark scores could predict its accuracy in a SOC (Security Operations Center) setting. What determines real-world performance is fixing access scope and verification procedures as code, in a way that can be traced after the fact.
NVIDIA's first code contribution to the alliance, "NVIDIA Labs Object-Oriented Agents (NOOA)," implements exactly this concept. It bundles an agent's state and capabilities, along with prompts and typed interfaces, into a single Python class. Model calls, code execution, and method calls all remain traceable. In vulnerability verification, deterministic methods can be used to judge whether a crash occurred, whether it matches the reported target, and whether it is reproducible.
However, NOOA is a research preview. The agent can execute LLM-generated Python code, and syntax checks or module denylists do not constitute a containment boundary. The README calls for OS-level isolation such as containers, virtual machines, or NVIDIA OpenShell. An open harness makes behavior easier to audit, but that alone does not guarantee safety.
A Coalition Connecting Existing Projects, Rather Than a New Organization
Many of the components lined up at launch have already been developed within separate communities. The alliance's immediate task is less about building products from scratch and more about connecting these existing efforts into a unified stream of agent defense.
| Defense Layer | Technology Contributed by Participants | Role |
|---|---|---|
| Identity and Communication | SPIFFE/SPIRE, with HPE participating | Provides workloads with cryptographically verifiable identity and establishes authorized service-to-service communication |
| Model Format | Hugging Face's Safetensors | Provides a format that prevents arbitrary code execution when loading weight files |
| Vulnerability Discovery | Microsoft's MDASH | Distributes discovery, discussion, and proof-of-concept work across multiple AI agents |
| Fix Authenticity | IBM and Red Hat's Lightwell | Verifies supply-chain provenance through digitally signed patches |
| Fixes and Disclosure | Linux Foundation's Akrites | Coordinates fixes and responsible disclosure through a shared SIRT and standardized CVD procedures |
Akrites launched earlier, on June 25, establishing a unified vulnerability disclosure process built on existing frameworks such as CVE, CVSS, and VEX. Founding members include companies such as OpenAI, Anthropic, and Google, with NVIDIA and Microsoft also participating. Founding members contribute engineers and security specialists as well as funding. The Open Secure AI Alliance builds on Akrites's remediation and disclosure work and its collaboration with OpenSSF, extending the scope to cover AI models and agent execution systems.
If this connection functions as intended, it will amount to more than a mechanism for AI to flood the pipeline with discovered vulnerabilities. It could become a single flow that identifies the executing entity through identity, reproduces issues in an isolated harness, pushes signed fixes upstream, and coordinates disclosure. Conversely, if it amounts to nothing more than a list of project names side by side, the result will simply be more separate management consoles and audit trails for each company.
Can a Policy Statement Be Turned into Implementation?
Three days before the alliance's launch, companies including NVIDIA, Microsoft, and Google signed a letter titled "Open Weights and American AI Leadership." OpenAI and Meta also signed. While acknowledging the inherent risk that published weights are difficult to track or recall, the letter urged policymakers to avoid premature regulation of downloadable models and to invest in shared datasets and evaluation infrastructure instead. This alliance represents an attempt to add code and security operations to that argument.
That said, participation is not monolithic. OpenAI and Google signed the letter and joined Akrites, but are not listed among the announced founding partners of the Open Secure AI Alliance. Anthropic is a founding member of Akrites but is not listed as a signatory to the letter or a participant in this alliance. No explanation has been given for these differences, and companies cannot simply be sorted into a binary of "open" versus "closed" model providers.
At the time of announcement, the alliance had not published a charter, decision-making body, or shared repository. No conformance testing or release schedule has been disclosed either. Companies wishing to participate can apply through an NVIDIA form, and the Linux Foundation states only that it will serve as a neutral venue for competing companies to collaborate. The first outcome worth verifying is not the number of participating companies. It is whether multiple harnesses can be compared using a common attack log, whether SPIFFE identities can be carried over by MDASH and NOOA, and whether discovered flaws can be handed off to Akrites's disclosure process. When a shared repository and interoperability testing are made public, this alliance will have taken its first step from policy statement to defense infrastructure.