Capability Overview
One week after its founding, the Open Secure AI Alliance (OSAA) — spearheaded by Nvidia and now comprising over 120 companies including Adobe, Cisco, Microsoft, BlackRock, and Visa — has produced its first tangible output: the Shared AI Findings Exchange (SAFE). Announced at Black Hat 2026 and managed by the Linux Foundation, SAFE is a proposed framework covering confidential AI cybersecurity incident reporting, affected-party notification, and blame-free post-incident analysis. In parallel, members are cataloguing open-source AI security tooling, with notable contributions including Nvidia’s Garak LLM vulnerability scanner, Okta’s agent identity primitives, Red Hat’s agent governance work, Amazon’s Strands Agents builder, and the Cedar authorisation language.
For defenders, this represents both an opportunity and a new attack surface to internalise. A shared industry-wide disclosure and tooling ecosystem raises the security floor for participating organisations — but it also creates concentrated, high-value targets that did not previously exist.
Attack Surface Analysis
Centralised disclosure as an intelligence windfall. The SAFE platform will aggregate knowledge of unpatched AI vulnerabilities across 120+ organisations. Any adversary who can read, delay, or manipulate submissions gains advance warning of exploitable conditions before affected parties complete remediation. The coordinated disclosure timing window — always a challenge in traditional CVE processes — becomes significantly more complex when AI model vulnerabilities involve retraining cycles measured in weeks or months rather than software patches measured in days.
Supply chain monoculture via shared tooling catalogue. Consolidating open-source AI security tools under a single discoverable catalogue means a successful supply chain compromise of one catalogued package (e.g., a malicious update to Garak) propagates across the entire member ecosystem simultaneously. This is a textbook AML.T0010 scenario at industrial scale.
Inadvertent model intelligence disclosure. Blame-free incident analysis submissions, however well-intentioned, may contain details about model architecture, fine-tuning datasets, or deployment topology. With 120 companies contributing and the Linux Foundation managing proposals for open comment, access controls on sensitive submission fields will be critical and are not yet publicly specified.
Agent identity and authorisation monoculture. Standardising agent identity (Okta) and authorisation (Cedar) primitives across a large member base is operationally sensible but creates a single point of failure. A zero-day against the shared identity layer would affect the entire ecosystem rather than a single vendor’s customers.
Notable membership gaps create blind spots. Anthropic, OpenAI, and Google are absent from membership. This means vulnerability intelligence surfaced through SAFE will not automatically reach operators running those providers’ models, fragmenting the protection the framework is designed to deliver.
Framework Mapping
- AML.T0010 (ML Supply Chain Compromise): The shared open-source tool catalogue is a direct supply chain attack surface.
- AML.T0019 (Publish Poisoned Datasets): Actors could submit corrupted or misleading incident data to SAFE, poisoning the collective knowledge base.
- AML.T0057 (LLM Data Leakage): Incident submissions may inadvertently expose sensitive model or deployment details.
- LLM05 (Supply Chain Vulnerabilities): Directly applicable to the catalogued tooling ecosystem.
- LLM06 (Sensitive Information Disclosure): SAFE’s open-comment process could expose proprietary incident details if access controls are insufficiently granular.
- LLM09 (Overreliance): Member organisations may over-rely on SAFE coverage without independently tracking non-member lab vulnerabilities.
Threat Scenarios
Scenario 1 — Garak poisoning: A threat actor submits a malicious pull request to the Garak repository shortly after it gains prominence through the OSAA catalogue. Security teams across dozens of member organisations integrate the compromised scanner into their pipelines, inadvertently introducing a backdoor into their AI security tooling.
Scenario 2 — SAFE intelligence harvest: A nation-state actor infiltrates a smaller OSAA member with weak access controls to read draft SAFE submissions. They extract details of an unpatched LLM prompt injection vulnerability affecting a major financial services member and exploit it before the disclosure cycle completes.
Scenario 3 — Cedar authorisation bypass: A zero-day in the shared Cedar authorisation language is discovered by a cybercriminal group. Because Cedar has been standardised across multiple OSAA members’ agent deployments, the exploit achieves immediate lateral reach across the ecosystem.
Defender Checklist
- Verify cryptographic integrity and provenance of all OSAA-catalogued tools before pipeline integration
- Define and enforce internal data classification policies for SAFE incident submissions — strip model architecture and topology details before submission
- Do not treat SAFE membership as a complete threat-intel solution; maintain independent feeds covering Anthropic, OpenAI, and Google vulnerability disclosures
- Review access control architecture for any shared Cedar or Okta agent identity primitives before broad deployment
- Monitor OSAA and Linux Foundation repositories for unusual commit patterns or dependency changes indicative of supply chain compromise
- Assign an internal owner to track SAFE’s evolving access control and governance specifications as they move from proposal to standard