Open Secure AI Alliance and the Open Defense Stack, Explained

The Open Secure AI Alliance is an industry group, started by NVIDIA in July 2026 and moved under the Linux Foundation in September 2026, that builds open tools, models and practices for defending software and AI agents. Its "open defense stack" covers the whole agent system, not just the model. Its first shared project, SAFE, sets rules for reporting AI incidents.

That is the short answer. The longer one matters more if you run AI in production, because the alliance makes a specific bet: that defenders are safer when models, weights, agent harnesses and security tooling are open enough to inspect, adapt and run on infrastructure you control. Plenty of thoughtful people agree. Plenty push back. This guide explains what the alliance actually published, where its argument is strong, where its own sources add caveats, and how to evaluate an open model before it touches anything important.

Key takeaways

• The Open Secure AI Alliance launched on 27 July 2026 with NVIDIA as founder and the Linux Foundation as an inaugural partner. It joined the Linux Foundation on 14 September 2026.
• Members span chip makers, cloud and data platforms, enterprise software, banks, AI labs, open source foundations and many security vendors. The two launch posts list 37 and 122 partners respectively.
• The "open defense stack" is a seven layer model of an agent system, from model and inference down to a trusted hardware foundation. Most of its controls sit outside the model.
• SAFE, the Shared AI Findings Exchange, commits members to report AI incidents and near misses on fixed timelines, including a confidential report within four business days.
• The case for open weights rests on access, competition, control and defenders' need for models they can run themselves. The same sources admit released weights cannot be recalled and modified copies are hard to trace.
• "Open weights" is not "open source AI" under the Open Source Initiative's definition.
• Evaluating an open model is a supply chain job: AI-BOM, model card review, pinned revision, safetensors over pickle, signature checks, licence review and sandbox testing.

What the Open Secure AI Alliance is

The alliance describes itself on its site as a group that builds and shares an open defensive stack of AI models, tools and techniques to strengthen cyber defense and secure software and AI agents. The emphasis throughout its material is on capabilities that defenders can inspect, adapt, trust and control.

It has two stated goals, according to the Linux Foundation's September announcement. The first is to build that open defensive stack. The second is collective defense: helping organizations test systems, share evidence and turn what they find into protections the wider ecosystem can use. The Linux Foundation positions this work alongside its existing security communities, especially the Open Source Security Foundation (OpenSSF).

Timeline

Who started it and who is in it

The September announcement says NVIDIA established the alliance together with members including the Linux Foundation. Moving it under the Linux Foundation gives it vendor neutral governance, which matters for a group whose members compete with each other.

The member lists do not match. The Linux Foundation's 27 July post names 37 inaugural partners, including itself. NVIDIA's launch post, published the same day, names 122. Both span chip and hardware makers, cloud and data platforms, developer tool companies, enterprise software vendors, financial institutions, telecom operators, AI labs, open source foundations and a large group of cybersecurity vendors. Hugging Face, which created the safetensors format (since offered to the PyTorch Foundation, according to NVIDIA), is on both lists.

Membership is a statement of support, not a certification. A vendor being in the alliance tells you nothing about whether its own products meet any particular bar, and the alliance does not claim otherwise.

How it is governed and how to join

Industry, researchers and government partners join through the Linux Foundation's enrollment system. The site lists three ways to take part: contribute open tools, models or research; work with foundations such as OpenSSF on standards; and help shape guidance for policymakers. Proposals go through a public request for comments on GitHub, where the wg-safe repository shows the SAFE proposal as approved by the steering committee.

What the "open defense stack" means

The phrase sounds like marketing until you read the alliance's own breakdown. Its core claim is that an AI agent is more than a language model. It is a software system built from models, the harness that lets the model observe context and take action, and the guardrails that constrain it. Security depends on the whole system, so every layer needs to be open, testable and auditable.

The site lists seven layers. Here they are with what each layer does, the controls that belong there, and example open work the alliance's launch material points to.

