Summary
- The Open Secure AI Alliance has joined the Linux Foundation after launching in July with more than 120 participants across AI, cybersecurity, cloud, and enterprise software.
- Its work covers the full AI agent stack, including models, identity, permissions, enforcement, monitoring, containment, and infrastructure rather than model security alone.
- A proposed Shared AI Findings Exchange would confidentially pool incidents and near misses so recurring weaknesses can be converted into common defensive controls.
The Open Secure AI Alliance has moved into the Linux Foundation, giving a coalition of AI, cybersecurity, cloud, and enterprise technology companies a vendor-neutral home for developing shared security tools as businesses put AI agents into production systems with access to data, software, and operational workflows.
The Alliance was established in July with Nvidia and more than 120 participating organisations, including Microsoft, IBM, Cisco, Cloudflare, SAP, Siemens, Mistral, Nokia, Canonical, SUSE, Thales, Salesforce, ServiceNow, CrowdStrike, Palo Alto Networks, Hugging Face, and Red Hat. Moving the initiative into the Linux Foundation changes its governance rather than creating a new group, with the intention of allowing competing vendors, researchers, and government organisations to collaborate without one technology supplier controlling the project.
Its work is centred on an open defensive stack spanning the systems surrounding AI rather than concentrating only on the security of a model. That includes inference, agent software, context and memory, identity and permissions, policy controls, enforcement, observability, containment, recovery, and the infrastructure underneath them.
Jim Zemlin, chief executive of the Linux Foundation, said: “AI systems should be secure, reliable and predictable.” The Foundation argues that bringing the Alliance into its governance structure will allow members to develop common tools, standards, and evidence-based practices while retaining the ability to inspect and adapt the resulting technology.
AI agents widen the attack surface
The scope reflects a problem appearing as enterprise AI moves from systems that answer questions towards software able to take actions. A conventional chatbot can generate incorrect information or expose sensitive data, but an agent may also have credentials, use external tools, query databases, invoke APIs, change records, send messages, or hand work to other agents.
That puts familiar security controls back at the centre of AI deployment. Organisations need to know which agents exist, what identities they use, which systems they can access, what permissions they have, how changes are approved, what activity is logged, and how access can be withdrawn when something goes wrong.
The Alliance is consequently emphasising security principles that already apply elsewhere in enterprise computing rather than treating every AI problem as unique. Its proposed practices include asset visibility, identity and permission management, deterministic controls around agent actions, change management, monitoring, human accountability, and rehearsed incident-response procedures.
There is still an AI-specific difficulty because an agent’s behaviour can be shaped by natural-language instructions, retrieved data, model outputs, tools, memory, and context assembled at runtime. A system may therefore behave differently without its underlying application code changing in the conventional sense, complicating established approaches to testing and assurance.
Open tooling is intended to give defenders greater visibility into those layers. The Alliance says organisations should be able to inspect security mechanisms, adapt them to their own infrastructure, and run them under their own control rather than depending entirely on an opaque service provided by the same vendor supplying the model or agent platform.
Incident sharing becomes part of the design
One of the Alliance’s first initiatives is the Shared AI Findings Exchange, or SAFE, which is being developed through a public request-for-comments process. The proposal is intended to create a mechanism for organisations to confidentially contribute AI security incidents and near misses, notify affected parties, and identify recurring failure patterns that can be turned into common defensive controls.
The idea resembles established forms of coordinated vulnerability disclosure and industry threat sharing, although AI incidents do not always fit neatly into existing software-security categories. A weakness may involve prompt manipulation, excessive agent permissions, leakage through context, unsafe tool use, a model behaving unpredictably around a particular input, or a chain of individually permitted actions producing an unintended result.
Pooling evidence could help organisations distinguish isolated implementation errors from weaknesses that recur across models and platforms. It could also make it harder for vendors to treat incidents as private product problems when the same failure mode appears elsewhere in the market.
There are practical obstacles because companies can be reluctant to disclose security incidents owing to legal exposure, customer confidence, regulatory reporting obligations, or concern that technical detail will help attackers. SAFE is therefore being proposed as a confidential exchange rather than a public database, with developers, security practitioners, researchers, and organisations invited to comment on the framework before 21 September.
Neutral governance has commercial consequences
The Linux Foundation already hosts security and infrastructure projects used across competing technology ecosystems, including the Open Source Security Foundation, while its broader portfolio includes Kubernetes, PyTorch, Model Context Protocol, RISC-V, and OpenStack. Bringing the Open Secure AI Alliance into the same institutional environment gives members established processes for collaborative governance while creating potential overlap with existing open-source security work.
That structure is particularly relevant in AI because the enterprise stack is becoming fragmented across model providers, cloud platforms, data systems, security vendors, agent frameworks, and application developers. Few organisations are likely to run every component from a single supplier, even where vendors would prefer them to do so.
Common defensive interfaces and evaluation methods could make security controls more portable across that multi-vendor environment. They could also limit dependence on a model provider’s proprietary safety systems by allowing security teams to impose additional controls at the identity, runtime, infrastructure, or application layer.
The involvement of European companies gives the project relevance beyond its US origins. SAP and Siemens bring large enterprise and industrial footprints, while Mistral represents European model development and Nokia, Thales, SUSE, and Canonical operate across communications, security, infrastructure, and open-source software. Nvidia will present the Alliance’s collective-defence work at Open Source Summit Europe in Prague on 7 October.
Open standards do not guarantee adoption, and a coalition containing competing vendors can spend considerable time agreeing terminology before producing technology security teams actually deploy. The Alliance will have to show that shared tooling can keep pace with agent architectures changing across model providers and software platforms, while the Linux Foundation gives it a neutral place to attempt that work.












