Securing generative AI: A practical guide for CISOs

If you are a CISO today, you are probably living in two different worlds.

In one, your board and business leaders want generative AI everywhere. Faster customer support, smarter operations, better analytics. In the other, your threat landscape just expanded to include systems that behave in ways none of your traditional controls were designed to handle.

You are now expected to keep your cloud environment safe from new risks, such as OWASP large language model (LLM) top 10 vulnerabilities. In this guide, I break down the key risks introduced by AI systems and outline architectural principles that will help you contain those risks and protect sensitive data.

4 security risks genAI introduces (& why CISOs should care)

One of the biggest mistakes I see among teams building AI tools is that they jump to execution without first understanding how it would expand their attack surface. There are four places where that exposure typically appears:

1. Prompt attacks can trick LLMs

Prompt injection is no longer an academic concern. There have been several instances of users talking models into revealing internal logic, leaking sensitive data, or ignoring restrictions you thought were hard-coded. A 2025 study of 10,000 real-world custom GPTs revealed that over 98.8% of GPTs were vulnerable to instruction leaking attacks via one or more adversarial prompts.

2. Training data exposure is difficult to undo

It is very easy for your team to pull emails, chats, logs, or customer records into training datasets. Once this data enters a training pipeline, you cannot remove it with a simple delete. The model has been shaped by it. You now carry a long-lived privacy and compliance risk that is hard to audit and even harder to explain later.

3. Over-permissive roles

AI pipelines often end up with over-privileged service identities. It’s common to see broad access to data stores, unrestricted permissions across AI platforms, and administrative control over underlying compute and automation layers.

For example, if an attacker takes advantage of over-permissive IAM roles in an AWS environment, they can:

• Read all training datasets and model artifacts across multiple S3 buckets
• Modify models and tamper with their behaviour
• Delete logs that would have helped your investigation
• In extreme cases, gain effective control of the entire AWS account

This is why AI workloads must follow strict least-privilege policies, so each component only receives the specific permissions it needs and nothing more

4. The problem of shadow AI

The last category is the one that often catches leaders off guard. Staff plug in unauthorized AI tools, automation platforms like n8n, and random LLM APIs into their workflows without proper approvals. While it feels productive, it also leads to unmanaged data movement and a host of compliance issues.

A recent study revealed that 56% of security professionals acknowledged the use of AI by employees in their organization without formal approval, with another 22% suspecting it’s happening.

If you cannot see prompt behaviour, training inputs, or data flows to third-party tools, your organisation is already exposed. The question is only when that exposure turns into an incident.

How to secure your genAI environment

A secure genAI environment is built around a few non-negotiable design choices. These solutions help you consistently keep AI behaviour predictable, contain failures, and preserve trust.

1. Enforce least privileged access for every AI component

Least privileged access must be the first principle across your organization. GenAI workloads should have narrow permissions with clear boundaries for who can train, deploy, or call the model. This prevents a compromised component from moving laterally or touching datasets it was never meant to see.

2. Control & filter interactions with your model

LLM guardrails, such as Amazon Bedrock Guardrails and NVIDIA NeMo Guardrails, act much like a WAF for LLMs by filtering harmful prompts and reducing the risk of PII leakage at the application layer. However, just as a WAF cannot fix SQL injection by itself, guardrails remain only a surface-level control. Real protection still depends on securing the underlying data, enforcing proper identity management and role-based access, and architecting AI systems so sensitive datasets never reach the model in the first place.

3. Segment AI workloads & restrict connectivity

AI workloads should sit inside a dedicated VPC so model endpoints are properly segmented from the rest of your environment. Think of it the same way you design a three-tier architecture where the web, application, and database tiers live in separate network segments. In the same way, your AI model endpoints belong in their own segment.

Placing AI platforms or model-serving infrastructure inside isolated VPC segments creates a clean separation between AI workloads and the rest of your infrastructure, eliminating unnecessary access paths and making lateral movement significantly harder for attackers.

4. Limit pipelines to specific, approved data sources

Ensure each pipeline has access only to the exact storage buckets or locations it is meant to use, nothing more. Limiting pipelines will help you prevent accidental ingestion of sensitive data and reduce the blast radius if a pipeline is compromised.

