Retrieval-Augmented Generation (RAG) has become one of the most practical ways for organizations to extend large language models with their own data. As Charles Chibueze, CISSP and Omorinsola Goriola, CISSP explain, such systems process proprietary documents, accept free-form user prompts, integrate with cloud APIs and generate responses that can directly influence real-world actions. They share what they learned from implementing a RAG system.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
During an engagement with a manufacturing customer, our task was to help deploy a custom RAG architecture that technicians could rely on for operational guidance without risking data leakage or unauthorized access.
Across multiple engagements, we’ve worked with customers in manufacturing, mining, and SaaS environments, all of which wanted to use RAG to improve internal knowledge access, technical troubleshooting and decision support. The customers we worked with also chose to own most of the RAG architecture rather than rely entirely on a fully managed cloud service. This meant responsibility for securing each component, from document ingestion to model inference.
In each case, the business value of a successful RAG project was clear. What was less clear at the start was how easily a poorly secured RAG system could expose sensitive data or become a new attack surface in the cloud. Architectures included a document repository for structured and unstructured data, embedding models, a vector database, a large language model inference endpoint, retrieval and augmentation logic and a CI/CD pipeline supporting continuous updates. Because these components were tightly integrated, weaknesses in one layer could easily affect the rest of the system.
Securing the Document Repository
The first security challenge we encountered was not the language model itself but the data ‘feeding’ the system. During early discussions, we realized that not all source documents were suitable for inclusion in the RAG pipeline: some contained sensitive information, while others hadn’t been properly classified.
For the manufacturing customer, we introduced a pre-processing workflow before documents ever reached the RAG repository. Incoming data was scanned and classified using existing, cloud-native, data classification services. Documents containing sensitive or regulated information were either redacted or routed to a separate location for human review. This step prevented inappropriate data from being embedded and indexed in the first place.
We tightly restricted access to the document repository: only specific services involved in ingestion and retrieval were granted access. Human users were deliberately excluded. This reduced the risk of accidental exposure and ensured the repository could not be browsed directly.
During our threat-modelling sessions, the vector database quickly became a focal point: once documents are embedded, the vector store effectively becomes a condensed representation of sensitive knowledge. In our implementation, the vector database was placed in a private network segment with no direct internet exposure. Encryption was enforced both in transit and at rest, and access was limited through narrowly scoped identity roles.
Initially, we underestimated how frequently engineers might want direct access for debugging. However, we found that granting temporary, audited access through controlled sessions was far safer than leaving persistent permissions in place.
We also enabled monitoring on query patterns. This proved valuable later when we tested for abnormal similarity searches that could indicate misuse or attempted inference attacks.
Large Language Model (LLM) Access and Guardrails
Prompt injection and unintended data disclosure were recurring concerns raised by customers. So, rather than assuming the model would behave safely, we treated the LLM as an untrusted component that required strong controls. In practice, we implemented input validation and prompt normalization before requests reached the model. We also restricted which system prompts could be used, to prevent users from overriding core instructions.
On the output side, responses were filtered to ensure they aligned with the user’s authorization level and did not reference restricted content.
We locked down access to the LLM endpoint using short-lived tokens and strict rate limits. This prevented the endpoint from being reused outside the RAG application – a risk we had initially overlooked during early design discussions.
Retrieval Logic and Data Segmentation
One lesson we learned early on was that retrieval logic can unintentionally bypass access controls, if data sources are not segmented properly. In the manufacturing environment, different groups of users required access to different knowledge domains.
To address this, we separated data sources and indexes by role. The retrieval layer enforced these boundaries, ensuring that a technician could retrieve only documents relevant to their function. This design choice added complexity, but it eliminated the possibility of scenarios in which users might indirectly access unauthorized information through clever prompting.
Securing the MLOps Pipeline
The CI/CD pipeline supporting our RAG system introduced its own risks: model updates, embedding refreshes and document ingestion jobs all relied on automated workflows. We secured this pipeline by limiting permissions, isolating environments and storing secrets in managed secret services rather than configuration files. All deployed artifacts were signed and tracked, enabling us to verify exactly which version of a model or retriever was running at any time. This proved especially helpful during incident response simulations.
Identity, Access Management and Application Exposure
Identity and access management was the connective tissue across the entire system. For this customer, we mapped every service interaction and enforced least-privilege access at each layer.
Authentication and authorization were implemented not only at the application level but also between internal services. We used short-lived, session-based credentials and ensured that all access was logged. This made it possible to trace a user request from the UI through retrieval and generation, which later became essential for auditing and troubleshooting.
The external API and user interface were protected behind an API gateway with web application firewall and DDoS protection. We also took care to remove sensitive prompts and responses from logs, an issue we encountered during early testing when verbose logging exposed more information than intended.
Observability
Visibility was critical once our systems moved into production. We implemented end-to-end audit trails linking user sessions to prompts, retrieved documents and generated responses. This allowed us to detect unusual behavior, such as repeated prompt patterns associated with injection attempts.
Compliance and Data Governance Considerations
Even with advanced AI systems, traditional data governance still applies. We worked closely with the customer to ensure data residency requirements were met and that responsibilities under the cloud shared responsibility model were clearly understood. The cloud provider secured the underlying infrastructure, while we focused on securing the application, data and access layers.
Closing Thoughts
What we learned from our engagements and have described here, is that securing a RAG system in the cloud requires more than protecting prompts or encrypting storage. In our real-world experience, success comes from treating the system as a full application stack, in which data quality, access control, model behavior and operational visibility all mattered equally.
It’s our strong advice to anyone considering RAG that you should start by understanding your architecture choices and data strategy before adding generative AI on top. Whether your system is fully managed or largely custom-built, the same principle applies: security must be designed-in from the start, informed by real workloads and real users, not added as an afterthought.
Charles Chibueze, CISSP, has over 10 years of experience in cybersecurity fields including cloud security, application security, GRC and consulting. He has held technical and management roles, with responsibility for designing security architectures, leading SOC operations and implementing compliance programs.
Omorinsola Goriola, CISSP, has 14 years of experience in cybersecurity and cloud security across financial services, public sector, consulting, enterprise systems and regulated industries. He has held business, management and technical roles, with responsibility for designing secure architectures, leading teams, advising executives, delivering transformation programs.
For You, By You: Join Us and Build ISC2's AI Security CertificationAs cybersecurity professionals evolve and adapt their skillset and job functions because of AI, ISC2 has announced the development of a new AI security certification to recognize and benchmark AI skills and competence within the cybersecurity workforce. The AI security certification development process presents an opportunity for cybersecurity professionals to input into the process and help define parameters for the certification. This is your moment to play a defining role at the foundation of this new certification:
For more information about the ISC2 AI security certification program and how to contribute to the various development activities taking place, go to https://www.isc2.org/new-ai-certification. |
