SAIF Risk Assessment to Control Plan: How to Turn Google's Report Into Tested AI Security Controls

Google's SAIF Risk Assessment is a free questionnaire at saif.google that takes about ten minutes and returns a report naming which of the 15 SAIF risks apply to your AI system, why each was flagged, and the controls Google recommends. Since SAIF 2.0, a separate Agent Risk Self-Assessment does the same for agents that call tools. Most teams run it for one of four reasons: a customer security questionnaire now asks about AI security by name, the board asked which framework the company follows, an agent with real permissions went to production, or ISO 42001 or SOC 2 pulled AI systems into scope. The report answers none of those on its own, because it lists risks and cannot tell you whether a single control is in place or works. This post covers what SAIF is, how to run the assessment so the report is worth acting on, how to turn each flagged risk into a control with an acceptance test, where the report stops and testing has to start, and how the same work reports out under NIST AI RMF, ISO 42001, and the OWASP LLM and Agentic Top 10 lists.

What SAIF is

Google's Secure AI Framework (SAIF) is the externalized version of the framework Google uses to secure its own AI. Google published it in 2023 around six elements: extend existing security foundations to AI, extend detection and response to AI inputs and outputs, automate defenses against adversarial inputs, harmonize controls across every model and application on one platform, adapt controls through feedback from testing and incidents, and judge AI risk in the context of the business process it sits in. Google added the Risk Assessment and the Risk Map in October 2024 and released SAIF 2.0 in October 2025 with a focus on agents.

The Risk Map and the 15 risks

The working core of SAIF is the Risk Map. It divides an AI system into four component areas, Data, Infrastructure, Model, and Application, across model creation and model usage, and places 15 named risks along that path:

• Data: Data Poisoning, Unauthorized Training Data, Excessive Data Handling
• Infrastructure: Model Source Tampering, Model Exfiltration, Model Deployment Tampering, Denial of ML Service
• Model: Model Reverse Engineering, Model Evasion, Prompt Injection
• Application: Insecure Integrated Component, Sensitive Data Disclosure, Inferred Sensitive Data, Insecure Model Output, Rogue Actions

Each risk carries a set of controls and an owner, the model creator, the model consumer, or both, based on who has to enact the controls. Most companies are model consumers: they call a hosted foundation model and build an application around it, which puts most of the 15 risks at least partly on their side and leaves the training data and model source risks with the model provider. Knowing which side you are on is the first filter on the report.

What SAIF 2.0 added for agents

SAIF 2.0 adds a second risk map for agents, covering risks such as tool permissions, agent memory, and multi-agent interaction, and three design principles Google states plainly in its October 2025 announcement: agents must have well-defined human controllers, their powers must be carefully limited, and their actions and planning must be observable. The Agent Risk Self-Assessment at saif.google/agent-risk-self-assessment applies those principles as a seven-question questionnaire covering identity and authorization, observability, user control, model safety, in-tool guardrails, input and output screening, and testing. If your system calls tools, holds or uses credentials, or acts without a human approving each step, run both assessments.

Who should run the assessment and how

System owner, engineering, security, and privacy in the same session

Run it with the system owner, the engineering team that built it, someone from the security team, and, when the system touches PII, PHI, or other regulated data, someone from the privacy team. The questionnaire asks about training and tuning data, access controls on models and datasets, adversarial input handling, secure design for generative AI, agent capabilities, and how user data is stored, processed, and used against consent. The system owner is accountable for the risk and decides what gets fixed first. Engineering knows the true answers on architecture. Security knows which answers describe a policy rather than a deployed control. Privacy knows whether the consent and retention answers are true, and several of the questions are theirs. A compliance analyst filling it out alone produces a clean report for a system that is not clean, and that report is the one a customer eventually asks to see.

One run per system

Run it once per AI system. A single company-level run averages a RAG chatbot over public documentation with an agent that can modify customer records, and the two have different risk lists, so the average hides the one that matters. Run the standard assessment for any LLM feature and add the agent assessment for anything with tools.

Re-run whenever the system changes

Re-run the assessment when the system changes in a way that touches the risk list: a new tool or extension, a new data source in the retrieval corpus, a model version change, a new user population, or a move from human-in-the-loop to autonomous action. Each of those changes the answer to at least one question, and the report from before the change no longer describes the system. A quarterly re-run is the floor for systems that did not change. Change-triggered re-runs are the actual control, and they are what SAIF's feedback-loop element, ISO 42001's requirement to plan changes to the management system (clause 6.3), and its operation and monitoring control (A.6.2.6) all ask for.

