Google Secure AI Framework (SAIF) Guide

Teams adopting AI know they should "secure it", but without a shared map of where risks enter the AI lifecycle and who owns each control, model builders and application teams each assume the other has it covered. Google's Secure AI Framework (SAIF) provides that map: six core elements for the security programme, a risk map of AI development components, 15 named risks each tied to responsible parties and controls, and specific guidance and a self-assessment for agents. This guide explains each part, shows how to turn SAIF into a working control set with clear ownership, covers the identity controls agents need, and maps SAIF to other frameworks. It is written for security architects, AI product owners and governance leads, whichever cloud or model provider they use.

This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

SAIF has three working layers. Six core elements frame the security programme, the SAIF Map shows where risks enter the AI lifecycle, and the risk and control catalogue says what to do and who does it.
Ownership is built in. Each of the 15 risks and each control names whether the Model Creator, the Model Consumer or both are responsible, which makes it a practical shared responsibility tool.
Agents get their own controls. Agent Permissions, Agent User Control and Agent Observability address Rogue Actions and Sensitive Data Disclosure, the two risks the Agent Risk Self Assessment focuses on.
Three agent principles anchor the design. Google's agent paper says agents must have well-defined human controllers, carefully limited powers, and observable actions and planning.
It is guidance, not a product description. The SAIF site states its content is for information and industry advancement and does not reflect Google's current technical implementations, so it applies to any platform.

What it is and who it applies to

Google introduced SAIF on 8 June 2023 and now publishes it at saif.google. Google has shared the SAIF Risk Assessment, the SAIF Risk Map and the associated risk, control and component descriptions with the Coalition for Secure AI (CoSAI), so SAIF material also informs that industry effort. See the CoSAI Frameworks and Workstreams Guide.

SAIF uses two roles throughout, and knowing which one you are drives everything else:

Model Creator: an organisation that trains, tunes or builds models. It owns data, training and most infrastructure controls.
Model Consumer: an organisation that builds applications or agents on models it did not train. It owns application, agent and most runtime controls, and shares responsibility for some infrastructure controls if it stores models.

Many organisations are both: a company that fine-tunes an open model and deploys it in an agent carries creator and consumer duties. SAIF's agent material covers systems that take actions through tools.

Structure and key requirements

The six core elements

The original announcement set out six core elements, which work as programme-level objectives:

Core element	What it means in practice (our reading)
Expand strong security foundations to the AI ecosystem	Apply existing identity, infrastructure, supply chain and data controls to AI assets rather than starting again
Extend detection and response to bring AI into an organisation's threat universe	Log AI inputs, outputs and agent actions, and give the SOC AI-specific detections and playbooks
Automate defences to keep pace with existing and new threats	Use automation, including AI, for detection and response at scale
Harmonise platform level controls to ensure consistent security across the organisation	Offer one approved set of AI platforms and guardrails instead of per-team builds
Adapt controls to adjust mitigations and create faster feedback loops for AI deployment	Red team, test and feed findings back into controls continuously
Contextualise AI system risks in surrounding business processes	Assess each AI use in its business process, with end-to-end risk ownership

The SAIF Map

The SAIF Map presents AI development through a security lens across four component areas: Data, Infrastructure, Model and Application. It traces the lifecycle from data ingestion and processing through training, tuning and evaluation, storage, serving and deployment to application and model use, and shows agent and plugin components, orchestration (tools, memory and retrieved data) and the reasoning core in agentic systems. Each risk is placed where it is introduced, where it is exposed and where it can be mitigated, which is often three different places owned by three different teams.

The 15 risks and their controls

