Concept 4 of 5

Secure AI and the Secure AI Framework

1 question test this

Google treats 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. The Gen AI Leader exam asks about the framework and the tools rather than about attack technique.

Security across the lifecycle

Each stage carries its own exposure, and the point of the framing is that securing one is not securing the system.

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 you 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

SAIF is Google's published framework for securing AI systems. Its purpose is to give 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 rather than starting over.

Its themes are worth knowing in outline. Extend existing security foundations to AI rather than building a parallel programme. Widen detection and response to include AI systems. Automate defences to keep pace. Harmonise controls across the organisation so every team is not inventing its own. Adapt controls as the threats change. And put AI system risks into the surrounding business risk process rather than treating them as a separate technical concern.

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 rather than a certification. ISO/IEC 42001 is the standard an organisation is certified against, and the two are easy to confuse.

The tools

Secure by design infrastructure is Google's claim that the underlying platform carries protections by default rather than as configuration, 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 rather than 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

Two questions are worth carrying into any AI project. What is this system permitted to do if somebody manipulates its input, and would we know afterwards. Almost every control in this section is an answer to one of those.

Practise this

You need one AI system of your own, fifteen minutes, and a framework to map against. Any will do, whether that is the themes above, the govern, map, measure and manage functions, or a list your security team keeps.

Write the themes down the left and, against each, the control you actually run today, then mark it implemented, partial or absent. Partial does the work here, so use it 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 themes work

  extend existing security foundations to AI systems
  widen 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 you cannot 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 teaches you that the gap is rarely a missing control at build time and is usually the absence of anybody watching afterwards.

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 rather than controls. 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.

Common misconceptions

Securing an AI system means securing the model.

The model is rarely the weakest point. Training data, the pipeline that produced it, the endpoint serving it, and whatever the system is permitted to act on all carry more risk, which is why the framework runs across the lifecycle rather than around the model.

SAIF is a certification you can be audited against.

It is a conceptual framework Google published to extend established security practice to AI systems. ISO/IEC 42001 is the standard an organisation gets certified against. Confusing the two is the usual mistake in this area.

Security is something added once the AI system works.

The lifecycle framing exists to prevent exactly that. Training data collected without access controls, or a pipeline nobody can audit, cannot be secured retrospectively without doing the work again.

1 question test this concept

A security team proposes running AI risk as a separate programme, with its own controls, its own review board and its own tooling, alongside but apart from the existing security function. How does Google's Secure AI Framework frame that choice, and where does the framework itself sit?

  • AIt supports the proposal, since AI risks have no counterpart in conventional security and need controls of their own.
  • BIt supports the proposal, and an organisation demonstrates the result by being certified against the framework.
  • CIt treats the question as settled by the platform, since secure by design cloud infrastructure covers AI workloads along with everything else.
  • DIt argues for extending existing security foundations to AI systems and harmonising controls across the organisation, and it is one of several frameworks addressing the same problem.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Data and Goliath, On data collection and the exposure it creates.
Template
Launch checklist, Everything that has to happen from two weeks out to one week after release, grouped by when it falls due, each line with a named owner and a go or no go decision on the day.