Google SAIF - the controls layer

SAIF answers one question the risk frameworks deliberately leave open: given an AI system, which concrete safeguards do you build? This page is the full working map of Google’s Secure AI Framework - every element, component, risk, and control - written so you can run it against a real deployment.

The core idea

• SAIF is a controls framework - it tells you what safeguards to build. It is voluntary and not certifiable. Pair it with a risk process (NIST AI RMF or ISO/IEC 23894) and a management system (ISO/IEC 42001) - see how they stack in VIII.1 · Frameworks & standards.
• It covers the whole lifecycle, not just the model - data, infrastructure, model, and application - and distinguishes two audiences: model creators and model consumers.
• The payoff is the Risk Map: map your system to four components, run the questionnaire, and every flagged risk traces to specific controls you can go implement.

What SAIF is - and the three layers people conflate

Google introduced SAIF on 8 June 2023 as “a conceptual framework for secure AI systems,” built on its security-by-default heritage (SLSA for supply-chain integrity, BeyondCorp for zero trust). It is positioned today as “a practitioner’s guide to navigating AI security” (saif.google; Introducing SAIF).

Three distinct things all wear the “SAIF” label - do not conflate them:

Layer	What it is	Where it lives
The six core elements	2023 strategic posture - the “why” and the high-level moves	The launch blog post
The operational framework	Components -> risks -> controls -> Risk Map -> self-assessment	saif.google/secure-ai-framework
SAIF 2.0	Oct 2025 extension for agentic systems (Agent Risk Map + agent principles)	The 2025 strategy blog + Cloud

The operational framework is the one you do. The core elements are the posture it sits inside.

The six core elements

These are Google’s original strategic elements, quoted verbatim from the launch post. Read each as “extend the security discipline you already have to cover AI.”

#	Element (verbatim)	What it means in practice
1	”Expand strong security foundations to the AI ecosystem”	Your existing AppSec, IAM, and supply-chain controls apply to AI - start there, do not reinvent
2	”Extend detection and response to bring AI into an organization’s threat universe”	Put AI systems in scope for your SOC, threat intel, and IR - not a separate silo
3	”Automate defenses to keep pace with existing and new threats”	Attackers use AI at machine speed; your defenses must too
4	”Harmonize platform level controls to ensure consistent security across the organization”	One control plane across AI systems, not per-team snowflakes
5	”Adapt controls to adjust mitigations and create faster feedback loops for AI deployment”	Red-team, learn, and push mitigations continuously - AI risk is non-stationary
6	”Contextualize AI system risks in surrounding business processes”	Risk is a function of the business process the model sits in, not the model alone

The four components

SAIF structures a generative-AI system into four component areas - “the broadened scope of AI development compared to traditional software development” (components). This is the coordinate system for everything else: risks and controls are hung off these four areas.

Component	Sub-components	The security question
Data	Data Sources · Data Filtering & Processing · Training Data	Can you trust what went into the model?
Infrastructure	Model Frameworks & Code · Training, Tuning & Evaluation · Data & Model Storage · Model Serving	Can the pipeline and its artifacts be tampered with?
Model	The Model · Input Handling · Output Handling	Can the model itself be manipulated or leaked?
Application	Application · Agent	Can the surface around the model be abused, and can an agent act badly?

The fifteen risks

Every SAIF risk carries a short code - learn the codes, because the controls and Risk Map reference them (risks). Grouped by the component that introduces them:

Component	Risk (code)
Data	Data Poisoning (DP) · Unauthorized Training Data (UTD) · Excessive Data Handling (EDH)
Infrastructure	Model Source Tampering (MST) · Model Exfiltration (MXF) · Model Deployment Tampering (MDT) · Denial of ML Service (DMS)
Model	Model Reverse Engineering (MRE) · Prompt Injection (PIJ) · Model Evasion (MEV) · Sensitive Data Disclosure (SDD) · Inferred Sensitive Data (ISD)
Application	Insecure Integrated Component (IIC) · Insecure Model Output (IMO) · Rogue Actions (RA)

Read the codes against the offense sections

These fifteen are the same attacks the offense pillar teaches - just governance-tagged. PIJ is prompt injection (II.2 · Prompt injection & the LLM attack surface); DP is data poisoning (I.3 · Training data); MXF is model extraction (I.4 · Adversarial machine learning); RA is the agent acting on a hijacked goal (III.4 · Persistence & propagation). The value of the code is that it lets you say “we tested PIJ and MEV, we did not test MDT” in a language a board and an auditor both accept.