Two features of this model stand out. First, most of the security weight sits outside the model. Policy, enforcement and containment are deterministic controls that do not depend on the model behaving well, which matches how mature teams already treat agents. Second, the harness gets its own layer. The Linux Foundation argues that the harness, which decides what an agent can see and do, shapes behaviour in practice as much as the model does. Anyone who has watched an agent change after a change to its tool list will recognise that.

NOOA, the first code contribution

NOOA, the NVIDIA Labs Object-Oriented Agent project, is the working code that shipped with the launch. Its README describes a model agnostic Python framework where an agent is a Python class: fields hold state, methods are capabilities, docstrings act as prompts and type annotations act as contracts. A method with an empty body becomes an agentic loop handed to the model; a method with real code stays deterministic.

Putting agents in ordinary Python makes them easier to test, trace, version and review with existing tools, which supports the alliance's auditability goal. The flip side is that the model acts by writing Python in a REPL with access to the agent object and imports. Code as action needs the same isolation you would give any untrusted code execution. NOOA is Apache 2.0 licensed, installs from PyPI as nooa, and NVIDIA calls it a research framework, so expect it to change.

SAFE: the Shared AI Findings Exchange

SAFE is the alliance's first working group and the most concrete thing it has published. The proposal's mission is to confidentially collect and analyze AI incidents and near misses, promptly inform affected parties, and turn recurring failures into shared controls backed by evidence.

Who takes part

SAFE wants model developers, deployers, cloud and tool providers, independent researchers, critical infrastructure operators and civil society at the table, with governments and standards bodies as observers without control. Its processes apply equally to open and closed systems; neither is safe by declaration. In the proposal's words, "Trust is not a control".

What members must report

As a condition of membership, members agree to report when they know or reasonably suspect that an AI system they operate has done any of the following:

• Accessed, exploited, disrupted, misused or modified a third party system without authorization.
• Caused third party impact by escaping or bypassing a sandbox, network, identity, policy or tool boundary.
• Accessed third party confidential information without the owner's consent.
• Kept probing or modifying a production target after the operator knew or suspected the activity was unauthorized or out of scope.

Intent does not decide reportability: believing an environment was simulated may explain an incident but does not remove the duty to report it. Near misses count too.

Notification timelines

These timelines sit on top of existing obligations. The proposal says they do not replace coordinated vulnerability disclosure practice, contracts or legal duties to notify regulators or law enforcement.

Evidence you are expected to keep

This list is useful even if you never join anything, because it doubles as a logging checklist for any agent deployment. Members must preserve and share with affected organizations:

• Prompts, traces, tool calls, logs, configurations, model and safeguard versions and third party dependencies
• Agent and workload identities
• Permissions and credentials available during the run
• Human approval and intervention events
• Files and external artifacts created or changed
• Detection, containment and recovery events
• A complete incident timeline
• Reproduction testing and remediation evidence

If your agent platform cannot produce most of this today, that is the gap to close first.

How incidents are reviewed

Each incident is examined across eight control layers: the model, its instructions, safeguards, tools, the environment, monitoring, human operations and the supply chain. The supply chain question asks whether a cloud, evaluation, data or tooling partner invalidated a control you assumed was in place. The affected organization can correct factual errors but cannot veto the findings.

Findings flow out in three tiers: a confidential rapid alert, a de-identified member advisory and a public safety report. Each review should produce a recommendation with a minimum control, a reproducible way to verify it, an owner and a deadline. For unintended access to real systems, the proposal suggests controls such as default deny network egress, explicit target allowlists, signed evaluation manifests and automatic stops when scope is uncertain.

Open weights and security: the arguments both ways

The alliance's founding documents take a clear side in the open weights debate. Read them alongside the caveats they include.

The case for open weights

The Linux Foundation's July post and the open letter it cites make the same three points.

1. Access. Startups, established firms, universities and public bodies can build on capable models without training one from scratch or paying frontier prices for routine work.
2. Competition. When many organizations can adapt and deploy capable models, competition spreads to chips, applications and services.
3. Control. Organizations can keep data in house, adapt models to their needs and avoid lock in.

On security, the argument is that attackers already use advanced AI, so defenders need comparable models they can run, study and adapt, and that concentrating capability in a few closed models creates single points of failure. NVIDIA's launch post adds a balancing line that is easy to miss: the world needs both closed and open models, and defenders should pick the right one for the job.

