What Is the SAFE Working Group? Open AI Incident Learning Explained

The SAFE Working Group (Shared AI Findings Exchange) is an open community effort, run inside the Open Secure AI Alliance at the Linux Foundation, that confidentially collects AI security incidents and near misses, notifies affected organizations and turns recurring failures into shared, verifiable controls. It started as a public Request for Comments in August 2026 and published SAFE version 1.0 on 21 October 2026. Anyone can read it, comment on GitHub and join the working group.

SAFE is not another list of AI risks. It is a reporting and learning process, closer to aviation's confidential safety reporting than to a checklist, and it sits next to work you may already use: the OWASP GenAI Security Project, the OpenSSF AI/ML Security Working Group, and NIST's AI Risk Management Framework with its Generative AI Profile (NIST AI 600-1). This guide covers what SAFE asks of members, how it fits with those efforts, what you can use today without joining, and how to take part.

Key takeaways

• SAFE means Shared AI Findings Exchange, a working group of the Open Secure AI Alliance, which joined the Linux Foundation in September 2026.
• It is about learning from incidents. SAFE collects AI incidents and near misses in confidence, reviews them without blame, and publishes controls others can implement and test.
• Members accept a reporting compact covering unauthorized access to third party systems, sandbox escapes, unapproved access to confidential data and consequential harm, including credible near misses.
• The clock is tight: affected organizations immediately, exposed customers within 72 hours, SAFE within 4 business days, then public reports at 30 and 90 days.
• Reviews cover eleven control layers, from the model and its instructions to tools, environment, supply chain, serving path and authorization.
• It complements OWASP, OpenSSF and NIST, supplying the feedback loop from real incidents that risk lists and frameworks lack.
• You can use it without joining, and participation is open through GitHub and the Alliance Slack.

What the SAFE Working Group is

SAFE's mission has three parts: confidentially collect and analyze AI incidents and near misses, promptly inform affected parties, and turn recurring failures into shared, evidence based controls that reduce systemic risk.

The Linux Foundation's 4 August 2026 announcement framed the problem plainly. Organizations investigate AI security incidents on their own, the lessons stay inside the company, and there was no widely adopted community framework for sharing those failures in confidence and turning them into reusable defensive guidance.

NIST had named the same gap. The incident disclosure appendix of its July 2024 Generative AI Profile notes that formal channels for reporting AI incidents did not exist, and that public incident databases chose what to track ad hoc, sometimes by media coverage. SAFE is one attempt to build that channel, as a voluntary industry compact rather than a regulation.

Where the name and the model come from

The Linux Foundation post cites NASA's Aviation Safety Reporting System (ASRS) as the model. ASRS is a voluntary, confidential channel for aviation staff to report safety incidents. NASA says more than one million reports have been filed, all de-identified, and no reporter's identity has ever been breached.

The lesson SAFE borrows is that candid reporting depends on trust in the process. If reports can be used to punish reporters, near misses go unreported, and near misses are what show a weak control before anyone gets hurt. So SAFE keeps learning separate from enforcement, focuses reviews on systemic causes rather than blame, and asks members to give staff a confidential reporting route outside their immediate management chain.

Who runs it

SAFE lives inside the Open Secure AI Alliance. According to the Linux Foundation's 14 September 2026 announcement, the Alliance was originally established by NVIDIA with a group of enterprise members and then moved to the Linux Foundation for neutral governance. Its public site describes the goal as an open defensive stack of models, tools and techniques that defenders can inspect, adapt and run on infrastructure they control. NVIDIA's own blog put the Alliance at more than 120 organizations in August 2026.

The first draft came from contributors at several Alliance members across chips, enterprise Linux, model hosting, networking and security. The members file lists an interim chair from NVIDIA and an interim co-chair from Red Hat since 14 October 2026. The README marks SAFE as approved by the Steering Committee, while the charter itself is still under development. The content is licensed CC BY 4.0.

Timeline so far

The RFC URL from the August post now redirects to OpenSecureAIAlliance/wg-safe, which holds the original proposal, version 1.0 and a changelog.

What SAFE covers: scope in detail

The version 1.0 document is organized into a mission statement, scope and membership, guiding principles, definitions, the reporting compact, notification timelines, evidence preservation, a review framework, a disclosure model and a section on turning lessons into controls. The key pieces follow.

Who can take part