Model creator vs model consumer - what a pure consumer can descope

SAIF tags every risk with the persona that can mitigate it. A model creator trains or fine-tunes the model; a model consumer builds a product on someone else’s model (a hosted API, a downloaded open-weight checkpoint). Most enterprises are pure consumers, and SAIF lets them formally descope the risks they cannot touch - as long as the residual responsibility is understood.

SAIF persona attribution	Risks (codes)	What it means for a pure consumer
Creator-only	DP · UTD · MST · EDH	Descope. You never see the training pipeline, so you cannot poison it, mishandle training data, or tamper with model source. Push these onto the provider via procurement (model card, provenance attestation, ML-BOM).
Both	MXF · MDT · PIJ · MEV · SDD · ISD	Shared. The creator hardens the base model; you still own the deployed copy, the prompt boundary, and what leaks at your inference surface.
Consumer-only	DMS · MRE · IIC · IMO · RA	Fully yours. Serving availability, query-based extraction of your endpoint, insecure plugins/tools you wired in, unvalidated model output, and agent rogue actions are all your build.

The residual for a consumer is bigger than it looks

Descoping the four creator-only risks does not shrink the Assurance and Governance categories - those still apply to all fifteen because a consumer must red-team, detect, and respond on the deployed system regardless of who trained it. And the “both” risks are where consumers get caught: you cannot fix Prompt Injection (PIJ) or Sensitive Data Disclosure (SDD) in the base weights, but you own every consequence of them at your surface. Treat provider attestations as evidence for the creator-only risks, not as a transfer of liability.

The SAIF Risk Map

The Risk Map is the interactive diagram that ties it together - “how different security risks are introduced, exploited and mitigated throughout the AI development process.” Its key insight is that each risk has a path, tracked across three dimensions:

• Introduced - where in the lifecycle the risk enters (e.g. Data Poisoning can enter at ingest, processing, training, or storage).
• Exposed - where it becomes exploitable.
• Mitigated - where a control can actually stop it.

flowchart TB
  subgraph DATA["Data"]
    A["Data Sources"] --> B["Filtering and<br/>Processing"] --> C["Training Data"]
  end
  subgraph INFRA["Infrastructure"]
    C --> D["Training /<br/>Tuning / Eval"] --> E["Data and Model<br/>Storage"] --> F["Model Serving"]
  end
  subgraph MODEL["Model"]
    F --> G["The Model"]
    G --> H["Input Handling"]
    G --> I["Output Handling"]
  end
  subgraph APP["Application"]
    H --> J["Application"] --> K["Agent"]
    I --> J
  end
  classDef n fill:#1c2436,stroke:#84b6ff,color:#dbe6ff;
  class A,B,C,D,E,F,G,H,I,J,K n;

Two properties matter for how you defend:

• Risks are not siloed. Data Poisoning (DP) spans ingest, processing, training, and storage - so a single control point is never enough. Sensitive Data Disclosure (SDD) explicitly needs “multi-layered” defenses.
• Some risks are inherent. Google flags Prompt Injection (PIJ) and Model Evasion (MEV) as inherent to how models work - you manage them, you do not eliminate them. Plan for detection and containment, not a silver bullet.

The six control categories

SAIF’s controls are grouped into six categories - four aligned to the components, plus two cross-cutting categories (Assurance and Governance) that apply to every risk. Each control names the risks it addresses, so you can work backward from a flagged risk to the exact control to build.

Category	Control -> risks it mitigates
Data	Privacy Enhancing Technologies -> SDD · Training Data Management -> ISD, UTD · Training Data Sanitization -> DP, UTD · User Data Management -> SDD, EDH
Infrastructure	Model & Data Inventory Mgmt -> DP, MST, MXF · Model & Data Access Controls -> DP, MST, MXF · Model & Data Integrity Mgmt -> DP, MST · Secure-by-Default ML Tooling -> DP, MST, MXF, MDT
Model	Input Validation & Sanitization -> PIJ · Output Validation & Sanitization -> PIJ, RA, SDD, ISD · Adversarial Training & Testing -> MEV, PIJ, SDD, ISD, IMO
Application	Application Access Mgmt -> DMS, MRE · User Transparency & Controls -> SDD, EDH · Agent User Control -> SDD, RA · Agent Permissions -> IIC, SDD, RA · Agent Observability -> SDD, RA
Assurance (all risks)	Red Teaming · Vulnerability Management · Threat Detection · Incident Response Management
Governance (all risks)	User Policies & Education · Internal Policies & Education · Product Governance · Risk Governance