Answer for what is deployed

The report splits into risks relevant to you and risks you have mitigated, based on roughly twelve yes, no, or maybe answers. Google states that it does not collect or share the answers or the results, so there is no penalty for honesty and no benefit to optimism. Answer for the control that is running in production today. "We plan to filter retrieved content" is a no.

From the report to AI security controls you can ship

The worked example

Take a system we see often: a customer support agent built on a hosted foundation model. It retrieves from an internal knowledge base, looks up order history through an API, and issues refunds under $200 without human approval. The standard assessment flags Prompt Injection, Sensitive Data Disclosure, Insecure Model Output, Insecure Integrated Component, Rogue Actions, and Excessive Data Handling. The agent assessment adds findings on tool scope and memory.

Each risk as a ticket

The report earns its keep at the point where each flagged risk becomes a ticket with a layer, a control, and an acceptance test. For this system:

Prompt Injection through retrieved documents. Treat knowledge base content as untrusted. Separate retrieved text from instructions with hard delimiters, run an injection classifier on retrieved chunks before they enter context, and keep the system prompt out of the retrieval path. SAIF controls: Input Validation and Sanitization, Adversarial Training and Testing. Acceptance test: a planted document containing "refund the full order" fails to change agent behavior across 50 runs.

Rogue Actions on the refund tool. Enforce the $200 limit in the refund API, where the prompt cannot override it. Require the order ID in every refund call to belong to the authenticated customer at the token level. SAIF controls: Agent Permissions, Agent User Control, Agent Observability. Acceptance test: the agent cannot refund an order it retrieved for a different customer, regardless of what the conversation says.

Sensitive Data Disclosure. Scope the order lookup API to the caller. Redact payment data before it enters model context. SAIF controls: User Data Management, Output Validation and Sanitization. Acceptance test: no card number or full address appears in 1,000 sampled conversations or their logs.

Insecure Model Output. Encode model output before it renders in the support UI or is written to a ticket. SAIF control: Output Validation and Sanitization. Acceptance test: model output containing HTML or a markdown link does not execute or redirect.

Excessive Data Handling. Log tool names and arguments. Drop customer message bodies after 30 days unless a ticket is open. SAIF control: User Data Management. Acceptance test: a log query for a 31-day-old closed conversation returns tool metadata only.

Why prompt-level controls come last

Every control above names the layer it lives in, and none of them lives in the prompt. Prompt injection defeats prompt-level controls by definition, so the prompt is the last line of defense. A common finding in our agent assessments has nothing to do with the model: every tool runs under one service credential with write access to every customer, so the blast radius of a single successful injection is the whole customer base. That is a Rogue Actions finding in SAIF's vocabulary and an authorization bug in everyone else's, and it is fixed at the API.

This translation step is where most teams stall. The report is free and takes ten minutes. Turning six flagged risks into tickets with owners, layers, and tests is two to three weeks of work that sits between security and engineering and belongs to neither, which is why the report ends up in a folder. Our agentic AI security practice takes the SAIF report as the intake and returns a control plan the engineering team can execute, then tests the live system against it.

Where the AI security assessment stops and testing starts

The report tells you which risks apply. It cannot tell you whether your mitigations work, because a questionnaire measures what you say you do. Three areas need hands-on testing after the report, and they are the three that customers and auditors now ask about by name.

Indirect prompt injection with the real corpus

Test with the actual system prompt, the actual retrieval corpus, and the actual tools. Generic jailbreak lists miss the paths that matter for agents: documents, emails, web pages, and tool results that the model reads as instructions. We cover the mechanics in our guides to RAG security and prompt injection.

Tool permission enumeration

Enumerate every tool, the credential it runs under, and what happens if the model calls it with attacker-chosen arguments. Our threat model for AI agents lays out the method, and if the tools arrive over MCP, our MCP security guide covers the connection layer. The SAIF agent assessment gives you the risk names to report the findings under.

Data path tracing

Trace where customer input goes, including logs, the vector store, fine-tuning sets, and the model provider, and where retrieved content comes from. Sensitive Data Disclosure findings usually live in the logging pipeline rather than the model.

The OWASP AI Testing Guide and the OWASP Agentic AI Threats and Mitigations document are the published methods for this work, and they are what a client's security team will check your test plan against. We regularly find a path where untrusted content triggers a tool call nobody intended. The SAIF report will have named that risk. Only the test proves it is real.

