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.

Consider an internal AI assistant connected to an organisation’s document repository. The assistant might be able to retrieve HR documents, financial information and technical documentation. Giving the AI broad access because it is an “internal” application creates an unnecessary security boundary.

Instead, access should be determined by the identity and permissions of the user making the request. This becomes even more important when AI systems can take actions rather than simply return information. An assistant that can create tickets is relatively low risk. An agent that can modify cloud infrastructure, reset credentials or delete resources has a much larger potential blast radius.

Google’s more recent SAIF guidance specifically highlights identity propagation for agentic AI and warns against giving agents broad service-account permissions. Actions performed on a user’s behalf should be appropriately controlled and permissioned. For security teams, the practical rule is straightforward: an AI agent should not have more authority than the user and task require.

Put controls around inputs and outputs

One of the most recognisable AI security problems is prompt injection. An attacker may provide malicious instructions through a document, web page, email or direct prompt in an attempt to influence the model’s behaviour. The risk becomes more serious when the model has access to external tools.

SAIF therefore includes input validation and sanitisation as a control against adversarial queries and output validation and sanitisation to prevent dangerous or inappropriate model output from being passed into downstream systems. A practical example would be an AI-powered threat intelligence assistant that reads external reports.

The assistant might encounter an embedded instruction attempting to make it ignore its system instructions or disclose internal information. An input-handling layer can identify and restrict suspicious content before it reaches the model. Outputs can then be checked before being passed to another application or used to trigger an action.

Google’s current security tooling illustrates how this can work operationally. Its Model Armor capability, for example, is designed to inspect prompts and responses and help mitigate risks including prompt injection, jailbreaks and sensitive-data leakage.

The underlying principle is vendor-neutral: do not assume that either model inputs or outputs are trustworthy simply because they have passed through an AI system.

Give AI agents narrowly defined permissions

Agentic AI represents one of the most important practical applications of SAIF.

A conventional chatbot generally produces an answer. An agent can potentially make changes to systems, invoke APIs and interact with other software. This changes the security model: imagine an AI-powered SOC agent responsible for investigating suspicious accounts. It might need permission to read authentication logs, query endpoint telemetry and retrieve threat intelligence. It probably does not need permission to delete accounts, modify firewall rules or change identity policies. Least privilege therefore becomes a critical control.

SAIF recommends limiting the number of tools an agent can interact with and restricting the actions it can perform. It also recommends contextual and dynamic permissions rather than simply giving an agent a large static set of privileges. This can be implemented using existing IAM infrastructure. An investigation agent could receive read-only access by default. If it reaches a point where containment is appropriate, the proposed action could be presented to a human analyst for approval. A separate privileged workflow could then execute the approved change.

This produces a useful division of responsibility: AI investigates quickly, while humans retain control over high-impact actions.

Make AI activity visible to the SOC

If an organisation monitors its users, endpoints and applications but cannot see what its AI systems are doing, it has created a significant blind spot.

Logging therefore becomes another practical SAIF requirement.

Security teams should capture relevant information about AI interactions, including authentication, model access, tool calls, unusual prompts, sensitive-data access and agent actions. Google’s current SAIF controls specifically include agent observability, with an emphasis on making agent actions and tool use transparent and auditable.

This information can then feed existing SIEM and threat-hunting workflows.

For example, a SOC might create detections for an AI agent suddenly accessing an unfamiliar database, making an unusual number of API calls or attempting to use a tool outside its normal operating pattern.

AI security telemetry therefore becomes another source of security intelligence.

The threat-hunting team can begin asking questions such as whether an agent’s behaviour has changed, whether a compromised identity is manipulating an AI application or whether an AI system is attempting to access information outside its normal operating scope.

Test AI systems like applications

AI systems should not be considered secure simply because they passed conventional penetration testing. Their behaviour depends upon data, models, prompts and application architecture, creating attack paths that conventional application testing may not fully expose.

SAIF therefore incorporates red teaming, vulnerability management and threat detection into its assurance controls. A practical AI red-team exercise might attempt prompt injection, sensitive-data extraction, privilege escalation through an agent, malicious tool invocation or manipulation of model inputs.

For example, an organisation could give a red team access to an internal AI assistant and ask whether it can be persuaded to retrieve documents belonging to another department. If the assistant succeeds, the problem is not necessarily the model itself. It may indicate weaknesses in application authorisation, data segmentation or identity propagation.

AI security testing should examine the entire system rather than concentrating exclusively on model behaviour.

Connect AI security to threat hunting

This is where the framework connects directly with the threat-hunting practices discussed earlier in this series.

Once an organisation has identified its AI assets and established logging, those systems become legitimate threat-hunting targets. A hunter might investigate unusual access to model repositories, unexpected changes to training datasets, anomalous API calls from AI applications or suspicious tool usage by agents.

The same AI capabilities that make conventional threat hunting easier can also be applied to AI security itself. Machine learning can establish baselines for normal agent behaviour. Large language models can help analysts interpret AI-specific logs. Automated systems can correlate an unusual prompt with subsequent API calls and identity events.

The organisation effectively creates a feedback loop: AI improves security operations, while security operations monitor and protect the AI systems performing that work.

Build incident response around AI failure

Finally, organisations need to consider what happens when AI security controls fail. An AI-specific incident response process does not necessarily require a completely separate incident-response team. Existing procedures can be extended with AI-specific playbooks.

If an agent begins making unauthorised changes, responders need to know how to revoke its credentials and terminate active sessions. If training data is discovered to have been poisoned, the organisation needs to know which model versions may have been affected. If sensitive information is exposed through an AI application, responders need to determine what data was accessed, by whom and whether it was subsequently retained or transmitted elsewhere.

These are familiar incident-response questions applied to a new class of technology. The important point is preparation. Security teams should not be designing their first AI incident-response procedure during an active compromise.

Making SAIF practical

The most useful way to approach SAIF is not as another compliance checklist.

It is a way of asking better security questions about AI:

• Where is our AI?

• What data does it use?

• Who can access it?

• What can it do?

• What happens if its inputs are manipulated?

• What happens if its outputs are wrong?

• Can we see what it is doing?

• Can we stop it quickly?

• Can we prove what happened afterwards?

• These questions fit naturally into existing security architecture reviews, threat modelling, vulnerability management, red teaming and SOC processes.

That is ultimately what makes SAIF useful to cybersecurity professionals. It does not require organisations to abandon established security practice. Instead, it extends those practices to a technology where the application logic is influenced by data, models and probabilistic behaviour.

The practical value of secure AI

AI is already making security operations easier. It reduces the amount of manual analysis required to investigate incidents, accelerates threat hunting and allows smaller teams to process security data at a scale that previously required much larger workforces.

The next challenge is ensuring that this additional capability does not create an equivalent increase in risk. SAIF provides a useful framework for doing exactly that. Inventory the AI environment. Protect its data. Control model access. Validate inputs and outputs. Apply least privilege to agents. Monitor AI activity. Red-team the system. Prepare for incidents.

None of these ideas are particularly alien to a competent security team. The significant change is that the same principles now need to encompass models, datasets and autonomous agents alongside servers, endpoints and applications.

For organisations already experimenting with AI-powered security operations, that makes SAIF less of an abstract AI governance framework and more of a practical extension of everyday cybersecurity. The objective is not simply to make AI secure, but, rather, it is to make AI useful enough, observable enough and controllable enough that security teams can confidently use it to do more work, faster, without losing control of the systems they are defending.