Enterprise Security in the Agentic AI Era

Google SAIF — Secure AI Framework

6 min read

Google SAIF — Secure AI Framework

Google SAIF (Secure AI Framework) provides AI security principles and lifecycle guidance across data, infrastructure, model, and application layers. Google’s primary institutional vehicle for collaborative standards is now CoSAI, to which Google donated the SAIF Risk Map and Risk Assessment in 2024.

Key Concepts

SAIF introduced “Secure Agents” principles covering three dimensions:

  1. Human control — maintaining oversight over autonomous agent actions
  2. Limited powers — agents operate with minimum necessary capabilities
  3. Observability — comprehensive monitoring of agent behavior

These map directly to what the ASI Top 10 later formalized as the “Least Agency” principle.

Six Core Elements (the SAIF “Approach”)

The SAIF framework’s practitioner-facing contribution, documented at length in the SAIF Implementation Guide (Google, 2024). The six elements are levers to apply collectively rather than steps to follow chronologically:

  1. Expand strong security foundations to the AI ecosystem — review existing security controls for AI applicability; analyze gaps; track supply-chain assets / code / training data; scale data governance to AI; retain and retrain existing security talent rather than only hiring external AI experts.
  2. Extend detection and response to bring AI into an organization’s threat universe — develop AI-specific threat understanding; respond to attacks against AI and issues raised by AI output; for Gen AI, enforce content safety policies; adjust abuse policy + IR processes for AI-specific incident types.
  3. Automate defenses to keep pace with existing and new threats — augment traditional defenses (encryption, access control, auditing) with AI-driven training-data and model protections; use AI to automate time-consuming defensive tasks (e.g., AI-generated YARA rules from malware analysis); keep humans in the loop on important decisions.
  4. Harmonize platform-level controls to ensure consistent security across the organization — periodic review of AI usage and lifecycle; prevent fragmentation by standardizing on tooling and frameworks; right-fit existing control frameworks to AI rather than creating parallel ones.
  5. Adapt controls to adjust mitigations and create faster feedback loops for AI deployment — Red Team exercises; track novel attacks (prompt injection, data poisoning, evasion); apply ML to improve detection accuracy and speed; create a feedback loop so Red Team findings flow back into training and protections.
  6. Contextualize AI system risks in surrounding business processes — establish a model risk management framework; build inventory of AI models with risk profiles; enforce data-privacy / cyber-risk / third-party-risk policies through the ML model lifecycle; apply shared responsibility (developer / deployer / user splits); match AI use cases to risk tolerances.

The six elements are distinct from (and complementary to) the SAIF Risk Map’s four layers (data / infrastructure / model / application) — the layers describe what to protect; the elements describe how to apply controls. Both views are part of SAIF.

Four-Step Implementation Methodology

The implementation guide’s adoption pathway:

  1. Understand the use — characterize the business problem, the data needed, the user-interaction model, and whether you are building / fine-tuning / using a third-party model. Each combination drives different control requirements.
  2. Assemble the team — multidisciplinary stakeholder list: Business use case owners; Security; Cloud Engineering; Risk and Audit; Privacy; Legal; Data Science; Development; Responsible AI and Ethics. Establishes that security, privacy, risk, and compliance considerations are included from the start.
  3. Level set with an AI primer — bring all stakeholders to a baseline understanding of AI / ML / Deep Learning / Gen AI / LLMs and the model development lifecycle.
  4. Apply the six core elements — the framework’s substantive content; not chronological, treat as collectively-applied levers.

This stakeholder list operates at the implementation-team level — distinct from the AI Agent Layered Council’s governance-level cross-functional body (CIO + CFO + COO + GC + Procurement + CHRO). SAIF’s team is who does the work; the Layered Council is who governs the program.

CMM / RA crosswalk for the six elements

SAIF elementWiki CMM domainWiki RA plane
1 Expand security foundationsD8 (Supply Chain & Tooling); D6 (Data); D9 (Operations)(Cross-cutting; foundational)
2 Extend detection & responseD7 (Observability & Behavioral Monitoring)Observability plane
3 Automate defensesD4 (Runtime & Guardrails); D7 (Observability)Runtime plane; Observability plane
4 Harmonize platform-level controlsD1 (Governance & Accountability); D3 (Control & Least-Agency)Control plane
5 Adapt controls + feedback loopsD7 (Observability); D9 (Operations & Human Factors)Observability plane; Cross-cutting
6 Contextualize risks in businessD1 (Governance & Accountability)(Cross-cutting; governance)

Q1 2026 Developments

No formal “SAIF 2.0” has been announced. Google’s Q1 2026 AI security contributions primarily flowed through CoSAI and Google ADK:

Google ADK Go 1.0 (March 31, 2026) shipped with built-in security features:

  • OpenTelemetry integration — full observability out of the box
  • Human-in-the-loop confirmations — configurable approval gates
  • before_model_callback hooks — platform-level input validation (the reference implementation of platform-level enforcement)
  • Model Armor integration — prompt injection detection at the API layer

A2A Protocol reached v1.0.0 on 2026-03-12 with signed Agent Cards (§8.4) and gRPC support; under Linux Foundation governance since 2025-06-23.

Supply chain risk in Google's own toolchain

A LiteLLM supply chain compromise was detected in ADK dependencies (March 24, 2026), demonstrating that even Google’s AI toolchain is not immune to supply chain attacks.

Google donated its SAIF Risk Map and Risk Assessment to CoSAI, ensuring continuity of SAIF content under the multi-stakeholder collaborative model.

Architecture: A2A Protocol

The Agent-to-Agent (A2A) protocol introduces an important security principle:

  • Opacity principle — agents collaborate without sharing internal memory or proprietary logic; only externally visible capabilities are exchanged
  • Agent Cards at .well-known endpoints for identity discovery
  • Signed Agent Cards (§8.4 of A2A v1.0, algorithm-agnostic — Ed25519 is the de facto vendor pick) enabling cryptographic verification of identity-and-capability metadata
  • Authentication delegates to OpenAPI-style schemes (OAuth 2.0/OIDC, mTLS, API keys); message-level integrity, replay protection, and cross-agent delegation remain vendor-side or proposal-side

Strengths

  • ADK’s before_model_callback is the reference implementation of platform-level security enforcement — the pattern the paper identifies as most critical
  • A2A “opacity principle” is a sound architectural security pattern for multi-agent systems
  • SAIF’s comprehensive lifecycle coverage (data → infrastructure → model → application) remains one of the most holistic single-framework scopes
  • CoSAI donation ensures SAIF content has multi-stakeholder governance

Gaps and Shortcomings

  • CoSAI publications remain principled guidance rather than enforceable specifications
  • A2A v1.0 has security woven through §7 + §8.4 but no standalone security specification — message integrity, replay protection, and cross-agent delegation remain implementer / vendor concerns (see Multi-Agent Runtime Security for the depth)
  • Agent identity in A2A relies on Agent Cards at .well-known endpoints; formalized authorization schemes remain on the roadmap
  • AI Incident Response Framework lacks AI-specific IoCs or forensic procedures
  • No AI-BOM requirements
  • Cognitive file integrity and proof-of-guardrail concepts are unaddressed

See Also

Graph View

Backlinks