The control names alone are opaque; here is what each of the less-obvious ones actually does, quoting SAIF’s own one-line definitions (controls).

Data controls:

Control	What it does
Privacy Enhancing Technologies	Minimize, de-identify, or restrict use of PII in training or evaluation (differential privacy, redaction, tokenization)
Training Data Management	Ensure all data used to train and evaluate models is authorized for the intended purpose (provenance, licensing, consent)
Training Data Sanitization	Detect and remove or remediate poisoned or sensitive data in training and evaluation sets
User Data Management	Store, process, and use runtime user data (prompts, logs) in compliance with user consent

Assurance controls (all four are cross-cutting - they apply to every one of the fifteen risks):

Control	What it does
Red Teaming	Find security and privacy weaknesses through self-driven adversarial attacks on the AI system
Vulnerability Management	Continuously test and monitor production AI infrastructure and products for security/privacy regressions
Threat Detection	Detect and alert on internal or external attacks against AI assets, infrastructure, and products
Incident Response Management	Manage the organizational response to AI security and privacy incidents

Governance controls (also cross-cutting):

Control	What it does
User Policies & Education	Publish clear, user-facing AI security and privacy policies and guidance
Internal Policies & Education	Publish comprehensive AI security and privacy policies and training for your own employees
Product Governance	Validate that every AI model and product meets the organization’s established security/privacy requirements before ship
Risk Governance	Inventory, measure, and monitor residual AI risk across the organization

The Assurance category is where this book lives

The four Assurance controls - Red Teaming, Vulnerability Management, Threat Detection, Incident Response - are cross-cutting because they apply to all fifteen risks. The entire offense pillar (Part II) is an expansion of SAIF’s “Red Teaming” control; the defense pillar (Part III) expands “Threat Detection” and “Incident Response.” SAIF names them; this book tells you how to execute them.

The SAIF Risk Assessment

Launched 24 October 2024, the SAIF Risk Assessment is “a questionnaire-based tool that will generate an instant and tailored checklist.” It asks about your training/tuning/evaluation setup, access controls, adversarial-input prevention, secure design and coding practices, and any generative-AI agents. It then produces a report that, for each of the fifteen risks:

1. States whether the risk applies to your system, and why.
2. Gives the technical detail behind it.
3. Names the mitigating controls, linked into the Risk Map so you can see where they act.

This is the fastest path from “we have an AI system” to “here is our prioritized control gap list.” Run it at design time and re-run it whenever the architecture changes.

Worked example - a support-ticket RAG agent

Take a concrete system: an internal support agent built on a hosted LLM API, with retrieval over the company’s ticket history and a tool that can issue refunds. Map it to the four components, then run it through the Risk Assessment logic.

Component	This system’s instance
Data	Not trained by us - we consume a hosted model. Our only “data” is the RAG corpus (ticket history) and runtime prompts/logs.
Infrastructure	Provider’s serving stack (opaque to us) + our vector store + our orchestration service.
Model	Third-party hosted model; we control Input Handling (prompt assembly, retrieved context) and Output Handling (response parsing).
Application	The support app and an agent that calls a refund tool - so the Agent sub-component is live.

Because we are a pure consumer, the four creator-only risks (DP, UTD, MST, EDH) descope to the provider. Running the questionnaire flags the risks that survive - here are three, with the controls that fire:

Flagged risk	Why it applies here	Controls that fire
Prompt Injection (PIJ)	Retrieved tickets are untrusted text that reaches the model; a malicious ticket can carry injected instructions.	Input Validation & Sanitization; Output Validation & Sanitization; Adversarial Training & Testing (red-team the RAG path)
Rogue Actions (RA)	The agent can issue refunds - a hijacked goal (via PIJ) turns into unauthorized money movement.	Agent Permissions (allowlist + refund cap); Agent User Control (human approval on refunds); Agent Observability (log every tool call); Output Validation
Sensitive Data Disclosure (SDD)	Ticket history contains customer PII that can surface in an answer to the wrong user.	Privacy Enhancing Technologies; Output Validation & Sanitization; User Transparency & Controls; User Data Management

The chain is the point: PIJ (inherent, cannot be eliminated) is the entry, RA is the impact, and the fired controls cluster on the Model and Application boundaries - exactly where a consumer’s residual responsibility sits. The Assurance controls (Red Teaming this PIJ->RA path, Threat Detection on the refund tool) apply on top, as always.