SAFE invites model creators (proprietary and open weight, including fine tuning and quantization groups), researchers, AI deployers, hosting, cloud and tool providers, critical infrastructure operators and civil society worldwide. Government and standards bodies join only as non-controlling observers.

Independence rules stand out. No member or funder may control publication timing or remediation conclusions, and participation grants neither a veto nor access to identifiable confidential reports. The organization involved can correct factual errors but cannot rewrite findings. Reviewers disclose conflicts and recuse where needed, and decisions can be appealed to SAFE leadership or the Alliance Steering Committee.

The document also makes a point that matters in the open versus closed model debate. Its processes apply equally to open and closed AI systems, and it rejects shortcuts in both directions: open systems are not automatically safe, and closed systems are not safe because a vendor says so. In the document's own words, "Trust is not a control; shared evidence and verifiable improvement are how trust is earned."

Note one subtlety from the changelog: joining the Alliance does not, by itself, bind you to SAFE's reporting duties. Participating in SAFE does.

Key definitions

Version 1.0 added definitions worth adopting internally:

• AI incident: an event where an AI system causes or materially contributes to an outcome covered by the reporting compact.
• Near miss: an event with a credible path to a reportable outcome that was stopped before it happened, especially when one control failed and a backup caught it. Routine blocked attempts with no material control failure can be aggregated rather than reported one by one.
• Approved scope: the authorization given by an accountable person, covering permitted actions, targets, resources, purpose, time limits and delegation limits. Critically, a task request or the AI system's own interpretation cannot widen it.
• Agent sandbox and secure runtime: isolated environments that limit an agent's files, processes and network access and record its activity.

Read the approved scope definition twice. Many agent incidents start when an agent reads a broad instruction as permission it was never given, and SAFE treats that as a scope failure.

The reporting compact

Members agree to report when they know or reasonably suspect that an AI system they operate has done any of the following:

1. Accessed, exploited, disrupted, misused or modified a third party system without authorization.
2. Caused third party impact by escaping or bypassing a secure runtime, sandbox or safety system, across network, file artifact, identity, policy or tool boundaries.
3. Accessed third party confidential information, or redistributed it, without the policies, capabilities and permissions approved for acting on a user's behalf.
4. Kept probing, accessing or modifying a production target after the operator knew or reasonably suspected the activity was unauthorized or outside approved scope.
5. Caused or materially contributed to consequential harm, or a credible near miss, to people, the operating organization, property or the environment, including through a failure to act when action was required. This explicitly covers embodied AI and physical control systems.

Several clarifications close loopholes. Intent does not decide reportability, and believing the environment was a simulation does not remove the duty to report. A chain of actions that together exceed the original authorization is in scope, and unauthorized changes to the files that define an agent's permissions or scope count as boundary failures.

Responsibility is shared along the chain. A deployer, host, model provider or tool provider reports what it knows and names the other responsible parties, and a provider that lacks certain records should say so.

Notification timelines

The clock starts at reasonable grounds to suspect a reportable event, not when an investigation concludes, and members record the basis for each timestamp. A preliminary report can be incomplete if it states the evidence gaps and the plan to close them.

SAFE neither replaces nor extends legal, contractual or coordinated disclosure deadlines; regulator reporting still runs on its own clock. Our post on the GDPR 72 hour clock for AI agent data incidents covers one of those overlaps.

Evidence preservation

This is the most practical section. Members must give affected organizations the evidence for a full forensic response, including:

• Agent execution traces and model reasoning traces, with the versions, identifiers and configurations that were observed.
• Environment records: runtime versions, images or build definitions identified by content digest, the agent's starting working directory including uncommitted changes, network paths and isolation boundaries, plus any differences between the intended, described and actually encountered environments.
• Prompts, including system prompts and tool definitions; tool calls and their results as delivered to the agent, noting any truncation; logs; and third party dependencies such as external tools, APIs, harnesses and serving artifacts.
• Credential identifiers, types, scopes and revocation status, but never reusable passwords, tokens or keys in reports. Secret values stay in restricted forensic custody.
• Human approvals and automated monitor approvals, with the originating principal, authorization source, delegation chain and approved scope.
• Files and artifacts created, changed or deleted, with location, time and previous state where available.
• Detection, containment and recovery events, kept separate from later replays. A new run must never silently replace missing original evidence.
• Sensor and actuator records for physical systems, and the languages involved for language dependent controls.

Every item gets a stable identifier and custody record, and a preliminary control failure analysis is due within 30 days.

