|
 |
All images taken from Google SAIF documentation and similar documents.
The discussion around artificial intelligence and cybersecurity has moved beyond the question of whether organisations should use AI. Security teams are already using it to analyse telemetry, investigate alerts, generate detection queries, summarise incidents and identify suspicious behaviour. The more useful question now is how organisations can introduce AI without creating a new collection of security problems.
Google’s Secure AI Framework (SAIF) provides one way of approaching that problem. The framework is designed to apply security principles across the AI lifecycle, covering data, infrastructure, models and applications rather than treating the model itself as the entire security boundary. Google’s current SAIF guidance also includes specific considerations for AI agents, which can introduce additional risks when models are allowed to interact with external tools and systems.
 |
The important point for security professionals is that SAIF is not a completely separate security discipline. Much of it will look familiar. Identity management, least privilege, vulnerability management, threat detection, incident response, red teaming and continuous monitoring all remain important. The difference is that these controls now need to be applied to systems where data, models and AI-driven decision making form part of the attack surface.
That makes SAIF particularly useful when it is translated from a conceptual framework into practical security operations.
Start with an AI inventory
The first practical application is also one of the least glamorous: finding out what AI systems actually exist in the organisation. Most security teams already maintain inventories of endpoints, applications, cloud resources and identities. AI requires an additional layer of visibility. Organisations need to know which models are being used, where they are hosted, which datasets support them, which applications consume them and which users or services can access them.
This is especially important because AI adoption often happens outside conventional IT procurement processes. Developers may experiment with external APIs, individual teams may introduce AI-powered SaaS products, and business units may deploy internal assistants without security teams being involved.
SAIF’s risk map explicitly separates AI environments into data, infrastructure, model and application components. This provides a useful structure for extending an existing asset-management programme into AI. In practice, a security team could begin by creating an inventory containing the model or service, owner, business purpose, data sources, deployment environment, API endpoints, users, permissions and criticality.
This immediately produces a security benefit. Once AI assets are visible, they can be subjected to the same risk assessment, vulnerability management and access-control processes as other enterprise technology.
Protect the data behind the model
AI security is often discussed as though the model is the most important asset. In many environments, the data supporting that model is considerably more valuable. A customer-service assistant might have access to customer records. An internal coding assistant could process proprietary source code. A threat-hunting system might ingest authentication logs, endpoint telemetry and incident reports.
Compromising the model is therefore only one possible objective. An attacker may instead attempt to manipulate, steal or extract the data surrounding it. SAIF recommends controls including training-data management, data sanitisation, privacy-enhancing technologies and user-data management. These controls address risks such as data poisoning, unauthorised training data and sensitive-data disclosure.
Consider an organisation developing an internal fraud-detection model. Before training begins, the security team could verify the provenance of the training dataset, scan it for malicious or anomalous content and ensure that sensitive fields are handled appropriately. Changes to the dataset could then be tracked so that unexpected modifications are detectable. This is essentially data security applied to an AI pipeline. The difference is that compromised training data can influence the behaviour of the resulting model, potentially creating a security problem that persists long after the original data manipulation has occurred.
 |
Treat models as controlled production assets
Once a model has been trained or selected, it needs to be managed like any other important production component. That means maintaining version control, recording where the model came from, tracking changes and restricting access to model files and weights. SAIF specifically recommends model and data inventory management and access controls designed to minimise unauthorised access to models, weights and datasets.
For a security team, this could mean integrating models into existing change-management and asset-management processes. A new model version should have an identifiable owner and approval process. Production deployments should be distinguishable from development models. Access to model weights should be restricted to personnel and services that actually require it.
This sounds straightforward, but it becomes particularly important when organisations use a mixture of commercial models, open-source models and internally developed systems. Without inventory and provenance, determining what is actually running becomes difficult. Without access controls, model theft becomes considerably easier.
Apply Zero Trust to AI applications
AI applications should not receive implicit trust simply because they operate inside the corporate network. A useful practical application of SAIF is therefore to apply Zero Trust principles to AI interfaces.