Secure AI is the practice of protecting an AI system from attack and misuse across its whole lifecycle, and the Secure AI Framework is Google's published structure for doing it. Google announced the framework in June 2023, treating AI security as ordinary security extended to a new kind of system plus a handful of risks that only exist because there is a model in the path, and it has since handed the framework to an industry coalition and extended it to agents. The Gen AI Leader exam asks about the framework and the tools, with attack technique left to other courses, and the Practitioner course cares because the framework's two questions are the ones any product person can carry into a project.
The sections below take security across the lifecycle, the framework and its six elements, what the framework became after 2023, the tools the exam names, the reading for a product person, where each syllabus places the material, and end with a fifteen minute mapping exercise.
Security across the lifecycle
Each stage of the lifecycle carries its own exposure, and the point of the framing is that securing one stage leaves the system unsecured.
Data collection and preparation. Usually the largest concentration of sensitive material in the whole project, and frequently the least protected, sitting in storage somebody opened during development. Poisoning also begins here, where altered training data teaches the model something planted.
Training. Who could change the data, the code or the parameters, and whether anyone would notice.
Deployment. The endpoint is a resource like any other. Who may call it, who may change it, and whether it is rate limited, which is partly what stops a model being rebuilt by querying it repeatedly.
Use. Prompt injection, sensitive information coming back out of context, and whatever the system is permitted to act on.
Monitoring. Whether the team would know. Logging what was asked and answered makes an incident reconstructable, and immediately creates its own privacy question, because the log now holds whatever users typed.
The Secure AI Framework and its six elements
Across those stages, SAIF gives organisations a common structure for thinking about AI risk, so that security teams already competent at protecting software have a way to extend that competence without starting over.
Its six core elements are worth knowing in outline. Expand strong security foundations to the AI ecosystem, so that existing controls cover the new systems. Extend detection and response to bring AI into the organisation's threat universe. Automate defences to keep pace with existing and new threats. Harmonise platform level controls so every team is not inventing its own. Adapt controls to adjust mitigations as the threats change. And contextualise AI system risks in the surrounding business process, so that they are weighed alongside every other risk the business carries.
The benefit is consistency. Without a framework, every team makes its own judgement about what is safe enough, and the organisation has no way to compare or govern those judgements.
SAIF is a framework and no certification. ISO/IEC 42001 is the standard an organisation is certified against, and the two are easy to confuse.
What the framework became after 2023
A framework published by one vendor has a credibility problem, and Google addressed it in three steps. In July 2024 it co founded the Coalition for Secure AI under an open standards body, with several other model developers and cloud providers as members, and contributed the framework as a starting point for shared guidance. In October 2024 it published a risk self assessment built on the framework, a questionnaire that maps an organisation's answers to the risks the framework names and the controls that address each one. And in October 2025 it published an extension for agents, adding three principles that agents must have well defined human controllers, that their powers must be limited to what the task needs, and that their actions and plans must be observable. The three are the excessive agency and human oversight material of this course restated as a vendor's design rule.
The tools the exam names
The exam pairs the framework with four Google Cloud capabilities.
Secure by design infrastructure is Google's claim that the underlying platform carries protections by default, with no configuration needed to switch them on, covering encryption at rest and in transit, hardware roots of trust and network isolation.
Identity and Access Management is the primary control and the one that decides most outcomes. Who may call a model, read the training data, change a deployment or use a tool an agent has. Least privilege applies here exactly as it does anywhere else, and it matters more once an agent can act.
Security Command Center is the security posture and threat view across a Google Cloud environment. Misconfigurations, vulnerabilities and active threats in one place, which is how an AI workload gets watched alongside everything else and never separately.
Workload monitoring covers the operational picture, what is running, what it is calling and whether behaviour has changed.
The reading for a product person
Underneath the tools sit two questions worth carrying into any AI project. What this system is permitted to do if somebody manipulates its input, and whether the team would know afterwards. Almost every control in this section is an answer to one of those.
Where each syllabus puts it
SAIF is Google's framework and the Gen AI Leader exam asks about it by name, alongside the Google Cloud tooling that implements it.
Read outside that exam, it is one of several attempts at the same problem and worth placing among them. The NIST AI Risk Management Framework is voluntary, United States government published and organised around govern, map, measure and manage. ISO 42001 is certifiable and describes a management system, with the controls left to the organisation. MITRE ATLAS catalogues actual attack techniques against machine learning systems. SAIF is the most implementation minded of the four and the least independent, since the organisation publishing it also sells the tools, which is the reason it was handed to a coalition.
Practise this
The exercise needs one AI system of the team's own, fifteen minutes, and a framework to map against. Any will do, whether that is the six elements above, the govern, map, measure and manage functions, or a list the security team keeps.
Write the themes down the left and, against each, the control the team actually runs today, then mark it implemented, partial or absent. Partial does the work here, so it is used wherever a control covers part of the system, is never checked, or produces output nobody has read this month.
System ...........................................
Framework I am mapping against ...................
Theme or control What we actually do today I / P / A
................... .......................... I P A
................... .......................... I P A
................... .......................... I P A
If no framework is to hand, these six elements work
expand existing security foundations to AI systems
extend detection and response to cover them
automate defences to keep pace
harmonise controls so teams are not each inventing their own
adapt controls as the threats change
put AI risks into the surrounding business risk process
Marking rule
if nobody can say where the evidence lives, it is partial
at best
Read the absent and partial rows for what they have in common. The controls marked implemented are usually the ones that existed before any model arrived, meaning access control, review and a deployment pipeline, while the gaps cluster in detection and response, which is whether anybody would notice the system behaving differently and who gets called when they do. That pattern is the argument for mapping against a framework at all, since a team assessing itself control by control finds its strong rows and misses the shape.
An honest mapping shows that the gap is rarely a missing control at build time and is usually the absence of anybody watching afterwards.