5. Encrypt at rest with a key management service

Use managed key encryption to protect prompts, responses, datasets, and model artifacts across the entire lifecycle. This ensures that sensitive information is never exposed in plaintext as it moves through training, retrieval, and inference pipelines.

6. Strengthen detection & response capabilities

You should be able to trace every model invocation: who accessed it, what parameters were used, and how the system responded. Centralized audit logging tools will help you capture every model and platform API call, while a unified security monitoring layer, such as AWS Security Hub, Microsoft Sentinel, and Google Security Command Center, aggregates findings and anomalies. Together, these tools will give you the visibility required for investigations, compliance, and detection of unusual behaviour.

7. Continuously monitor model-level behavior

Monitor both network traffic and model-level activity continuously so unusual patterns are caught early. This includes network traffic monitoring within isolated environments, system and application metrics tracking, and newer model observability capabilities that provide visibility into prompts, model reasoning steps, tool calls, and output provenance in agentic applications. Continuous monitoring helps you see not only what is happening on the network but also how the model itself is being used.

8. Block sensitive data before it enters AI pipelines

A sensitive data discovery service like Amazon Macie or Microsoft Purview acts as an early-detection layer in any AI security architecture. Use it to scan storage locations for PII or secrets and trigger automated workflows that quarantine or block flagged files, preventing them from flowing into downstream AI training or inference pipelines.

This combination (isolated network paths, strict data boundaries, strong guardrails, and deep observability) gives you a level of control few AI deployments achieve today. And the difference becomes obvious the first time something goes wrong.

Imagine deploying an AI customer-support assistant on an AWS environment with broad access to internal knowledge bases. There’s no segmentation, guardrails are missing, and logging is limited. A malicious user starts probing the system with crafted prompts. Slowly, they coax the model into returning HR documents the assistant was never meant to touch. Nothing alerts you. No logs explain what happened.

Now contrast that with a system built on the architecture above:

• Segmentation limits the data that the model can even reach.
• Bedrock Guardrails block the attempt at the door.
• CloudTrail surfaces suspicious prompt sequences instantly.

The same attack becomes harmless because you designed an environment that contains model behaviour even under pressure. This is exactly why a simple, structured approach to AI security is effective.

Data discipline goes a long way

Data protection is the one part of your AI program that you cannot afford to ignore. If the wrong data enters your pipelines, everything downstream becomes harder to secure. A little discipline makes all the difference, and it all starts with these principles:

• Sanitise, approve, and verify every dataset before it enters a workflow: RAG pipelines are only as safe as the information you feed them. If the input is messy or sensitive, the model will reflect it.
• Lock down the storage locations that hold AI data: Enforce strict access controls, mandatory encryption, and full logging so you always know who touched what and when. Visibility is your safety net.
• Keep sensitive data inside your cloud environment: Do not allow external tools to pull content out of your environment. Most accidental breaches start this way, usually through a well-intentioned integration that moves data into places you cannot govern.
• Treat fine-tuning data as a governance problem: You need clear rules for which datasets can be used, how they are validated, and whether they support the business outcome you are targeting.

Data is the fuel for your AI systems, and one unvetted dataset is enough to cause compliance issues, privacy exposure, and reputational damage. However, data is also the most common source of avoidable risk. If you control data, you control the behaviour of the model.

Where CISOs should begin

We’ve covered a lot of ground, and by this point, you’re probably thinking about where to even begin. I suggest starting by creating a list of approved AI models and approved datasets. Test every model for prompt injection before it goes live, and run a basic threat-modelling exercise for each AI application to identify who might attack the system, what they could target, and how the model could be abused. This will help you add AI risks to your enterprise risk register so leadership understands the exposure.

Once you understand genAI risks, you can build a simple incident response plan for its misuse. Most importantly, ensure that your Security, Engineering, and Data teams work together from the beginning. AI projects create risk when security is treated as an afterthought.

Generative AI can give your organisation a true competitive edge. However, the advantage only holds if you deploy it with discipline. Putting the right safeguards for your models, data, and customers might seem like it slows innovation. In reality, it’s what builds trust, reduces risk, and positions your organisation for long-term success with AI.

Learn how Modus Create’s AI security services can help your business →