SAIF 2.0 - the agent extension

In October 2025 Google extended SAIF for agentic systems (AI security strategy, Oct 2025; Cloud SAIF). SAIF 2.0 adds:

1. An Agent Risk Map - the Risk Map extended with agent-specific paths.
2. Security capabilities built across Google’s own agents.
3. Three agent principles that should govern any agent you deploy:

Agents must have well-defined human controllers, their powers must be carefully limited, and their actions and planning must be observable.

Those three principles map directly onto the SAIF Application controls: Agent User Control (well-defined human controller), Agent Permissions (powers carefully limited), and Agent Observability (actions and planning observable). If you build agents, these three controls are non-negotiable - they are the concrete implementation of the principles, and they line up with the agentic threats in III.4 · Persistence & propagation and the MCP guidance in IV.2 · Model Context Protocol (MCP).

CoSAI - where SAIF becomes vendor-neutral

SAIF is a Google framework; CoSAI is the industry standardization path that keeps it from being one vendor’s dialect.

• The Coalition for Secure AI was founded 18 July 2024 at the Aspen Security Forum, housed under OASIS Open as an Open Project. Founding members span Amazon, Anthropic, Cisco, Cohere, IBM, Intel, Microsoft, NVIDIA, OpenAI, PayPal, Wiz, and Google (Introducing CoSAI).
• By July 2025 it added an Agentic AI Security workstream and released “Principles for Secure-by-Design Agentic Systems” - Human-governed & Accountable, Bounded & Resilient, Transparent & Verifiable - which mirror SAIF 2.0’s three agent principles (CoSAI first anniversary).
• On 16 September 2025 Google donated the SAIF data - as the CoSAI Risk Map (CoSAI-RM) - to CoSAI, making it a vendor-neutral common language (Google donates SAIF data).
• On 18 November 2025 CoSAI released actionable frameworks for AI model signing and incident response (CoSAI frameworks).
• As of mid-2026, CoSAI-RM plus the model-signing and incident-response frameworks (Nov 2025), and 2026 workstream papers on agentic security and agentic identity and access, are the current deliverables - check oasis-open.org for newer workstream releases before you cite them.

Practical takeaway: if you need a portable, non-Google-branded control taxonomy for a mixed-vendor program or a procurement conversation, cite CoSAI-RM rather than “Google SAIF” - it is the same map, governed neutrally.

How to apply SAIF - the workflow

Applying SAIF to a real deployment - the concrete artifact per step

# 1. MAP the system to the four components -> produce an ML-BOM / inventory
#    (Data / Infrastructure / Model / Application), e.g. CycloneDX ML-BOM:
cyclonedx-py environment -o mlbom.json          # deps; add model + dataset refs

# 2. RUN the SAIF Risk Assessment questionnaire at saif.google
#    -> export the tailored checklist of which of the 15 risks apply, and why

# 3. SCAN the model artifacts before you trust them (MST / DP integrity):
modelscan -p ./models/<model.pkl>               # unsafe deserialization, MST
fickling --check-safety ./models/<model.pkl>    # pickle payloads that run on load

# 4. IMPLEMENT + EVIDENCE the mapped controls
#    Assurance: red-team the PIJ / MEV / RA risks
garak --model_type rest -G rest.json --probes promptinject,dan
#    Infrastructure: sign the model so MST / MXF tampering is detectable
cosign sign-blob --key <cosign.key> ./models/<model> > model.sig

# 5. FOR AGENTS: enforce the SAIF 2.0 Application controls -
#    Agent Permissions (allowlist the tools an agent may call),
#    Agent User Control (human approval on irreversible actions),
#    Agent Observability (log every tool-call to the SIEM)

# 6. FOR PORTABILITY: re-express the gap list in CoSAI-RM terms
#    so a mixed-vendor program and an auditor read the same map

Where SAIF hands off

SAIF gives you the controls. It does not give you the risk-tolerance gates that decide whether a control gap blocks a launch, nor the auditable management system that proves you run it consistently. For the first, go to NIST AI RMF (GOVERN sets tolerance, MANAGE decides deploy/no-deploy). For the second, go to ISO/IEC 42001 in VIII.4 · ISO/IEC 42001, verification & maturity. The one-finding-many-frameworks crosswalk in VIII.1 · Frameworks & standards shows every SAIF risk in its NIST, ISO, and EU AI Act contexts.