Google SAIF: Turn the Secure AI Framework Into Control Ownership

Google SAIF places an AI system on a map with four component areas: data and infrastructure, plus model and application. Risks move through that system as data becomes a model and the model reaches an application. Users or agents then invoke it. Google maps controls to those risks. The framework becomes operational when every relevant intersection has an owner and an enforcement point. It also needs a test and retained evidence. A framework diagram alone leaves the security decision unfinished.

TL;DR

• Google SAIF maps risks and controls across data and infrastructure, plus model and application components, instead of treating the model as the whole AI system.
• Use the SAIF map to follow one risk through the development process and identify where control ownership changes.
• Convert each relevant map intersection into a record with an owner and control location. Include an acceptance test and evidence, then add a review trigger.
• DeepInspect can support the application/runtime slice for authenticated HTTP AI traffic. Data pipelines and model integrity need separate controls. Infrastructure and endpoints also need separate controls, as does local execution.

Google SAIF maps the full AI development process

Google describes the Secure AI Framework map as a visual guide for locating AI risks and potential controls across the development process. It supports two useful views. A security team can follow one risk through the system, or it can inspect the risks concentrated around one component area. Google also separates model consumers, who build applications with models, from model creators, who train or fine-tune them.

That separation prevents a familiar architecture error: assigning every AI risk to the application team because the application has the visible user interface. Training-data poisoning begins in a different place than prompt injection. Infrastructure compromise has another owner. Agent actions can cross several systems after one model response.

The AI governance framework guide provides the broader policy and decision structure. SAIF adds a security-specific map for connecting those decisions to the deployed system.

Four component areas expose ownership changes

Google's SAIF components reference describes the model as code and weights created through training, stored and served through infrastructure, then used in applications. It also names input handling and output handling as component-level defenses. Application components include the user-facing product and service callers. They also include agents that can invoke tools or other systems.

Start an implementation with one page that names the exact data sources and training or tuning process. It should also name the model artifact and serving infrastructure, followed by the application and external connections. Draw each boundary as a box. On a wall-sized printout, the useful marks are the arrows where ownership changes, not the logo in the center.

For each arrow, record the sender and recipient. Add the data class and authentication method. Then specify the permitted action and failure behavior, with the evidence source. The AI risk register template can hold the resulting risks and accountable owners without turning the SAIF map into another static policy document.

Controls need tests and retained evidence

The SAIF controls catalog includes technical and governance controls mapped to AI risks. Google names threat detection and incident response management, alongside product governance and risk governance, among the control families. The catalog identifies which actors can implement a control and which risks it addresses.

Turn each catalog control into an implementation record. Record the component and risk, then the named owner and enforcement location. Add the expected behavior and test input. Store the acceptance rule and result, followed by the evidence URI. Add the system version and test date. Preserve exceptions with an approver and expiry rather than overwriting the failed result.

I would reject a SAIF assessment where every control points to the same enterprise security policy. That document may establish intent, but it cannot show that a poisoned retrieval source was quarantined or that an unapproved tool call was denied. The evidence should let a reviewer reconstruct one control decision against one system version.

Material changes reopen the affected SAIF record

AI systems change without receiving a new product name. A model replacement can alter output handling and safety behavior. Adding retrieval changes the data path. A new tool gives an agent another action surface. Moving inference changes infrastructure ownership, while a new user group can change access assumptions.

Define review triggers beside each SAIF record. Reopen the affected entries after a model or provider change or a new data source. Also reopen them after an altered system prompt or infrastructure move. Tool additions and policy revisions require the same review. An incident does too. Preserve the previous evidence package so the reviewer can see what changed and which control was retested.

This approach also keeps SAIF distinct from a one-time threat-model workshop. The CISA AI guidance can organize lifecycle release evidence. SAIF supplies a component-and-risk view that follows security ownership across the system. One artifact should reference the other without merging their conclusions.

The HTTP request boundary covers one SAIF slice

At the application/runtime layer, an authenticated user or agent may send an HTTP request to an LLM endpoint. A request-boundary control can inspect caller identity and application. It can also inspect the model destination and data classification, followed by the requested action before transmission. It can then permit or block the request. It can also transform the request and write a per-decision record.

That evidence can support SAIF controls tied to input handling and output handling. It can also support route authorization and policy enforcement, plus selected monitoring duties. The AI audit log format guide covers the fields needed to preserve that decision independently of the calling application.

Other SAIF areas retain their own owners. Training-data integrity belongs with the data and model pipeline. Infrastructure isolation belongs with the platform team. Endpoint controls govern local clients. Tool authorization must also exist at the target system. A clean SAIF implementation makes those limits visible instead of coloring the entire map green after one gateway test.

DeepInspect

DeepInspect supports the request-boundary slice of a SAIF implementation. It sits between authenticated users or agents and approved HTTP-based LLM endpoints, evaluates identity-aware policy, and writes a per-decision audit record before traffic proceeds.

Map those records to the SAIF controls they directly support. Keep model training and data integrity with their respective owners. Infrastructure and endpoint security also need their own owners, as does downstream tool authorization. Book a technical deep dive at deepinspect.ai.