The risks the same sources admit

None of these documents claims open weights are risk free. The open letter says plainly that released weights are beyond the original developer's control and that modified versions are hard to trace or reverse. NVIDIA accepts that open models can be misused, including by weakening safeguards, while arguing those risks are not unique to open systems.

For a team using open weights, the practical risks are:

• Provenance. A file on a public hub may be a re-upload, fine tune or quantization of something else. Without signatures or clear lineage, you are trusting a name.
• Unsafe formats. Hugging Face's documentation warns that loading a pickle file can run arbitrary code, and pickle is the default format for PyTorch weights.
• Removed safeguards. Anyone can fine tune refusal behaviour out of a released model.
• Licence and data uncertainty. Many "open" models carry custom licences and little training data information.

NIST's Generative AI Profile (NIST AI 600-1, July 2024) covers much of this under its value chain and component integration risk: upstream components and data integrated without transparency or traceability, and weak supplier vetting across the AI lifecycle. That is supply chain risk, applied to models.

What the Hugging Face incident does and does not show

Both the Linux Foundation and NVIDIA cite Hugging Face's July 2026 disclosure. The original is more careful than the summaries.

According to Hugging Face, an autonomous agent system broke in through its dataset processing pipeline, escalated, harvested credentials and moved laterally over a weekend. Responders used LLM-based agents to analyze more than 17,000 recorded attacker events. Hosted frontier models blocked the requests, because the analysis meant submitting real attack commands and payloads, so the team ran an open weight model on its own infrastructure instead. That also kept attacker data and credentials inside its environment.

Hugging Face's lesson is to have a capable self-hosted model vetted before an incident. It also says this is not an argument against safety measures on hosted models. The Linux Foundation's post goes further, saying the defenders could respond only because they had open models. That is a stronger reading than Hugging Face's own account. The fair takeaway: hosted model guardrails can block legitimate incident response, and a self-hosted model belongs in an incident plan. It does not prove open models are safer in general.

Decision table: hosted closed model or self-hosted open weights

For security teams the real question is not ideology. It is which option fits a given job. This table compares the two on the factors that tend to decide it.

Many teams end up using both: hosted models for general work, and a vetted self-hosted model for sensitive data and incident response.

"Open weights" is not "open source AI"

The Open Source Initiative's Open Source AI Definition 1.0 requires three things: training data information detailed enough for a skilled person to build a substantially equivalent system, the complete code used to train and run it, and the model parameters, each under OSI-approved terms. Weights only count as open source if the data information and code that produced them come too.

Most open weight releases ship parameters and inference code under a licence of the publisher's choosing. That is still useful to defenders, because you can run and test the model, but it is not enough to rebuild it or fully audit its training. When an announcement says "open", ask which parts and under what terms.

How to evaluate an open model before you run it

Whether or not your organization ever joins the alliance, the practical work it points to is the same work you would apply to any third party dependency. Here is a step by step approach for a team adopting an open weight model inside a product or an internal agent.

Step 1: Record it in an AI-BOM

You cannot govern what you have not listed. Two open standards cover models today.

• CycloneDX has a machine learning model component type with a model card object: model parameters (approach, task, architecture family, architecture, datasets, inputs, outputs), quantitative analysis and considerations such as use cases and technical limitations.
• SPDX 3.0 has an AI profile with fields such as type of model, domain, autonomy type, training information, limitations, metrics and safety risk assessment, and requires a concluded licence for every AI package.

A minimal CycloneDX entry looks like this. Replace the example values with your own.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-example-7b",
      "name": "example-org/example-7b-instruct",
      "version": "3f2c9e1",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "<sha256 of model.safetensors>" }],
      "externalReferences": [
        { "type": "model-card", "url": "https://huggingface.co/example-org/example-7b-instruct" }
      ],
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "self-supervised" },
          "task": "text-generation",
          "architectureFamily": "transformer"
        },
        "considerations": {
          "useCases": ["Internal log triage"],
          "technicalLimitations": ["Not evaluated for code execution tasks"]
        }
      }
    }
  ]
}

