In May 2025, three Google engineers — Santiago Díaz, Christoph Kern, and Kara Olive — published "Google's Approach for Secure AI Agents: An Introduction," part of Google's Secure AI Framework (SAIF). It's one of the cleaner mental models for agent security published by a major vendor — worth reading in full.
We're going to do something specific with it: map our own testing coverage onto it, honestly, and show you the two places where the framework points at a gap in ours. First, the necessary disclosure — SAIF is Google's framework, "SAIF" and "Google" are their marks, and AAPT is an independent product, not affiliated with or endorsed by Google. We map to SAIF the same way we map to the OWASP LLM Top 10 and MITRE ATLAS: as a neutral reference a buyer can hold every vendor to.
The box most people skip in the diagram
The paper's core is a hybrid defense-in-depth. Two of its layers are runtime controls: a deterministic policy engine that intercepts an agent's actions and can allow, block, or require confirmation; and reasoning-based defenses — adversarial training and guard-model classifiers that make the model itself harder to manipulate. Both live inline, in production, while the agent runs.
But underneath those two layers, the paper names a third band it calls assurance: regression testing, variant analysis, and red teams. This is the part that isn't a product feature you switch on — it's work someone has to do before the agent ships, and repeatedly after. It's also the part teams quietly skip, because the two shiny runtime layers feel like "the security."
That assurance box is where a tool like ours lives. So let's be precise about the boundary up front, because getting it wrong is how vendors lose credibility:
A testing tool is not a policy engine and not a guard model. It doesn't block a live attack. Its job is to find out whether your runtime controls actually hold — before an attacker does.
With that boundary drawn, the interesting thing is how neatly Google's assurance vocabulary maps to concrete testing mechanisms — including two that are exactly how our own engine works:
| Google's assurance method | What it means in practice |
|---|---|
| Variant analysis | An adaptive attacker that generates attack variants live, adapting to each refusal — rather than replaying a fixed script. |
| Regression testing | Re-running each finding N times to measure reproducibility — "fails 1-in-20" vs "every time" is the difference between a backlog item and a launch blocker. |
| Red teams & reviewers | The adversarial engagement itself: someone deliberately trying to make the agent misbehave. |
Their two risks, in test terms
SAIF reduces agent risk to two headline categories. Here's what a red-team probe for each actually looks like.
Risk 1 — Rogue actions
The agent is induced to do something unintended, harmful, or off-policy — usually via prompt injection hidden in the data it processes, sometimes via plain misinterpretation. Testing it means planting hostile instructions in retrieved documents, RAG corpora, or hidden HTML/markup and checking whether the agent's plan gets hijacked; then following the plan into tool use, where a hijacked agent does real damage — traversing a path it shouldn't, calling a dangerous tool, escaping its sandbox, or pivoting through a network proxy. This last cluster — the agent misusing its own tools to break containment — is the surface expanding fastest, and the one we most recently built a dedicated probe family for.
Risk 2 — Sensitive data disclosure
The agent is induced to reveal private data — by chaining a read tool into an exfiltration tool, by leaking a schema or cloud-metadata credentials, or by insecure output rendering: emitting a markdown image URL that quietly ships data to an attacker when the app renders it. Testing it means driving the agent toward those disclosures and watching what actually comes back — in the response and in the tool calls.
Their three principles, tested
The paper's prescriptive core is three principles. Two of them are directly testable; one is a control you build, not one we test — and we'll say so.
| SAIF principle | Testable? What a probe checks |
|---|---|
| 1 · Well-defined human controllers | Partial. Can an untrusted input impersonate the controlling user, or bury a harmful action past a human approver? Cross-user memory isolation. |
| 2 · Limited agent powers | Strong. Can the agent be pushed beyond least privilege — confused-deputy tool chains, path traversal, privilege escalation, sandbox escape, tool egress? This is our deepest coverage. |
| 3 · Observable actions | Out of scope. Observability is a control you build. We consume it — tool-call visibility is what lets us detect a silent escape — rather than test it. |
Where our coverage stops — the honest part
Mapping our library onto SAIF, roughly twenty of our twenty-four probe categories slot cleanly into its risks, stages, and principles. The framework mostly validates and re-labels coverage we already ship. But an honest map has to name what it doesn't cover, and SAIF surfaces exactly two probe-level gaps:
- Output-rendering exfil. Google's flagship data-disclosure example — the markdown/image URL that leaks data on render — is a vector we test on the input side (hidden-markup injection) but not yet on the output side. (We did fix this class in our own report generator; that's product hygiene, not a probe.)
- Explicit confirmation-gate bypass. We test whether a harmful action slips past a fatigued human approver. We don't yet have a probe for the distinct case of an agent taking an irreversible action without ever requesting the confirmation SAIF's Principle 1 requires.
Both are small and buildable. Naming them is the point: a coverage map you can't puncture is one nobody believes.
Why this matters to you
If you're deploying agents inside a Google-Cloud or ADK-shaped stack, SAIF is increasingly the vocabulary your security reviewers will use. That's useful for everyone: it turns "is this agent secure?" — unanswerable — into a checklist of named risks, principles, and a defense model you can point a test at.
The uncomfortable follow-up is the same one it always is. Google has told you what to defend and how to layer the defenses. The question left over is whether anyone has actually tested your agent against that list — rogue actions, data disclosure, least privilege, containment — or whether the runtime layers are simply assumed to hold.
Test against the list
See the attack classes SAIF names — prompt injection, tool misuse, multi-turn escalation, containment — running against a live agent in a few minutes.
Source: "Google's Approach for Secure AI Agents: An Introduction" (Díaz, Kern, Olive; Google, May 2025), part of the Secure AI Framework. SAIF and Google are trademarks of Google LLC; AAPT is independent and not affiliated with or endorsed by Google. This post summarizes and comments on a public document; it reproduces no substantial portion of it. Only test agents you own or have written permission to test.