Much of this list is software supply chain data: image digests, build definitions and dependency versions are what an SBOM and build record capture. Teams that keep those records will meet SAFE's evidence list far more easily.

The review framework

For every layer that applies, reviewers state the expected outcome, the evidence and one of four labels: pass, fail, insufficient evidence or not applicable. The labels describe one assessment and do not certify general safety or legal compliance.

The last three layers arrived in version 1.0, reflecting how agent incidents often come from chains of individually allowed steps, stale tokens or a misbehaving proxy.

The disclosure model and TLP

SAFE uses three disclosure tiers:

1. Confidential rapid alert: indicators, containment steps and affected patterns for members and other trusted recipients.
2. Member operating advisory: de-identified analysis, implicated controls, tests and recommended actions.
3. Public safety report: root causes, lessons, recommendations and adoption metrics after sensitive details are removed.

Sharing boundaries use FIRST's Traffic Light Protocol 2.0 (TLP:RED, TLP:AMBER, TLP:GREEN, TLP:CLEAR), which FIRST says is not a formal classification scheme. SAFE aims for findings to reach GREEN or CLEAR. Notably, embarrassment, reputational harm or commercial disadvantage alone does not justify withholding information. If you already handle TLP labels in security advisories, our explainer on CSAF and TLP labels shows how the same labels work in machine readable advisories.

From lessons to controls

Every review should end in recommendations naming the failure, the required outcome, a minimum control with alternatives, a reproducible verification method, the evidence to keep, an owner, a deadline and adoption metrics.

Where safe and lawful, SAFE plans to publish reusable tests, machine readable policies, detection rules and reference configurations in a shared, versioned catalog, with detection rules in open, vendor neutral formats.

For agents that reach real systems they should not, the document gives example controls: default deny network egress, explicit target allow lists, signed evaluation manifests, independent preflight isolation checks, real time action monitoring, automatic stops when scope is unclear, and equal assurance requirements for evaluation partners. That short list is a good baseline for any team running agents today.

How SAFE relates to other AI security efforts

SAFE does not compete with the frameworks most teams already use. Each one answers a different question.

SAFE and OpenSSF

The Linux Foundation says the Alliance's work runs alongside OpenSSF, and the Alliance site lists collaborating with OpenSSF on standards as a way to contribute. They are separate groups. OpenSSF's AI/ML Security Working Group studies how AI affects open source projects and adopters; its projects include OpenSSF Model Signing, a library and CLI for signing and verifying ML models, and OSS-CRS, a framework for LLM based bug finding and fixing systems.

The practical link is SAFE's supply chain layer: when a review asks whether a model or harness was what the team believed, signed artifacts and provenance records answer it. Our post on OpenSSF Model Signing v1.0 covers that tool in depth.

SAFE and the OWASP GenAI Security Project

The OWASP GenAI Security Project is a community effort producing free guidance on generative AI security. Its best known output is the Top 10 for LLM Applications. The 2025 list runs from LLM01 Prompt Injection through Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, and Misinformation to LLM10 Unbounded Consumption. On 2 September 2026 the project announced a 2026 edition of the Top 10, a new Agent Control Standard for agentic systems, and a community of more than 30,000 members. It also runs an AI Threat Intelligence and Response initiative and publishes quarterly roundups of AI exploits and incidents.

OWASP lists tell you what can go wrong; SAFE reviews tell you what did go wrong, in which layer, and which control would have caught it. Recurring SAFE findings about agents exceeding scope, for example, are evidence for how to weight Excessive Agency. For a deeper walk through the list, see our OWASP Top 10 for LLM applications explainer.

SAFE and the NIST AI RMF

NIST released the voluntary AI RMF 1.0 on 26 January 2023, organized into Govern, Map, Measure and Manage. NIST says it is being revised under the White House AI Action Plan, and in April 2026 it released a concept note for a critical infrastructure profile.

The subcategory that lines up with SAFE is MANAGE 4.3: incidents and errors are communicated to relevant AI actors, including affected communities, and processes for tracking, responding to and recovering from incidents are followed and documented. GOVERN 6.2, which asks for contingency processes to handle failures or incidents in third party data or AI systems deemed high risk, is another touchpoint. SAFE gives you a concrete way to do both, but you still need the rest of the framework. Our guide to AI risk management with the NIST AI RMF walks through the four functions.

SAFE and NIST AI 600-1