The version field holds the exact revision you evaluated, not a branch name. See our guide to AI bills of materials for what else to record.

Step 2: Read the model card like an auditor

On Hugging Face, the model card is the repository's README.md with a YAML metadata block. Hugging Face's docs say it should cover intended uses and limitations, including biases, plus training parameters, and the metadata can link training datasets. Read it for gaps:

• Is the training data described, or only gestured at?
• Is a base model stated, so you can trace lineage?
• Are limitations and out of scope uses spelled out?
• Does the metadata licence match the licence file?
• Is the publisher who you think it is, or is this a re-upload?

A thin model card is not proof of a problem, but it shifts the whole burden of evaluation to you. Our post on model cards and AI SBOM transparency goes deeper.

Step 3: Pin the exact revision and keep only safe formats

Hugging Face's CLI downloads from the latest commit on main by default. Pin a specific commit instead and pull safetensors weights where the repository provides them. Check the target directory first so you do not overwrite a model you already approved.

# Confirm the target directory does not already hold an approved model
ls ./models/example-7b-instruct 2>/dev/null && echo "Directory exists, choose another path"

# Download one pinned revision, weights in safetensors format only
hf download example-org/example-7b-instruct \
  --revision 3f2c9e1d5a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d \
  --include "*.safetensors" \
  --local-dir ./models/example-7b-instruct

# Download the small config and tokenizer files from the same revision
hf download example-org/example-7b-instruct config.json tokenizer.json \
  --revision 3f2c9e1d5a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d \
  --local-dir ./models/example-7b-instruct

# Look for pickle based files that should not be there
find ./models/example-7b-instruct -type f \( -name "*.bin" -o -name "*.pt" -o -name "*.pth" -o -name "*.pkl" -o -name "*.ckpt" \)

# Record a hash manifest for the AI-BOM and for later drift checks
find ./models/example-7b-instruct -type f -exec shasum -a 256 {} \; | sort -k2 > example-7b-instruct.sha256

The safetensors README describes it as a way to store tensors safely, unlike pickle, while staying fast. Hugging Face's pickle documentation explains that unpickling can execute code and advises loading models only from trusted publishers. If a model ships only in a pickle based format, treat the file as code from an unknown author: keep it off developer laptops and ask the publisher for a safetensors release.

Step 4: Verify signatures where they exist

The OpenSSF model signing project, in the Sigstore model-transparency repository, signs a whole model directory so users can check the files match what a known identity signed. It supports Sigstore keyless signing, which records signing events in a public transparency log, as well as private keys, certificates and hardware tokens. The signature bundle holds an in-toto statement listing each file path and digest.

pip install model-signing

# Compute the model's digest using the tool's own file ignore rules
model_signing digest ./models/example-7b-instruct

# Verify a Sigstore signature against the identity the publisher documents
model_signing verify ./models/example-7b-instruct \
  --signature model.sig \
  --identity "$PUBLISHER_IDENTITY" \
  --identity-provider "$PUBLISHER_OIDC_PROVIDER"

Most open models are not signed today. When they are not, your pinned commit and hash manifest are the next best record, and you can sign the copy you approved so internal deployments verify against your own identity. Our post on signing and attesting model weights covers that approach.

Step 5: Check the licence and the terms of use

The SPDX AI profile requires every AI package to carry a concluded licence for a reason. Model licences vary widely: some are standard open source licences, many are custom, and some restrict use cases, user counts or redistribution. Record the licence identifier, or a link to the custom text, in your AI-BOM, and have someone with authority sign off before the model ships in a product.

Step 6: Test behaviour inside a sandbox

Before a model gets real permissions, serve it in an isolated environment with default deny network egress, the control SAFE suggests for evaluations. Run your own tests for the tasks you plan, including prompts that try to make it leak data or ignore instructions. If it will drive an agent, give that agent a test identity with no production access and log every tool call. A fine tuned open model may have lost its safety behaviour, so build controls that hold even if the model does whatever it is asked.

Step 7: Wire it into the agent stack with deterministic controls

