37 Companies Join Forces to Open-Source AI Security Defenses

37 Companies Join Forces to Make AI Security Tools Public Infrastructure

On July 27, 2026, 37 companies and organizations—including NVIDIA, Microsoft, IBM, Adobe, Cisco, Cloudflare, Hugging Face, and the Linux Foundation—announced the formation of the Open Secure AI Alliance. The alliance plans to build and share open-source tools to help enterprises and security teams deploy AI with greater transparency and control, while promoting coordinated vulnerability disclosure and remediation.

This is not another policy forum debating whether “AI will destroy humanity.” At least based on the information released so far, it is more focused on practical engineering concerns: where models come from, whether runtime frameworks can be trusted, whether supply chains have been poisoned, whether inference data could leak, and whether security teams can deploy protections within their own infrastructure.

The alliance’s position is clear: AI security cannot rely entirely on black-box services provided by a handful of model vendors. The world needs both proprietary frontier models and open models and runtime frameworks. The former push the upper limits of capability, while the latter give defenders room to inspect, modify, deploy locally, and respond quickly.

A Broad Membership Spanning Multiple Layers of the AI Technology Stack

The 37 founding members announced are:

• Adobe
• Cadence
• Capital One
• Cisco
• Cloudera
• Cloudflare
• Cognition
• CrowdStrike
• Databricks
• Dell Technologies
• DoorDash
• Elastic
• HPE
• Hugging Face
• IBM
• LangChain
• Linux Foundation
• Microsoft
• NAVER
• NetApp
• Nous Research
• NVIDIA
• OpenClaw
• Palantir
• Palo Alto Networks
• Red Hat
• Reflection AI
• Salesforce
• SAP
• ServiceNow
• Siemens
• SK Telecom
• Snowflake
• SpaceXAI
• Synopsys
• Thinking Machines Lab
• TrendAI

The significance of the list is not merely the number of companies involved. Together, these members cover nearly every major stage of AI application development, from hardware and cloud platforms to model hosting and security operations.

NVIDIA, Dell, HPE, and NetApp operate at the compute and infrastructure layer; Microsoft, IBM, Red Hat, SAP, Salesforce, and ServiceNow focus on enterprise software and cloud services; Hugging Face, LangChain, Databricks, Cloudera, and Snowflake sit within the model, data, and development toolchain; while CrowdStrike, Palo Alto Networks, Cloudflare, Cisco, Elastic, and Synopsys directly address cybersecurity, code security, and security operations.

This type of cross-layer alliance has more practical value than one led by a single security vendor. The attack surface of an AI application does not exist solely within the model itself. An enterprise AI agent may simultaneously depend on open-source weights, container images, vector databases, third-party tools, identity systems, and internal APIs. If any layer is replaced, misconfigured, or injected with malicious content, the visible result may simply be that “the model gave the wrong answer,” even though the root cause is entirely different.

In other words, AI security is not about wrapping another layer of sensitive-word filtering around a model. It is a combination of software supply chain security, data security, identity management, runtime isolation, and model behavior governance.

Why Emphasize “Open” Instead of Building Another Security SaaS

The alliance builds on the Linux Foundation’s Akrites initiative and the OpenSSF community’s existing work. Its core philosophy resembles that of traditional open-source security: tools, detection methods, and vulnerability information should be open to review, reproduction, and collaborative remediation rather than controlled exclusively by a single vendor.

For developers, “open security” has at least three practical implications.

First, Protection Rules Can Be Inspected

Proprietary security products typically tell users that a request was blocked without fully explaining the detection logic. This kind of black box may be acceptable for general office use, but in finance, industry, government, healthcare, and similar environments, organizations often need to know why a rule was triggered, where false positives came from, and whether any data left the local network.

Open tools allow teams to audit detection code, pin versions, and maintain their own policy branches. They are not inherently more secure, but they are easier to verify.

Second, Defensive Capabilities Can Be Localized

Model security frequently involves highly sensitive data: system prompts, internal documents, source code, access tokens, employee identities, and customer records. Sending all of this information to an external security service for secondary inspection can itself create new compliance risks.

If scanners, evaluation frameworks, and runtime protection components can operate within an enterprise network, security teams can perform detection without exposing raw data. For private clouds, edge devices, and industrial environments without stable public internet access, this is not merely a preference—it is a prerequisite for deployment.

Third, Single Points of Failure Can Be Reduced

If one vendor’s classifier is bypassed, every customer using the same service may be exposed simultaneously. An open-source ecosystem, by contrast, allows different organizations to use different models, rules, and deployment methods, creating a more distributed defensive structure.

This resembles the logic of public algorithms in cryptography: security should not depend on “attackers not knowing how the system works,” but should instead be grounded in verifiable mechanisms wherever possible. Of course, open source also makes it easier for attackers to study defensive logic. Truly effective systems must therefore still combine access controls, continuous updates, monitoring, and layered isolation. “Public code” must not be equated with “automatic security.”

It Needs to Address More Than Prompt Injection

The alliance has not yet published a complete tool list, technical roadmap, or delivery schedule. Based on its membership and the real-world attack surface of AI applications, developers should pay particular attention to whether it produces practical results in the following areas.

1. Model and Data Supply Chains

Model files, datasets, adapters, dependency packages, and container images can all become vectors for poisoning. Development teams need more than file hashes; they also need provenance, version tracking, signature verification, license information, and dependency inventories.