NIST AI 600-1, published 26 July 2024, lists twelve generative AI risks, including confabulation, data privacy, information security, and value chain and component integration. Its actions focus on four considerations: governance, content provenance, pre-deployment testing and incident disclosure.

Three parts of AI 600-1 read almost like a brief for SAFE:

• The incident disclosure appendix notes that formal channels for reporting AI incidents did not exist, and that greater standardization of reporting could improve risk management across the ecosystem.
• Suggested action MG-4.3-002 asks organizations to record and track reported errors, near misses and negative impacts. SAFE makes near misses reportable by design.
• It stresses logging, change records and version history for third party inputs and plugins, which SAFE's evidence list makes concrete.

Our explainer on the twelve generative AI risks in NIST AI 600-1 covers the risk list itself.

SAFE and CoSAI

The Coalition for Secure AI (CoSAI) is an OASIS Open project sharing best practices for secure AI deployment, with recent work on MCP security and AI supply chain artifact integrity. The Linux Foundation's SAFE post does not mention CoSAI and we found no stated relationship. Topics overlap, but they are separate bodies.

How to participate

The working group repository spells out the routes in.

Read and comment

1. Read SAFE.md (version 1.0), the original proposal in rfc-safe-proposal.md and CHANGELOG.md to see what changed between the August draft and the October release.
2. For substantive suggestions, open an issue so the community can discuss it first.
3. For minor fixes such as typos or broken links, send a pull request directly.

Contribute a change

The contributing guide asks for a fork, a branch, a Developer Certificate of Origin sign off on each commit, and a pull request with a clear description:

# Fork OpenSecureAIAlliance/wg-safe on GitHub first, then:
git clone https://github.com/<your-user>/wg-safe.git
cd wg-safe
git checkout -b clarify-near-miss-threshold

# edit SAFE.md or open a discussion issue instead for larger changes
git add SAFE.md
git commit -s -m "Clarify near-miss aggregation example"   # -s adds the DCO Signed-off-by line
git push origin clarify-near-miss-threshold
# then open a pull request against OpenSecureAIAlliance/wg-safe

Join the working group

• Introduce yourself in the working group channel on the Open Secure AI Alliance Slack; meeting schedules are announced there.
• Add yourself to the contributors table in MEMBERS.md with a pull request.
• If your organization wants to join the wider Alliance, the Alliance site has a join page. Remember that Alliance membership alone does not commit you to SAFE's reporting compact; participating in SAFE does.

Before committing, read the compact with legal and incident response leads; its deadlines are tighter than many internal processes.

Step by step: make your AI incident process SAFE ready

You can adopt SAFE's structure inside your own team today, whether or not you join. The steps below use generic tooling and are safe to run; none of them change production systems.

1. Write down approved scope for every agent

For each agent or AI workflow, record who authorized it, which actions, targets, resources and data it may use, for what purpose, until when, and whether it may delegate. Store it with the code, not in a wiki page nobody reads. A minimal YAML record might look like this:

# agents/release-bot/scope.yaml
agent: release-bot
accountable_owner: platform-security@yourco.example
approved_actions: [read_repo, open_pull_request, run_tests]
denied_actions: [push_to_main, publish_package, change_ci_secrets]
targets:
  repos: [yourco/api, yourco/web]
  network_egress: [registry.npmjs.org, pypi.org]
expires: 2027-01-31
delegation: none

SAFE treats unauthorized changes to files like this as boundary failures, so protect them with code owners and branch protection.

2. Capture environment evidence at the start of every agent session

SAFE asks for the working directory at session start, including uncommitted changes, and for images or build definitions identified by content digest. These commands collect that baseline for a repository based agent session:

SESSION=$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p evidence/$SESSION

# Working directory state, committed and uncommitted
git rev-parse HEAD                > evidence/$SESSION/head.txt
git status --porcelain=v1         > evidence/$SESSION/status.txt
git diff                          > evidence/$SESSION/uncommitted.patch

# Container image identity by digest, not by tag
docker image inspect --format '{{json .RepoDigests}}' your-agent-runtime:latest \
  > evidence/$SESSION/runtime-digest.json

# Dependency inventory for the workspace (Safeguard CLI writes JSON under ./output)
safeguard scan --dir .
cp -r output evidence/$SESSION/sbom

# Integrity hashes for everything collected
find evidence/$SESSION -type f -exec shasum -a 256 {} \; > evidence/$SESSION/SHA256SUMS

Store evidence where the agent cannot write.