SAIF risk	Responsible	Controls named by SAIF
Data Poisoning	Creator	Training Data Sanitization; Secure-by-Default ML Tooling; Model and Data Integrity Management; Model and Data Access Control; Model and Data Inventory Management
Unauthorized Training Data	Creator	Training Data Sanitization; Training Data Management
Model Source Tampering	Creator	Secure-by-Default ML Tooling; Model and Data Integrity, Access Control and Inventory Management
Excessive Data Handling	Creator	User Data Management
Model Exfiltration	Creator, Consumer	Model and Data Inventory Management; Model and Data Access Control; Secure-by-Default ML Tooling
Model Deployment Tampering	Creator, Consumer	Secure-by-Default ML Tooling
Denial of ML Service	Consumer	Application Access Management
Model Reverse Engineering	Consumer	Application Access Management
Insecure Integrated Component	Consumer	Agent Permissions
Prompt Injection	Creator, Consumer	Input Validation and Sanitization; Adversarial Training and Testing; Output Validation and Sanitization
Model Evasion	Creator, Consumer	Adversarial Training and Testing
Sensitive Data Disclosure	Creator, Consumer	Privacy Enhancing Technologies; User Data Management; Output Validation and Sanitization; Agent Permissions; Agent User Control; Agent Observability
Inferred Sensitive Data	Creator, Consumer	Training Data Management; Output Validation and Sanitization
Insecure Model Output	Consumer	Output Validation and Sanitization
Rogue Actions	Consumer	Agent Permissions; Agent User Control; Agent Observability; Output Validation and Sanitization

SAIF states that its Assurance and Governance controls apply to all risks. Those are Red Teaming, Vulnerability Management, Threat Detection and Incident Response Management (Assurance), and User Policies and Education, Internal Policies and Education, Product Governance and Risk Governance (Governance). The remaining controls sit in Data, Infrastructure, Model and Application categories, matching the map; the Application category also includes User Transparency and Controls.

Identity and NHI requirements

SAIF's identity content is spread across several controls, and together they describe what an agent's identity and access should look like:

Agent Permissions: use least privilege as the upper bound on an agent's permissions, keep the number of tools to a minimum, and make privileges contextual and dynamic, adapting to the specific query and trusted context. SAIF's agent page also recommends credentialed tool access.
Agent User Control: require user approval for agent or plugin actions that alter user data or act on the user's behalf.
Agent Observability: log the agent's actions, tool use and reasoning so they can be audited and debugged.
Model and Data Access Controls and Application Access Management: limit internal access to models, weights and datasets, and ensure only authorised users and endpoints reach permitted resources and actions.

SAIF's agent page notes that agents can reveal credentials and API keys they have been given, which makes credential handling part of the Sensitive Data Disclosure risk. The first question in the Agent Risk Self Assessment asks whether the agent has its own identity with narrowly scoped credentials. Google's agent paper adds that agents must have well-defined human controllers, which in identity terms means every agent identity has an accountable owner and every delegated action is traceable to the user it served.

In practice: issue each agent a distinct non-human identity, prefer short-lived tokens bound to the task, keep credentials out of prompts and memory, and record the human principal on every delegated call. See the Agent Identity and Access Guide, the Runtime Secrets Injection for AI Agents Without Prompt Exposure guide and the AI Agent Authorisation Guide.

Implementation steps

NHI Mgmt Group suggests this rollout for applying SAIF:

Classify your role per system. For each AI system decide whether you are Model Creator, Model Consumer or both. This removes risks you do not own from your list and tells you which supplier evidence to request.
Place each system on the SAIF Map. Mark which components you operate: data pipelines, training, storage, serving, application, agent and orchestration. Unused components drop out.
Filter the 15 risks. Keep the risks whose responsibility matches your role and whose components you run. A consumer building an internal agent typically keeps Prompt Injection, Sensitive Data Disclosure, Insecure Model Output, Insecure Integrated Component, Denial of ML Service and Rogue Actions.
Run the Agent Risk Self Assessment for each agent. Its seven questions cover identity and authorisation, observability, user control, built-in model safety, in-tool guardrails, input and output screening, and prompt injection testing. Google states it does not collect or share answers. Treat any "no" or "maybe" as a backlog item.
Implement controls in order. Start with Agent Permissions and identity, then Agent User Control for write actions, then Agent Observability, then input and output validation. These address the two agent risks most directly.
Add assurance. Red team against Prompt Injection and Rogue Actions before production, with detection rules for anomalous tool use and an incident response playbook ready.
Expand approvals carefully. Begin with user approval on every action that changes data. Remove approval for an action type only after testing and monitoring show it behaves as expected, and keep the ability to re-enable approvals quickly if monitoring flags a problem.
Govern the residual risk. Record residual risk per system under Risk Governance and review it at each significant change.

Small and large organisations

Organisation	Practical SAIF scope (our suggestion)
Small, consuming hosted models	Consumer risks only, the Agent Risk Self Assessment per agent, Application and Governance controls, supplier evidence for creator risks
Mid-size, fine-tuning and deploying agents	Creator and consumer risks for fine-tuned models, full Data and Infrastructure controls for the tuning pipeline, agent controls everywhere
Large, training models	All 15 risks, control owners per SAIF Map component, Assurance controls in a dedicated AI red team and SOC function, harmonised platform controls as the second core element describes