Use the seven layers above as a design review. Before production, you should be able to say which identity the agent runs as and what it can reach, which dangerous actions are blocked or gated by rules outside the model, how you stop it, revoke its credentials and roll back its changes, and where keys live so the agent cannot read them. Workload identity standards such as SPIFFE, cited in the alliance's launch post, give each service and agent a verifiable identity so access decisions do not rest on shared secrets.

For logging, take the SAFE evidence list as your baseline: prompts, traces, tool calls, model and safeguard versions, identities, available permissions, approvals, changed files and containment events.

Step 8: Prepare a self-hosted model for incident response

Take Hugging Face's lesson at face value. Choose a capable model you can run on your own hardware, put it through steps 1 to 6 now, and document how responders will use it. An incident is the wrong time to discover that your tools refuse to read attack logs, or that you have no approved way to analyze sensitive data without sending it outside.

How the alliance relates to OpenSSF, Akrites and NIST

The alliance adds an AI focused layer next to existing efforts rather than replacing them.

• OpenSSF is the Linux Foundation's home for open source security tooling and practice. The alliance lists collaboration with foundations like OpenSSF as a core way to participate, and the model signing work above is one example.
• Akrites, launched in June 2026, coordinates finding, fixing and disclosing vulnerabilities in critical open source, with a shared incident response team, and offers to act as maintainer of last resort for unmaintained critical packages. NVIDIA says the alliance builds on it. Akrites handles vulnerabilities in code; SAFE handles incidents caused by AI systems.
• NIST AI 600-1 supplies a risk vocabulary that many organizations already map AI controls to. The alliance's work fits under it.

You can benefit from the alliance's outputs without joining, because they are meant to be public.

Where Safeguard fits

Safeguard is a software supply chain security platform. It is not a member of the alliance, it does not evaluate model alignment, and it does not replace incident reporting groups such as SAFE. Its fit is the supply chain side of adopting open models and agents. GA means generally available; EA means early access.

• SBOM generation and analysis in SPDX and CycloneDX [GA]. The inference servers, tokenizers, Python packages and container images around a model are ordinary dependencies, and the Safeguard CLI scans the service repository or its container image like any other project.
• Model and agent scanning [GA]. LLM and SLM artifacts pulled from Hugging Face or supplied directly, agent skill definitions, and agent configurations with their tool access are treated as scan targets.
• Agent identity [GA]. Tracks which agent holds what access, at what level.
• Policies and gates [GA] at build, CI and release, plus attestation and signing support for SLSA, Sigstore and in-toto [GA].
• Model flexibility [GA]. Run with no LLM at all (Zero AI mode), with a model you bring, or with Safeguard's own models inside your environment, which suits teams adopting open weights to keep data in house.
• AI-BOM discovery [EA]. Inventories AI assets and produces ML-BOMs in CycloneDX and the SPDX AI profile. Confirm coverage for your stack.
• AI Gateway [EA] and MCP Guardrail [EA]. A runtime guardrail proxy for model traffic, and guardrail proxy URLs for MCP servers that govern agent tool calls.

Where Safeguard does not help: it does not judge whether a model's behaviour is safe for your use case, it does not fine tune or red team models, and it cannot prove the origin of weights that were never signed. Steps 2, 5, 6 and 8 above remain your team's work.

Common mistakes

• Treating alliance membership as a security rating. It signals intent to collaborate, nothing more.
• Calling every open weight model "open source". Under the OSI definition it usually is not.
• Pulling from the main branch. Pin a commit and record its hash, or your evaluation describes a model you no longer run.
• Loading pickle files on a workstation. Pickle can execute code when loaded. Prefer safetensors.
• Relying on the model to refuse. Refusals can be fine tuned out or talked around. Put hard limits in enforcement and containment.
• Giving the agent the developer's credentials. An agent needs its own identity and the smallest set of permissions for its task.
• Ignoring the code around the model. Serving stacks, plugins and containers carry ordinary vulnerabilities. Hugging Face's attacker came in through data processing code, not a model.

Fix it without waiting for upstream

