Google's Secure AI Framework (SAIF), explained

Google's announcement is explicit about scope: AI systems introduce risk categories a conventional application-security program doesn't have fields for, including theft of the model itself, poisoning of training data, prompt injection attacks that manipulate a model's behavior through crafted input, and extraction of confidential information embedded in training data. Rather than treating these as entirely novel problems requiring a new discipline from scratch, SAIF's stated approach borrows directly from practices Google had already applied to software supply-chain security — the same thinking behind frameworks like SLSA — and extends them to cover AI-specific threat models. This is the same overlapping-but-distinct territory covered in our guide to MITRE ATLAS, which catalogs the adversary tactics and techniques (including prompt injection) that SAIF's elements are meant to defend against, and our guide to the OWASP Top 10 for LLM Applications, which enumerates the same risk classes from an application-security angle.

Per Google's own current SAIF page, the six elements are:

Google states these elements are not meant to be worked through in a fixed order — an organization can start wherever its existing security program has the most relevant foundation, similar to how NIST frames its own AI Risk Management Framework functions as non-sequential.

Six conceptual elements are only useful if an organization can turn them into specific action, which is what Google's SAIF Risk Assessment tool, launched 24 October 2024 at saif.google, is built to do. It is a free, questionnaire-based self-assessment: an organization answers questions covering its model training, tuning and evaluation setup, access controls, defenses against adversarial inputs, secure design and coding practices, and any generative-AI agents it runs, and receives a tailored report identifying which specific risks apply — categories reported at launch include data poisoning, prompt injection and model-source tampering — along with Google's recommended controls for each. For a device or firmware vendor that already runs a structured firmware or SBOM-based security assessment, the SAIF Risk Assessment is a comparable but AI-specific input: a way to get a scoped, written list of AI risks and controls without first having to build that taxonomy internally.

No — CoSAI (the Coalition for Secure AI) is a distinct, multi-vendor body that Google helped establish to carry SAIF's ideas beyond a single company's framework. Per OASIS Open's own announcement, CoSAI was introduced on 18 July 2024 at the Aspen Security Forum as an OASIS Open Project, with founding members spanning Google, Amazon, Anthropic, Chainguard, Cisco, Cohere, GenLab, IBM, Intel, Microsoft, NVIDIA, OpenAI, PayPal and Wiz. Google's own announcement draws the connection explicitly: "last year we shared the Secure AI Framework (SAIF), knowing that it was just the first step... to operationalize any industry framework requires close collaboration with others — and above all a forum to make that happen." CoSAI's initial workstreams — software supply chain security for AI systems, preparing defenders for AI-era threats, and AI security governance (building a shared risk taxonomy, checklist and scorecard) — extend SAIF's six elements into deliverables developed and maintained collaboratively across the coalition's member organizations rather than published unilaterally by Google. By its first anniversary in July 2025, per OASIS's own follow-up announcement, CoSAI had grown to more than 45 partner organizations and had published additional work on agentic-system security principles and defender frameworks.

SAIF was written with general enterprise and cloud AI deployments in mind, not embedded or on-device AI specifically — but its six elements translate reasonably well as a checklist for a device maker building or embedding ML components into a product. Element 1 (extending security foundations to the AI ecosystem) maps onto treating an embedded model and its inference runtime as first-class inventory, the same gap our guide to AI-BOM for embedded AI devices covers. Element 2 (extending detection and response) means a device's existing monitoring and incident-response processes need to actually cover anomalous model behavior, not just conventional firmware alerts. Element 6 (contextualizing AI risk in business processes) is a useful forcing function for asking what a misbehaving on-device model could actually do in the physical world a connected device operates in — a different, often higher-stakes question than it is for a purely cloud-hosted model. None of this makes a device vendor "SAIF-certified" — there is no such certification — but running the free SAIF Risk Assessment tool alongside an existing firmware security review is a low-cost way to surface AI-specific gaps a conventional firmware assessment wouldn't catch on its own.

SoftWSP's device and firmware security work already looks for embedded models, inference runtimes and AI-related credentials as part of a firmware assessment; see device & firmware security services for how that scope can be extended to check against SAIF's six elements or CoSAI's emerging governance checklist alongside conventional firmware vulnerability classes.

This guide is based on Google's own Safety Center SAIF page and original 8 June 2023 announcement (both fetched directly), Google's CoSAI announcement and OASIS Open's own CoSAI announcement and first-anniversary update (fetched directly), and contemporaneous SecurityWeek reporting used to cross-check dates and founding-member lists. It is not a substitute for Google's or OASIS's own current SAIF/CoSAI materials and does not constitute security or compliance advice; SAIF 2.0 and agent-specific risk-map details reported elsewhere were not independently re-verified against a primary Google source in this research pass and should be confirmed directly at saif.google before being cited as current.