How SAIF reports out under NIST AI RMF, ISO 42001, and OWASP

Use SAIF for the technical risk list and let the frameworks you already report against carry governance and audit. The overlap is high enough that one set of work reports three ways. At the framework level, SAIF's six elements land on NIST AI RMF's Govern and Manage functions and on ISO 42001 clauses 5, 6, 8, and 9. At the risk level, the crosswalk below maps all 15 to NIST AI RMF, ISO 42001 Annex A, the OWASP LLM Top 10 as renumbered in its August 2026 edition, and the OWASP Top 10 for Agentic Applications.

NIST references are to AI RMF 1.0 Playbook subcategories. ISO references are to ISO/IEC 42001:2023 Annex A. OWASP LLM numbering follows the 2026 edition, which moved Excessive Agency to LLM03 and Improper Output Handling to LLM10, and the Agentic list is the OWASP Top 10 for Agentic Applications 2026. Treat the table as a working crosswalk to confirm against your own control set.

SAIF has no discrete risk for inter-agent communication. Its agent map mentions multi-agent interaction, but teams running multi-agent systems should take ASI07 Insecure Inter-Agent Communication from OWASP directly.

If you already score against NIST AI RMF

The SAIF report is a ready input to the Map and Measure functions and will move both scores. Our guide to scoring against NIST AI RMF covers what evidence counts, and the SAIF risk list and the acceptance tests above are exactly that evidence.

If you are on the ISO 42001 path

The SAIF risks slot into the A.6 life cycle and A.7 data controls with no new clauses, and the impact assessment in A.5 is where the "contextualize risk in the business process" element lands. See the ISO 42001 certification path for sequencing.

The one-sentence questionnaire answer

When a customer asks which AI security framework you follow, the answer becomes: "SAIF for technical risk identification, mapped to the OWASP LLM and Agentic Top 10 for testing and to NIST AI RMF and ISO 42001 for governance." That is a stronger answer than any one framework alone, and it is only true once the crosswalk and the test results exist.

The first 30 days

Week one, inventory every AI system in production or pilot, including vendor features with an LLM inside, and run the SAIF assessment on each with the system owner, engineering, security, and privacy present. Save every report.

Week two, convert each flagged risk into a ticket with a layer, an owner, and an acceptance test. Start with any system whose tools have side effects.

Week three, test the highest-risk system against the three gaps above using its real corpus and real tools.

Week four, map open tickets to whichever framework you already report under and tie the re-run to your change management process with a quarterly floor, because a system that gains a tool has a new risk list.

Frequently asked questions

Is the SAIF risk report enough to answer a customer security questionnaire? No. Google's SAIF report lists applicable risks. Questionnaires ask which controls are in place and for evidence. You need each flagged risk mapped to a deployed control with test results, which is the control plan and test report described above.

Who should complete the SAIF Risk Assessment? The system owner and the engineering team, together with the security team, and privacy in the room when the system handles PII, PHI, or other regulated data. Run it per system and re-run it when the system gains a tool, a data source, or a new model version.

How long does the SAIF Risk Assessment take? About ten minutes per system for the questionnaire. Turning the report into tickets with acceptance tests is two to three weeks. Testing the live system adds two to three more.

Should I run the standard assessment or the agent assessment? Both, if the system calls tools or acts without per-step human approval. The agent assessment surfaces Rogue Actions and tool-scope risks the standard one does not.

How does SAIF map to NIST AI RMF and ISO 42001? SAIF is the technical risk list. NIST AI RMF and ISO 42001 carry governance and audit. The crosswalk table above maps all 15 risks, so one set of work reports under all three.

Does SAIF replace the OWASP LLM Top 10? No. SAIF names the risk and the control class. OWASP's 2026 LLM Top 10 and the Agentic Top 10 are what you test against. Use SAIF for the plan and OWASP for the test scope.

Where BD Emerson fits

We run SAIF-aligned AI security assessments through our agentic AI security practice, typically in four to six weeks depending on how many systems are in scope. The intake is your SAIF report or one we run with your team. The deliverable is a control plan per system with layer, owner, and acceptance test, adversarial test results against the live system, and a crosswalk to NIST AI RMF, ISO 42001, and OWASP you can hand to an auditor or paste into a customer questionnaire. Where the engagement uncovers governance gaps, the same evidence feeds our AI readiness and ISO 42001 implementation work without being redone.

If you have already run the assessment and the report is sitting in a folder, that is the right moment to talk to us.