3. Keep tool calls and approvals as structured logs

Log every tool call, its result as delivered (note truncation) and who approved it. Keep credential identifiers and scopes, never values, and keep permission prompts on for actions that touch shared systems.

4. Build an internal incident record that maps to SAFE's minimum fields

SAFE says submissions should use a versioned, machine readable minimum record where one is available, and structured narrative otherwise. Until an official schema is published, an internal record with the same fields keeps you ready. The structure below is our own illustration, not an official SAFE schema:

{
  "record_version": "internal-1",
  "reporting_contact": "ai-incidents@yourco.example",
  "tlp": "TLP:AMBER",
  "systems": [{"name": "release-bot", "model": "<model id>", "harness_version": "<version>"}],
  "incident_class": "scope_exceeded",
  "near_miss": true,
  "timeline": {
    "first_suspected": "2026-10-20T09:14:00Z",
    "affected_party_notified": "2026-10-20T10:02:00Z",
    "timestamp_basis": "alert from egress proxy log"
  },
  "containment": "agent token revoked; egress allow list tightened",
  "evidence": [{"id": "EV-001", "type": "tool_call_log", "sha256": "<hash>"}],
  "evidence_gaps": ["reasoning trace not retained for first 3 minutes"],
  "impact": {"severity": "low", "scale": "1 repository", "reversible": true},
  "next_update": "2026-10-27"
}

5. Run the eleven layer review on your last incident or near miss

Take your latest AI related incident and label each layer pass, fail, insufficient evidence or not applicable, with evidence. Expect early gaps in monitoring, serving path and supply chain records. For practice scenarios, our AI agent incident tabletop scenarios and AI incident response runbook for LLM applications are good starting points.

6. Turn each finding into a testable control

For each fail, write the recommendation the way SAFE does: the failure, the required outcome, the minimum control, a verification method you can rerun, an owner and a date. Then add the test to CI so it keeps running after the incident is closed.

Where Safeguard fits, honestly

Safeguard does not run an AI incident reporting service, and nothing here speaks for SAFE. Where we help is in producing the evidence and the controls SAFE asks for, mainly around the supply chain, serving path and tools layers. Maturity tags follow our product documentation.

• SBOMs and dependency inventory [GA]. SPDX and CycloneDX SBOMs for repositories, images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), answering which dependencies were present, plus which projects contain a given component version.
• Model scanning for LLMs, SLMs, skills and agents [GA] and AI-BOM discovery [EA], an inventory of the models and skills you run; early access, so depth varies.
• MCP Guardrail [GA] and agent identity [GA]. Proxy URLs in front of MCP servers, and tracking of which agent holds what access, for the tools and authorization layers.
• AI Gateway with prompt injection, jailbreak and PII egress guardrails [EA]. This sits in the serving path layer. It is early access.
• Policies and gates [GA] at build, CI and release, to make a recommendation stick, and a compliance suite [GA] whose framework library includes the NIST AI RMF.
• The Safeguard CLI's assistant runs commands only with your approval, with /permissions modes from Ask to Strict, leaving the approval trail SAFE asks for.

Where Safeguard does not help: it does not collect reasoning traces from third party AI services, file reports with SAFE or regulators, or decide whether an event meets SAFE's threshold.

Common mistakes

• Treating SAFE as a risk list. It is a reporting and learning process. Use OWASP or AI 600-1 for risks, and SAFE to learn which ones actually bite.
• Confusing Alliance membership with SAFE duties. Participation in SAFE, not Alliance membership, triggers the compact.
• Starting the clock at confirmation. Deadlines run from reasonable grounds to suspect, so waiting for certainty can blow the 72 hour notice.
• Skipping near misses. A blocked action that a backup control caught is a near miss. Only routine attempts with no control failure can be aggregated.
• Putting secrets in incident reports. Record credential identifiers and scopes, never the values.
• Rerunning the agent and calling it evidence. SAFE separates original observations from later replays.
• Recording images by tag. Tags move; record content digests.
• Assuming SAFE overrides legal duties. Regulatory and contractual deadlines still apply.
• Letting the task define the scope. "Test everything" does not widen approved scope. Write scope down first.

FAQ

What does SAFE stand for in AI security?

SAFE stands for Shared AI Findings Exchange. It is a working group of the Open Secure AI Alliance, hosted at the Linux Foundation, that confidentially collects and reviews AI incidents and near misses and publishes shared defensive controls.