If the alliance can promote a model bill of materials—similar to a software bill of materials—so that enterprises know exactly which weights, data-processing components, and runtime dependencies a service loads, that would be far more useful than publishing vague security principles.

2. Secure Tool Use by AI Agents

Once AI agents begin connecting to email, databases, browsers, and code repositories, prompt injection is no longer just a matter of making a model “say the wrong thing.” A malicious webpage could trick an agent into reading local files, an external document could conceal tool invocation instructions, and an overprivileged tool could even execute deletions, transfers, or deployments.

Effective protection should focus on least privilege, parameter validation, approval workflows, sandbox isolation, and comprehensive auditing—not on piling on another layer of natural-language prompts. A model may propose an action, but whether that action is executed should be determined by a deterministic policy system.

3. Evaluation and Red-Teaming of Open Models

Models vary widely in their resistance to unauthorized instructions, data leakage, malicious code, and tool hijacking. Their behavior can also change with quantization, fine-tuning, and modifications to system prompts. Testing only the base model is of limited value.

More useful tools should allow developers to run repeatable tests against their complete applications while recording model versions, inference parameters, prompt templates, tool permissions, and test results. Otherwise, the same “security score” cannot be compared across versions or meaningfully integrated into CI/CD workflows.

4. Vulnerability Disclosure and Response Mechanisms

The boundaries of AI vulnerabilities are less clear than those of traditional software vulnerabilities. The industry still lacks a fully standardized way to determine whether a jailbreak constitutes a product defect, a model limitation, or a deployment error.

If the alliance intends to build on the OpenSSF community’s experience, it will need to provide clear reporting channels, reproduction standards, severity classifications, remediation coordination, and disclosure timelines. Without these mechanisms, “shared vulnerabilities” can easily become scattered cases posted in public chat groups rather than reusable engineering assets.

An Impressive Roster Does Not Guarantee an Effective Alliance

This collaboration deserves attention, but it is too early to rate it highly.

Over the past few years, the AI industry has had no shortage of alliances, declarations, and security frameworks. What remains genuinely scarce is code that can be downloaded, deployed, and integrated directly into existing pipelines. For developers, an actively maintained scanner or a reproducible benchmark is generally more valuable than dozens of pages of principles.

The success of the Open Secure AI Alliance can be judged by four indicators:

1. Does it have public code repositories and explicit open-source licenses? If its core capabilities ultimately remain locked inside member companies’ commercial products, “open” will be little more than a slogan.
2. Does it have stable maintainers? Security tools require continuous updates. An initial code release without vulnerability response or ongoing version maintenance could instead create new supply chain risks.
3. Does it support multiple models, multiple clouds, and on-premises environments? If its tools work only with one cloud platform, one type of GPU, or one model API, the alliance’s value as public infrastructure will be greatly diminished.
4. Can it integrate into real development workflows? Ideally, its tools should connect to code review, image builds, model releases, agent runtimes, and security operations centers—not create another isolated console used only by security specialists.

Another notable signal is the absence of major model or cloud service providers such as OpenAI, Anthropic, Google, Meta, and Amazon from the announced list of founding members. The alliance already includes major participants such as NVIDIA, Microsoft, IBM, and Hugging Face, so its reach is by no means weak. Even so, it is still some distance from representing the entire industry.

That is not necessarily a bad thing. Too many members with overly complex interests can slow technical decision-making. However, when the alliance begins defining interfaces, evaluation methods, or vulnerability standards, whether these absent companies adopt them will directly determine whether those standards can become truly universal.

The Most Practical Impact for Developers: Security Capabilities Could Shift from Products to Components

If the alliance ultimately delivers open tools as planned, the greatest beneficiaries may not be foundation model companies, but ordinary development teams integrating models into business systems.

Today, model gateways, content moderation, red-team evaluation, prompt injection detection, data loss prevention, and agent permission management often come from different vendors. Their interfaces are inconsistent, their logs are fragmented, and reconstructing a complete chain of events after a security incident is difficult.

An open community has an opportunity to turn some of these capabilities into shared components and common data formats. Enterprises could continue purchasing commercial products without tying all of their security policies to a single vendor. Security companies could also build higher-level detection and operational capabilities on a common foundation instead of repeatedly reinventing basic infrastructure.

Open-source protection tools, however, will not relieve developers of responsibility. Model applications should still follow several basic principles: do not treat model outputs directly as trusted instructions; do not grant agents more privileges than their tasks require; do not execute high-risk actions without approval; and do not skip input validation, access controls, or log auditing simply because a so-called “secure model” is being used.

Conclusion

The Open Secure AI Alliance has identified the right problem: as AI becomes a new foundational layer of cloud computing and enterprise software, defensive capabilities cannot exist solely in the invisible backends of a handful of vendors. Open models, open runtime frameworks, and open-source security tools can give enterprises greater authority to audit, deploy, and modify their systems while reducing dependence on any single service.

For now, however, the alliance has mainly presented a membership list and a general direction. What is truly worth tracking next is not which company joins, but when the alliance releases its first usable repository, which license it adopts, who will maintain it, and whether its tools can stop an attack in a real production environment.

The true value of a security alliance is ultimately measured not by its wall of logos, but by its commit history.

References

• ITHome: NVIDIA, Microsoft, IBM, and 34 Other Companies Form the Open Secure AI Alliance—Introduces the alliance’s background, mission, open-source security philosophy, and complete list of founding members.