Evidence and assessment

SAIF is not a certification. Evidence is your record that the selected controls are in place and working:

Role and map record: per system, your creator or consumer role and the SAIF Map components in scope.
Risk register: the filtered SAIF risks with owners, controls and residual risk.
Agent Security Risk Reports: the self-assessment output per agent, with dates and the actions taken on each gap.
Identity evidence: agent identity inventory, credential scopes and lifetimes, owners, and approval configuration for write actions.
Assurance evidence: red team reports, vulnerability management records and incident response exercises for AI systems.

Metrics (our suggestions):

Percentage of agents with a current Agent Risk Self Assessment and no unresolved "no" answers.
Percentage of agents with a unique identity, named human controller and narrowly scoped credentials.
Percentage of agent write actions behind user approval or a tested policy exception.
Coverage of agent tool calls in centralised logs, against all calls observed at the gateway.
Prompt injection red team findings per release, and time to remediate.

Mapping to other frameworks

The table maps SAIF elements to commonly used frameworks; coverage is partial unless stated. See the AI Security Frameworks Crosswalk Guide for a wider crosswalk.

SAIF element	MITRE ATLAS	NIST SP 800-53 Rev. 5 and CSF 2.0	OWASP
Prompt Injection	AML.T0051 LLM Prompt Injection	SI-4 System Monitoring	LLM01 Prompt Injection
Data Poisoning	AML.T0020 Poison Training Data	SR-3 Supply Chain Controls and Processes	LLM04 Data and Model Poisoning
Model Exfiltration, Model Reverse Engineering	AML.T0024 Exfiltration via AI Inference API; AML.M0019	AC-6 Least Privilege	See the Model Extraction and Distillation Defence Guide
Sensitive Data Disclosure	AML.T0057 LLM Data Leakage	CSF PR.AA-05	LLM02 Sensitive Information Disclosure
Rogue Actions, Agent Permissions	AML.T0053 AI Agent Tool Invocation	AC-6; IA-9 Service Identification and Authentication	LLM06 Excessive Agency; Agentic ASI02 and ASI03
Denial of ML Service	AML.T0034 Cost Harvesting	CSF DE.CM-09	LLM10 Unbounded Consumption
Model and Data Inventory Management	Not a technique	CM-8 System Component Inventory	LLM03 Supply Chain
Risk Governance	Not a technique	RA-3 Risk Assessment; CSF GV.RM-01	Not applicable

For the related frameworks see the MITRE ATLAS Guide, the NIST AI RMF Guide and the OWASP Agentic Top 10 ASI03 Guide. If you run AI workloads on Google Cloud, the platform settings are covered in the Google Vertex AI Security Guide.

Common pitfalls

Ignoring the role column. Consumers who work all 15 risks waste effort on training controls they do not own, and often skip asking their provider for evidence instead.
Treating the six elements as the whole framework. The elements are objectives. The risks, controls and map are where implementation happens.
Giving agents a broad service account. Agent Permissions sets least privilege as the upper bound. A shared, long-lived credential cannot be contextual or dynamic.
Approval fatigue. Agent User Control works only when approval prompts are specific and rare enough to be read. Scope approvals to data-changing actions and tune them.
Logging outputs but not tool calls. Agent Observability needs actions, tool use and reasoning. Output logs alone cannot reconstruct a Rogue Action.
Running the self-assessment once. Agent capabilities change with each new tool. Re-run the assessment when tools, data access or autonomy change.

Practitioner checklist

Record whether you are Model Creator, Model Consumer or both for each AI system.
Place each system on the SAIF Map and filter the 15 risks to those you own.
Run the Agent Risk Self Assessment for every agent and track each gap to closure.
Give each agent its own identity, a named human controller and narrowly scoped, short-lived credentials.
Require user approval for agent actions that change data or act on a user's behalf until tested.
Log agent actions, tool calls and reasoning centrally and alert on anomalous tool use.
Apply input and output validation around every model and agent integration.
Red team for Prompt Injection and Rogue Actions before production and after major changes.
Record residual AI risk per system under Risk Governance and review it at each change.

Google Secure AI Framework Guide: Applying SAIF in Practice