Is the SAFE Working Group part of OpenSSF?

No. SAFE belongs to the Open Secure AI Alliance, which joined the Linux Foundation in September 2026. The Linux Foundation says the Alliance's work runs alongside OpenSSF, and the Alliance lists collaboration with OpenSSF on standards as a way to contribute, but they are separate groups.

Is SAFE a regulation or a legal requirement?

No. SAFE is voluntary. Members accept its reporting duties by participating, and the document states that it does not replace or extend legal, contractual or coordinated disclosure obligations.

What counts as a reportable AI incident under SAFE?

Unauthorized access to or modification of third party systems, escaping a sandbox or safety system with third party impact, reaching third party confidential data without approved permissions, continuing after learning activity is out of scope, and consequential harm or a credible near miss to people, the organization, property or the environment.

How fast do SAFE members have to report?

Directly affected organizations are notified immediately, customers with credible exposure within 72 hours, and SAFE within 4 business days, followed by a 14 day advisory when warranted, a 30 day preliminary factual report and 90 day remediation status, subject to legal and security constraints.

Does SAFE apply to open weight models or only to proprietary AI?

Both. SAFE's processes apply equally to open and closed AI systems, and its membership explicitly includes proprietary and open weight model creators as well as fine tuning and quantization groups.

How does SAFE relate to the NIST AI RMF and AI 600-1?

SAFE gives you a concrete way to carry out the AI RMF's MANAGE 4.3 subcategory on communicating incidents, and it responds directly to AI 600-1's observation that formal AI incident reporting channels did not exist. It does not replace either framework.

How is SAFE different from the OWASP Top 10 for LLM Applications?

The OWASP list describes the most important risks and mitigations for LLM applications. SAFE reviews real incidents and turns them into tested controls. They work best together: OWASP for design and testing, SAFE for learning from what happened.

How do I join the SAFE Working Group?

Read the spec in the OpenSecureAIAlliance/wg-safe GitHub repository, introduce yourself in the working group channel on the Alliance Slack, open issues or DCO signed pull requests, and add yourself to the contributors table in MEMBERS.md.

Fix it without waiting for upstream

SAFE's review framework lists supply chain and serving path as their own control layers, because agent harnesses, model servers, MCP servers and gateways are built from open source packages and container images. When a review concludes that a dependency in the harness was vulnerable, the fix is a dependency upgrade or a patched build, which is where the following applies.

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.

See how Safeguard would help

None of these demos show SAFE itself. They show an assistant working under human approval, narrowed tool access and local scanning, the habits SAFE's tools, authorization and supply chain layers check. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli . For more on how agents fail, see CERT-In's advisory on AI agent attack vectors and whether AI agents can escape their sandbox.

This first 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. Each approval is the kind of record SAFE asks you to keep. More background is in the Safeguard CLI overview.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Choosing tools per connection is a small version of SAFE's approved scope.

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, and then scans from the terminal. That is how you would produce the dependency inventory for the evidence folder in step 2.

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

Quick check

Sources

• Linux Foundation: Proposing the SAFE Working Group, an open community effort to improve AI security (4 August 2026)
• Linux Foundation: Open Secure AI Alliance joins the Linux Foundation (14 September 2026)
• Open Secure AI Alliance: SAFE Working Group repository (wg-safe)
• SAFE v1.0 specification (SAFE.md)
• SAFE original RFC (rfc-safe-proposal.md)
• SAFE changelog
• SAFE contributing guide
• SAFE members file
• Open Secure AI Alliance website
• NVIDIA blog: Open Secure AI Alliance contributions (4 August 2026)
• NASA Aviation Safety Reporting System
• NASA ASRS: Confidentiality and incentives to report
• FIRST: Traffic Light Protocol 2.0
• NIST: AI Risk Management Framework
• NIST AI 100-1: AI Risk Management Framework 1.0 (PDF)
• NIST AI 600-1: Generative AI Profile, publication page
• NIST AI 600-1 (PDF)
• OWASP GenAI Security Project
• OWASP Top 10 for LLM Applications
• OWASP GenAI: 2026 Top 10 for LLM Applications and Agent Control Standard announcement
• OWASP GenAI: AI Threat Intelligence initiative
• OpenSSF: AI/ML Security
• Coalition for Secure AI (CoSAI)

Last reviewed: 23 October 2026. SAFE version 1.0 is new and its charter is still being drafted; check the wg-safe repository for the current text before relying on any deadline or definition.