Open models arrive wrapped in ordinary open source: inference servers, tokenizer libraries, Python packages, agent frameworks and container images. The weights themselves are outside the controls below, but every one of those surrounding components is a dependency you build and ship, and that is where they apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What is the Open Secure AI Alliance?

It is an industry group that builds and shares open tools, models and practices for defending software and AI agents. NVIDIA announced it in July 2026 with dozens of inaugural partners, and it joined the Linux Foundation in September 2026 to get neutral governance.

Who are the members of the Open Secure AI Alliance?

The launch lists name between 37 and 122 organizations depending on the source. They include chip and hardware makers, cloud and data platforms, enterprise software firms, banks, telecom operators, AI labs, open source foundations and many cybersecurity vendors. Hugging Face and the Linux Foundation are among them.

What is the open defense stack?

It is the alliance's model of everything that needs securing in an AI agent system: model and inference, agent and context, the harness, policy and identity, enforcement, containment and recovery, and a trusted hardware foundation. The idea is that each layer should be open, testable and auditable.

What is SAFE in AI security?

In this context SAFE is the Shared AI Findings Exchange, the alliance's first working group. Members agree to report AI incidents and near misses, notify affected parties on fixed timelines, preserve evidence, and turn recurring failures into shared, verifiable controls.

How fast does SAFE require incident reporting?

The affected organization should hear as soon as possible, customers with credible exposure within 72 hours, and SAFE gets a confidential initial report within four business days. Broader advisories, a preliminary report and remediation status follow at 14, 30 and 90 days.

Are open weight models less secure than closed models?

Neither is secure by default. Open weights can be inspected and self-hosted but cannot be recalled and can be stripped of safeguards; hosted models shift trust to a provider you cannot inspect. Either way, put hard limits outside the model.

Is an open weight model the same as open source AI?

No. The OSI's Open Source AI Definition 1.0 requires detailed training data information and full training and inference code, as well as the parameters. Most open weight releases provide the parameters and inference code only.

How do I check whether a Hugging Face model is safe to use?

Read the model card, pin a specific commit, download safetensors rather than pickle, verify any signature, record the model and its hashes in an AI-BOM, check the licence, and test it in isolation before giving it real access.

See how Safeguard would help

None of these demos evaluates a model's behaviour. They show supply chain checks and human approval in AI assisted work, the layer this post argues should not depend on the model. To try the CLI, download it and read the CLI setup guide. For background, see AI model supply chain risks on Hugging Face.

This first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. It is a small, concrete example of the policy and identity layer: the agent gets the tools you allow and nothing more.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same approval flow applies when the vulnerable dependency sits in the Python stack around an open model. More in the Safeguard CLI overview.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For teams that chose open weights to keep data in house, it shows scanning on hardware you control.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Linux Foundation: Open Secure AI Alliance joins the Linux Foundation to build a shared, open defense stack for the AI era (14 Sept 2026)
• Linux Foundation: Open models and open weights are foundational to secure AI (27 July 2026)
• Open Secure AI Alliance: official site
• Open Secure AI Alliance: Shared AI Findings Exchange (SAFE) RFC
• Open Secure AI Alliance: wg-safe repository
• NVIDIA Blog: Industry leaders join Open Secure AI Alliance (27 July 2026)
• NVIDIA NOOA (labs-OO-Agents) repository and README
• Open letter: Open Weights and American AI Leadership
• Hugging Face: Security incident disclosure, July 2026
• Linux Foundation: Akrites launch press release (25 June 2026)
• OpenSSF: About
• Open Source Initiative: Open Source AI Definition 1.0
• NIST AI 600-1: AI RMF Generative AI Profile and PDF
• CycloneDX: Machine learning BOM capability and CycloneDX 1.6 JSON schema
• SPDX 3.0.1: AI profile
• Hugging Face Hub docs: Model cards
• Hugging Face Hub docs: Pickle scanning and security
• Hugging Face Hub docs: Command line interface
• Safetensors README
• Sigstore and OpenSSF: model-transparency (model signing)
• SPIFFE: project site

Last reviewed: 23 October 2026. The alliance, its member list and the SAFE working group are new and still changing; check the linked pages for current status.