For two years, almost every conversation Varun Carlay, CISSP, CCSP, has had about Retrieval-Augmented Generation (RAG) has included the same nervous question: how do we make sure the database does not send more data to the LLM than the user is allowed to see? It’s the right question, but are we focusing on the right area for the answer?
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Most artificial intelligence (AI) security conversations start with the model: jailbreaks, agent manipulation, output leakage. Those risks are real. But, in RAG security reviews across public-sector engagements, the sharpest questions I’ve been asked came not from AI teams or architects reviewing prompt filters, but from the data owners.
An agency would want to ship an internal assistant across policies, case files and benefits guidance. The AI team had built the pipeline, the security team had reviewed guardrails. Then someone in the data office would ask: “What happens when the assistant retrieves a chunk a user isn't authorized to see under FERPA, CJIS, or IRS Publication 1075?” The room would go quiet.
Often, in early RAG designs I reviewed, the answer was uncomfortable: there was little in the retrieval path to prevent it. OWASP’s GenAI Data Security guidance names this through findings on sensitive data leakage, vector store exposure and unsafe natural-language data gateways – with the same root cause across all of them.
When Every User Looks the Same to the Database
The deepest design flaw – that I keep seeing – is collapsed identity. A user authenticates to the AI application, but the database sees only one service account with broad read access – the easiest way to ship the proof of concept.
In agentic deployments, the problem compounds: the database may see neither the human user nor the AI agent acting on that user’s behalf. It may only see a shared runtime account. The agency believes its users have different permissions, but the data layer doesn’t know that.
The first time I walked an agency team through this, we ran two queries side by side from the AI application; both succeeded. Neither carried any information about which human had submitted the query; from the database’s perspective, every identity representing an agency employee was treated as the same user. The mood in the room shifted; it was the moment that team stopped treating RAG security as an LLM problem and start treating it as a data access problem.
A stronger solution to collapsed identity is a database that understands end-user identity natively, not just the service account presenting the connection. In this model, the AI application passes a token proving who the human user is; the database validates that context and applies per-user access policy - row-level predicates, column restrictions and operation limits – to every query, including those generated by an AI agent. The service account becomes a transport mechanism, not an authorization boundary. The database knows who is actually asking and can enforce accordingly, without relying on application-side filters after retrieval.
This is zero trust applied to retrieval. In that context, the retrieval engine can answer one question on every query: is this user, through this agent and application path, allowed to retrieve this chunk? If the answer is no, the chunk should never be returned – not filtered later, not censored in the prompt. It should never be retrieved.
The Controls That Have Done the Most Work
When teams ask me how to make that real, my answer is the database security toolkit they already own (the same one auditors expect under NIST 800-53) applied to AI workloads. Four controls here have done most of the work for me in real engagements:
- Row-level security across documents, chunks and embeddings: From what I've seen, the highest-leverage control is policy attached to the data itself, it's the one I recommend first. When a similarity search runs, the database evaluates the requester’s session context and silently filters out rows the requester is not authorized to see. The embedding might match and the chunk might be the most relevant in the corpus. It doesn’t matter: the row never enters the result set. I once demonstrated this to a public-sector technology team which was skeptical that an AI assistant could be controlled reliably. By the end, the question had shifted, from whether it could be done to how to scale it.
- Label-based security across the vector index: For regulated workloads, such as student records under FERPA, criminal justice information under CJIS, federal tax information under IRS Publication 1075, discretionary policies are not enough. During one engagement, we extended an existing classification scheme into the vector pipeline: every chunk inherited its source classification and the retrieval engine refused to release content whose classification exceeded the requester’s clearance. An agent at one clearance level could not retrieve data labeled higher, even when the question was rephrased or asked in different ways.
- Dynamic data redaction: Sometimes the user can see the row but not every column. A benefits case worker needs the case summary – but not the Social Security numbers, protected health information, or financial details stored alongside it. Dynamic redaction masks those fields at query time based on who is asking, without changing the stored data and without asking the application to track which fields are sensitive. I have used this to bring AI assistants live in environments where the security team would never have approved direct table access.
- A database firewall for the AI agent’s queries: This is one of the controls that teams often underestimate. AI applications can generate SQL that’s valid, but unexpected. A prompt injection, tool-use mistake, or overly broad user request can push an agent toward queries it was never meant to run: schema exploration, cross-jurisdiction joins, or select-everything statements. A database firewall helps by learning the normal query patterns for the retrieval service and blocking or flagging queries that fall outside those patterns. In practice, this can catch behavior that ordinary application logging may miss.
The Vector Store Is Not a Free Pass
A vector store is not less sensitive than the source system. Embeddings and chunks are derived from real government data – think case files, student records, investigative notes – and, even when not directly human-readable, they leak meaning, relationships, and document presence.
If the source system has strong permissions and the vector index does not, the agency has just created a less well-governed copy of its most sensitive content! Write controls matter too: restricting who can insert, update, classify, or relabel chunks is just as important as restricting who can query them. Wherever I can, I keep retrieval close to the governed data so the same controls protect both traditional queries and similarity search.
What I Tell Agencies Now
The version of this story that ends well is layered. The AI application defends against prompt injection, the retrieval service runs with least privilege and the database enforces identity-aware access, redacts sensitive fields, blocks unexpected queries, auditing what matters. An AI service account should not become a back door into sensitive data areas such as payroll, justice, tax, or benefits records.
But the layer I argue hardest for is the database. Prompt filters are easy to bypass and output checks are easy to evade. The database is the one place in the stack where a “no” actually means no, and where the audit evidence on which your compliance program already depends is generated.
So, when a state or local agency tells me they are nervous about putting their data behind an AI assistant, my answer is the same: the controls you need are already in your data platform. Turn them on, scope them to the AI’s identity and let the database decide. That is the most underused message in public-sector AI security. My practical test now is simple: can we identify the user, distinguish the AI agent acting on that user’s behalf, constrain both, filter rows before retrieval, mask sensitive fields, block unexpected query patterns, and audit the whole path?
These examples come from my own experience, but the underlying patterns are industry standard. Row-level security and dynamic data-masking are native to most modern enterprise databases. Label-based mandatory access is built into some platforms and approximated through policy tags in cloud data warehouses. As vector data can now live in the same engine as the source data, these same controls extend to similarity search instead of a separate, less-governed vector store. Database firewalling, sometimes called database activity monitoring is available natively in a few engines and through dedicated security tools for the rest. Identity-aware authorization is also maturing: some engines can now accept a verified end-user and agent identity at runtime and enforce row, column and cell-level policies per request, rather than relying on application-side logic.
The strongest architectures treat the service account as a transport mechanism and let the database enforce access based on the actual user, agent, and runtime context.
Varun Carlay, CISSP, CCSP, has more than 20 years of experience in enterprise technology, spanning cloud architecture, cloud security and data engineering. He has held business, management and technical roles, with responsibility for the secure migration of sensitive, critical workloads to public cloud. His cybersecurity work spans hybrid and multi-cloud strategy and IAM.
