The June 2023 intervention
This is a retrospective, not a new product announcement. On June 8, 2023, Google introduced the Secure AI Framework, or SAIF, as a conceptual framework for secure AI systems. Its six elements were: extend strong security foundations into AI; bring AI into detection and response; automate defenses; harmonize platform controls; adapt controls through feedback loops; and contextualize risk in business processes. [1]
The important historical move was not the claim that AI needed security. That proposition was already obvious amid the generative-AI boom. SAIF instead argued that AI security should be treated as a systems discipline: models, data, applications, infrastructure and operating processes had to be secured together. Google explicitly rooted the framework in practices such as reviewing, testing and controlling the supply chain, while naming model theft, training-data poisoning, prompt injection and confidential-data extraction as AI-specific concerns. [1]
That framing was useful because it resisted a false choice. Organizations did not have to discard software and cloud security knowledge when adopting AI. But neither could they assume existing controls automatically covered a model’s data lineage, behavior under hostile input, or connections to business actions.
Six principles, read as an operating model
The first principle was continuity: secure-by-default infrastructure and organizational expertise should be expanded to AI. The announcement used input sanitization and limiting—familiar responses to injection problems—as examples that could be adapted for prompt-injection-style attacks. This was an analogy, not proof that SQL-injection defenses solve prompt injection. The practical lesson is to reuse security mechanics only after testing them against the AI application’s actual interfaces and privileges.
The middle principles shift attention from a one-time launch review to operations. Detection and response should monitor generative-AI inputs and outputs for anomalies. Platform controls should be consistent across tools. Feedback loops should incorporate incidents, user feedback, updated data, fine-tuning and regular red-team exercises. These are vendor recommendations, not independent measurements of effectiveness. Still, they identify a durable operational fact: an AI system’s security posture can change after deployment as prompts, integrations, data and attacker tactics change.
The sixth principle prevents security from ending at the model boundary. SAIF called for end-to-end risk assessment including data lineage, validation and operational behavior monitoring. In practice, the risk of a summarization assistant differs materially from an agent that can alter records or invoke tools. The latter requires controls around authorization, approvals and rollback, even if both use the same underlying model.
From a pipeline to plausible attacks
Mandiant’s June 27, 2023 companion article made the lifecycle interpretation concrete. Its conceptual pipeline had six components, beginning with data gathering and ending in final production. It also described a threat-modeling process: identify components and threats, develop attack scenarios, map existing controls, find gaps, then execute remediation. [2]
This was valuable as a method rather than a universal architecture. Many organizations consume a hosted model API; others fine-tune a third-party model; only some train from scratch. Mandiant itself noted that deployment choices produce different threat models and relevant prevention and detection controls. Its GAIA Top 10 was expressly not exhaustive. [2] That limitation matters. A top-ten list can help teams start conversations, but it cannot substitute for modeling their own data flows, identities, integrations and business consequences.
The strongest connection to established controls is therefore procedural. Inventory the assets. Restrict access. protect integrity. Validate inputs and outputs. Segment environments. Monitor production. Investigate incidents. Those activities are recognizable from conventional security engineering. What AI adds is a wider set of assets and failure paths: training and evaluation data, model weights, transformation tools, prompts, retrieval sources, outputs and agent tool calls.
Assurance is evidence, not a checklist
Later Google material sharpens the distinction between building controls and proving that they work. A 2025 Google paper describes security assurance as a cross-functional effort to gain confidence that features, practices, procedures, controls and architecture enforce security policies. It highlights red teaming, vulnerability management, detection and response, threat intelligence and remediation. This is Google’s account of its approach, not independent validation of outcomes.
The later SAIF controls page makes the same architecture more explicit: governance and assurance apply across all risks and every development stage; red teaming, vulnerability management, threat detection and incident response are listed as assurance controls. [4] It also maps concrete controls to risks: authorized training data, sanitization for poisoned or sensitive data, inventories, access controls, integrity protection, input and output validation, and user approval for agent actions.
For a security leader, “assurance” should mean retained, reviewable evidence. A release decision should be able to show what model and data version were used, who authorized them, what adversarial tests were run, which failures remain, what permissions the application has, and how a production incident will be detected and contained. Passing a red-team exercise once is evidence of a test at a point in time; it is not evidence that the system remains safe after an integration, model, policy or data change.
A practical archive reading
SAIF’s 2023 contribution was to place AI inside the security lifecycle instead of treating it as a standalone model-safety exercise. Its limitation is equally clear: it was a framework published by Google, with examples and control descriptions rather than comparative independent outcome data. SecurityWeek’s contemporaneous reporting independently summarized the six-element structure, but that reporting still largely relayed the framework and Google’s positions rather than testing its effectiveness.
The practical interpretation in 2026 is not to adopt a branded taxonomy verbatim. Use the six principles as a coverage test. Can the organization name every AI asset and owner? Are model, data and tool permissions constrained? Are hostile inputs and unsafe outputs tested in the deployed context? Is there telemetry for model and agent behavior? Can the team demonstrate remediation and reassessment after change?
If the answer is no, the gap is not merely an “AI security” gap. It is an assurance gap: the organization lacks sufficient evidence that controls mediate the real system it operates. That was the enduring insight in the June 2023 announcement—and it remains more actionable than a promise that any single guardrail can secure an AI deployment.