Artificial intelligence is becoming deeply embedded in cybersecurity, but the tools used to defend organisations are often controlled by a small number of vendors. When those systems fail, restrict legitimate activity or cannot be adapted during an incident, security teams may have little choice but to wait for the provider to respond.
The newly formed Open Secure AI Alliance wants to change that model. Backed by major technology companies, security vendors, infrastructure providers and AI research organisations, the group aims to develop open-source components that can make AI-powered security systems easier to inspect, customise, test and govern.
Its central argument is straightforward: organisations should not be completely dependent on closed AI platforms when responding to cyberattacks. Defenders need tools they can operate on their own infrastructure, examine during an investigation and modify when standard safeguards interfere with legitimate security work.
A Broad Coalition Across Technology and Cybersecurity
The Alliance brings together an unusually wide range of companies involved in enterprise technology, cloud infrastructure, cybersecurity and artificial intelligence.
Its members reportedly include Nvidia, Adobe, Cisco, Cloudflare, CrowdStrike, IBM, Microsoft, Palo Alto Networks, Red Hat, Salesforce, SAP and ServiceNow. Infrastructure and data companies such as Dell Technologies, HPE, NetApp and Snowflake are also involved.
AI-focused organisations including Hugging Face, Cognition, Nous Research and Thinking Machines Lab add model-development and research expertise to the group.
The Linux Foundation provides the governance structure behind the initiative. This is important because an open-source alliance needs more than a collection of code repositories. It also requires transparent decision-making, contribution rules, maintenance processes and a structure that prevents any single company from controlling the entire direction.
Rather than creating one competing AI model, the Alliance appears to be concentrating on the wider security environment surrounding AI systems.
The Security Incident That Strengthened the Case for Openness
The Alliance's argument gained urgency following a security incident involving Hugging Face.
During the investigation, Hugging Face reportedly found that its closed AI tools were unable to distinguish between malicious attacker activity and legitimate actions performed by the company's own incident-response team.
The safeguards intended to prevent harmful behaviour reportedly interfered with the forensic work needed to understand and contain the breach. In other words, the system could recognise that potentially dangerous actions were being performed, but it could not reliably understand that authorised defenders were carrying them out for investigative purposes.
That limitation becomes especially serious during an active intrusion. Security teams may need to inspect suspicious files, reproduce attacker techniques, analyse malicious commands and test compromised environments. These activities can resemble cyberattacks when viewed without context.
A rigid safety filter may therefore block the same techniques defenders need to study.
An Open-Weight Model Provided an Alternative
Hugging Face reportedly turned to GLM 5.2, an open-weight model that could be operated directly on its own infrastructure without the same external restrictions.
The company used the model to examine more than 17,000 actions associated with the intrusion. That analysis helped its team reconstruct what had happened and contain the incident.
The significance of the episode goes beyond the specific model used. Hugging Face had access to an alternative system it could control, configure and run privately. It did not need to wait for a closed vendor to change its policies or adjust its safety mechanisms.
However, most organisations do not have Hugging Face's technical resources. They may not maintain multiple AI models, dedicated research teams or spare computing capacity for emergency investigations.
The Alliance wants to make that level of flexibility more widely available by treating open AI security tools as shared infrastructure rather than something limited to specialist laboratories.
Why Closed AI Can Become a Problem During an Incident
Closed AI platforms offer convenience, managed infrastructure and built-in safeguards. For many ordinary tasks, those advantages are valuable.
The difficulty appears when an organisation needs functionality that falls outside the vendor's permitted use cases. A security team may understand exactly why a particular forensic action is necessary, but the external AI provider sees only a request that resembles malicious activity.
When the model, safety controls and execution environment are all controlled by the vendor, the customer may be unable to inspect why the action was blocked or modify the system to recognise an authorised investigation.
That dependence can create a dangerous delay.
Cybersecurity incidents are highly time-sensitive. The longer attackers remain inside an environment, the more opportunities they have to steal information, deploy malware, destroy evidence or move into additional systems.
An open model does not automatically solve every problem, but it gives defenders more control over how the system is configured and operated.
Openness Does Not Eliminate Security Risks
The case for open AI is not without serious concerns.
Model weights that defenders can inspect may also be studied by attackers. Safeguards can potentially be removed, models can be fine-tuned for harmful purposes and vulnerabilities may be discovered by anyone with access to the code or model files.
The Open Secure AI Alliance does not appear to deny these risks.
Instead, its position is that closed models do not remove the possibility of misuse. They place access behind vendor-controlled systems, policies and technical barriers. Determined attackers may still exploit commercial platforms, use stolen accounts or build alternative tools.
The Alliance argues that openness should be combined with strong evaluation, monitoring, identity controls, permission boundaries and rapid patching. Under this approach, transparency becomes part of the defence rather than an excuse to operate without safeguards.
The real debate is therefore not simply whether open models are safe or unsafe. It is whether organisations can build an open ecosystem with enough controls to make transparency more valuable than secrecy.
The Model Is Only One Part of an AI Security System
AI security agents are often discussed as though the model alone performs the work. In practice, an enterprise AI agent is made up of several connected layers.
The model may provide reasoning and generate actions, but other systems determine what it is allowed to access, which tools it can call, how its identity is verified and whether its behaviour is recorded.
A secure AI agent may require authentication, role-based permissions, tool restrictions, detailed logs, approval workflows, evaluation systems and monitoring for unusual behaviour.
This surrounding software is commonly described as the agent harness.
A powerful model placed inside a poorly designed harness can become difficult to control. It may have excessive permissions, perform actions without adequate logging or make changes that cannot be traced afterwards.
The Alliance is therefore focusing not only on models, but also on the infrastructure needed to operate AI agents safely.
Nvidia Targets the Agent Harness Layer
One of Nvidia's contributions is the NVIDIA Labs Object-Oriented Agent, known as NOOA.
Released as open-source research code, NOOA focuses on the layer between an AI model and the actions it is permitted to perform. Its purpose is to make agent behaviour easier to test, observe, audit and govern.
This distinction matters because improving a model's intelligence does not automatically make the resulting agent safer.
An AI model may be excellent at identifying vulnerabilities, generating remediation steps or analysing code. Yet organisations still need to know what resources it accessed, which commands it executed and why it made a particular decision.
A well-designed harness can restrict the agent to approved tools, record each step and allow security teams to review what happened after an action is completed.
NOOA remains a research framework rather than a fully supported enterprise product, but it demonstrates the type of infrastructure the Alliance wants to develop openly.
Giving AI Agents Verifiable Identities
HPE is contributing work around SPIFFE and SPIRE, an open identity framework for software workloads.
In a traditional enterprise environment, human users authenticate with passwords, passkeys, security tokens or biometric methods. AI agents also need reliable identities, especially when they are accessing sensitive systems or acting automatically.
SPIFFE and SPIRE can issue cryptographic identities to workloads. This allows a system to verify that an AI agent is genuinely the approved service it claims to be before granting access.
Without this kind of identity control, a malicious process could attempt to impersonate a trusted agent and request access to enterprise data or infrastructure.
Strong workload identity also makes it easier to apply least-privilege access. An AI agent responsible for analysing logs, for example, should not automatically have permission to modify production databases or deploy software.
Making Model Files Safer to Distribute
Hugging Face has also transferred stewardship of Safetensors to the PyTorch Foundation.
Safetensors is a file format designed to store AI model weights without embedding executable code. This addresses a known weakness in some older model formats, where loading a model file could potentially execute hidden malicious instructions.
The risk is similar to opening an apparently harmless document that secretly contains dangerous code.
Separating model data from executable behaviour makes the distribution of open weights safer. It does not guarantee that a model itself is trustworthy, but it reduces one route through which attackers might compromise systems that download and load models.
This kind of supply-chain protection will become increasingly important as organisations obtain models, datasets and AI components from many different sources.
Protecting the Open-Source Supply Chain
IBM and Red Hat are contributing the Lightwell project, which focuses on digitally signed patches across the open-source supply chain.
Digital signatures help organisations verify that an update genuinely came from the expected developer and was not altered before reaching them.
This is particularly important in AI ecosystems because models and agents may depend on numerous libraries, frameworks, plugins and external tools. A weakness in one component can affect every system that relies on it.
Open-source software allows communities to identify and repair vulnerabilities quickly, but that benefit depends on users being able to trust the patches they receive.
Signed updates provide a stronger chain of verification between maintainers and the systems deploying those updates.
Using Multiple Agents to Find Real Vulnerabilities
Microsoft is contributing MDASH, a security-scanning harness that uses several specialised AI agents to examine software code.
Traditional scanning tools often identify suspicious patterns but produce large numbers of false positives. Security teams may receive long lists of possible vulnerabilities without knowing which ones can actually be exploited.
MDASH is intended to go further by using agents to investigate findings and demonstrate whether a vulnerability is practically exploitable.
That distinction can help security teams prioritise their work. A theoretical weakness that cannot be reached in the deployed environment may require less urgent attention than a vulnerability that an agent can reproduce under realistic conditions.
However, systems capable of proving exploitation must be governed carefully. The same capability that helps defenders validate a flaw could become dangerous if given excessive access or used outside an authorised testing environment.
xAI Promises More Open Access
xAI has reportedly contributed its Grok Build coding agent and indicated that it plans to release model weights from the Grok family to external researchers.
Opening model weights can allow independent experts to examine behaviour, identify weaknesses and test whether safety claims hold under different conditions.
It may also support the development of specialised security models that can run locally without sending sensitive data to an external provider.
For organisations handling confidential information, local operation can be a major advantage. Security logs, source code and incident evidence may contain highly sensitive details that companies are unwilling or legally unable to upload to third-party AI services.
The usefulness of these releases will nevertheless depend on licensing conditions, documentation, hardware requirements and whether the projects receive long-term maintenance.
A Message Directed at Regulators
The Alliance is not only speaking to developers and security professionals. Its argument is also aimed at governments currently preparing AI regulations.
Some policymakers are considering stronger restrictions on advanced open-weight models because they could be adapted for harmful purposes. The Alliance is warning that rules written too broadly may also weaken legitimate cybersecurity work.
Its position is that open models, agent harnesses and security tools should be treated as defensive assets rather than restricted automatically.
A blanket limitation on open frontier models could leave advanced AI security capabilities concentrated among a small number of major vendors. Organisations would then become dependent on those providers for access, policy decisions, pricing and technical updates.
The Hugging Face incident is being presented as an example of why defenders need alternatives they can operate independently.
Regulators Still Face a Difficult Balance
The Alliance's argument is significant, but it does not settle the regulatory debate.
Governments must consider both sides. Open models may give researchers and defenders valuable transparency, but they may also make powerful capabilities more accessible to malicious users.
A sensible regulatory approach may need to focus less on whether a model is simply open or closed and more on what it can do, how it is distributed and what safeguards surround its use.
Other factors could include computing requirements, tool access, identity controls, deployment context, monitoring and whether the model can autonomously affect real systems.
This risk-based approach would recognise that a model operating in a restricted research environment presents a different level of danger from an autonomous agent with access to financial, healthcare or critical-infrastructure systems.
The Alliance Still Has Much to Prove
Many of the Alliance's contributions are new, experimental or still developing.
NOOA is currently described as a research project rather than a supported commercial product. Other frameworks have not yet established a long track record in hostile enterprise environments.
Open-source security projects also require continuous maintenance. Releasing code is only the beginning. Contributors must fix vulnerabilities, review changes, update documentation and provide clear guidance for organisations attempting to deploy the technology.
The Alliance will also need to demonstrate that its governance model works when members have competing commercial interests.
Large companies may support open standards while still attempting to direct customers towards their own platforms, cloud services and enterprise products. Maintaining genuinely vendor-neutral governance will be essential for the Alliance's credibility.
More Real-World Evidence Will Be Needed
The Hugging Face incident provides a compelling story, but one case is not enough to establish open AI agents as the default choice for cybersecurity.
The Alliance will need additional examples showing that open tools can shorten incident-response times, improve vulnerability detection and operate safely in real production environments.
Independent testing will also be important. The same organisations contributing tools should not be the only ones evaluating their effectiveness.
Security researchers, universities and enterprise users should be able to test whether the systems remain reliable when exposed to manipulated inputs, compromised dependencies and determined attackers.
Clear metrics could help measure progress, including detection accuracy, false-positive rates, auditability, recovery time and the ability to limit an agent's permissions.
Final Thoughts
The Open Secure AI Alliance is entering one of the most important debates surrounding artificial intelligence: whether security should depend primarily on closed vendor systems or be built around tools that organisations can inspect and control.
Its strongest argument is not that open AI is automatically safer. It is that defenders need options when closed systems block legitimate investigations, fail to provide visibility or cannot be adapted quickly enough during an emergency.
The Alliance's work on agent harnesses, workload identity, safer model formats, signed patches and multi-agent code scanning shows that AI security extends far beyond the model itself.
Whether this approach becomes widely trusted will depend on evidence, maintenance and responsible governance. Open-source tools must prove that they can survive hostile environments, protect sensitive systems and remain usable long after their initial release.
For now, the initiative offers a valuable direction: AI security should not be judged only by how powerful a model is, but by how transparently, safely and independently defenders can use it.
Comments