Denying AI Exposure to Sensitive Data with Real Application Security (RAS) – Part 2
Thinking about building a chatbot with Generative AI or RAG? Or even enabling Agentic AI for your applications? You’d better think first about how you’re going to ensure your most sensitive structured data - as well as your vectorized unstructured data - remains invisible to the general public. Fortunately, that’s simple to do with one of Oracle Database 26ai’s least known toolsets: Real Application Security (RAS).
RAS in APEX: A Brief Demo
In the first part of this series, I showed you all the infrastructure for building a solid RAS security implementation for Chicago Crimes summary data, detailed arrest and incident reports, and their vectorized components.
My next step is to add generative AI capabilities into my application. Fortunately, this is quite simple in APEX 24.2.
Enabling AI In APEX
My first step is to make sure I’ve enabled my CPD workspace for AI. If the Generative AI attributes in Shared Components didn’t show up for my application, I would need to have my APEX workspaces administrator enable it (Figure 20).
Figure 20. Activating AI for Schema
Next, I’ll create a Generative AI configuration named Chatbot_LLAMA30B for my application (Figure 21):
- I’m using a preconfigured Generative AI Service (OCIGENAI) that defines the AI model and the various OCI credentials to access that service. (This will almost certainly vary within your IT organization, so I’ll leave that configuration to your senior APEX DevOps staff).
- I’ve supplied a pretty tight set of constraints within the system prompt for the chatbot, including a missive to simply say “I don’t know” when it’s beyond the knowledge provided in the document corpus.
- I’ve given it a simple welcome message to display (Figure 22).
Figure 21. Chatbot System Prompts
Figure 22. Picking a RAG Source
RAG Sources
One thing I really love about APEX 24.2 is the ability to build a RAG Source within this configuration. If you tried to implement RAG within version 24.1, you were probably as confused as I was in terms of exactly how to provide access to my corpus, document chunks, and/or embeddings. But now this is as simple as constructing a query, as shown in Figure 23.
This query returns document chunks from the CRIME_VECTORS table, which were built by applying an LLM against documents stored as BLOBs in the CRIME_REPORTS table. The WHERE clause limits retrieval to data from the CHICAGO_CRIMES table within a small range of CRIME_IDs because those are the only ones that have detailed crime reports – arrests, incidents, and even internal affairs investigations – attached to them.
Figure 23. RAG Source Query
Finally, I built a simple chatbot that opens via a dynamic action tied to a button click. Figure 24 shows the basic configuration for that.
Figure 24. Chatbot Dialogue Setup
Trust, But Verify-Build a Verification Page
One thing I’ve found extremely helpful whenever I’ve set up RAS within APEX is to include a page that shows the privileges currently granted to the RAS user, plus a few simple reports providing proof that restrictions are being applied as expected. I’ve then typically hidden that page from non-developers so I can validate what a user should see before they even connect to the application.
Figure 25 shows what this page returns when logging in as user LSNELLING, the current Chief of Police.
Figure 25. LSNELLING: Validation Results
LSNELLING can see quite literally everything from the combined map and report page (Figure 26).
Figure 26. LSNELLING: Map and Report Results
But things really get interesting when he attempts to probe more deeply with the new chatbot, searching for specific information that’s classified as either secret or confidential, by clicking on the AI Chatbot button above the map (Figure 27).
Figure 27. LSNELLING: Chatbot, Conversation #1
Note that the chatbot refused to reply with anything outside of the document corpus it can search. There are no reported murders included in any of the related documents, and it refused to speculate beyond that.
It seems that our Chief of Police has a sense of humor as well, asking the chatbot for any funny activity among the documents (Figure 28). And note the chatbot’s response queries about crime in Cicero, IL – a close “ring suburb” of Chicago – were rebuffed because the corpus has no information about that city.
Figure 28. LSNELLING: Chatbot, Conversation #2
Restricted Visibility-User WJACKSON
What will my application return to a user without tighter limits on viewing documents? If you recall from our setup earlier, user Walter Jackson (WJACKSON) was granted PII privileges but was not granted access to see documents classified as SECRET or CONFIDENTIAL, so he should be equally limited from seeing any report chunks or searching through them via chatbot functionality.
Figure 29 shows his connection was granted the CPD_DYN_PII_ROLE dynamic role, and his session is granted limited access to only two districts. However, the report below the map (Figure 30) returns much less information than it does for LSNELLING.
Figure 29. WJACKSON: Verification Results
Figure 30. WJACKSON: Map and Report Results
Officer Jackson does try to probe the crime reports and related embeddings for some interesting information, including whether he is under investigation for any wrongdoing. If you recall, he was transferred to a different district by Internal Affairs. Still, the chatbot can’t help him figure out what he may be under investigation for (Figure 31). That’s because he was not granted access to documents with a sensitivity of either CONFIDENTIAL or SECRET.
Figure 31. WJACKSON: ChatBot Results
Tightly Restricted Visibility-User NKURCHAWSKA
Finally, what will my application return to a user without any privileges to view the corpus of documents or their chunks, and embeddings? If you recall from our setup earlier, user Natalie Kurchawska (NKURCHAWSKA) was not granted any PII privileges, so she should not be able to see any report chunks or search through them via chatbot functionality.
Figure 32 shows her connection was only granted the CPD_DYN_DWRO_ROLE dynamic role, and her session is thus limited to viewing extremely limited information on the map itself (Figure 33). Note the report below the map is completely empty.
Figure 32. NKURCHAWSKA: Verification Results
The map that’s returned reflects these limits. NKURCHAWSKA only gets to see limited occurrences in the five districts she’s permitted to view. But more importantly, note there’s no detailed information below the map because she’s prevented from seeing any PII at all.
Figure 33. NKURCHAWSKA: Map and Report Results
And try as she might, her ability to query detailed reports via chatbot is also seriously limited (Figure 34).
Figure 34. NKURCHAWSKA: ChatBot Results
Conclusion-If It’s Not Hidden, Someone Will Find It
RAS is an excellent example of just how deeply secure the Oracle 26ai converged database is. Its capability to hide sensitive information within different realms (subsets of rows) based on selection criteria hidden from an end user and impenetrable to tricks like SQL injection makes it an extremely valuable tool for any DBA’s security toolbelt.
More importantly, RAS’s ability to hide data with specific columns across multiple realms portend it will be a crucial tool for preventing chatbots, RAG tools, and agents from accessing sensitive data that’s been captured from documents and then chunked and vectorized.
Happy Holidays! 🎄
Ready to Take Your Oracle Skills to the Next Level?
Join OraPub, Viscosity’s training hub for Oracle professionals, packed with expert-led courses and exclusive paid member benefits.
Check out Viscosity’s event page for upcoming virtual and on-site training opportunities.
SUBMIT YOUR COMMENT