We have all heard the stories about AI agents going “rogue” and releasing information that is commercially sensitive or private and with the unpredictability of LLMs, this is a real risk for any AI systems that try to provide an organisations data for use by an agent using an LLM.
The most common approach has always to build in the data security into the app layer, and when the only way that data can be accessed is via the app, then this is mostly OK – although it always leaves a “back-door” if the database user credentials are compromised.
If your app is a LLM-driven agent that accesses the database through a “run-sql” tool, then this opens up a real risk. There is no practical way to limit what the LLM does at the LLM level. If the LLM has access to the database credentials, then the door is open to the LLM to run whoever SQL it likes. The truth is that an LLM based agent can never be “trusted” to stay within the limits that we might try to set via prompts.
By implementing end-user data access via an LLM then we have opened up a giant security risk.
In many cases, it is the specific security and permissions for the end-user that needs to be applied, and these cannot be encoded into an LLM. What is needed is security and permissions at a much deeper layer – where the end-user credentials are provided to the database, and the security is implemented in the database core – so that no data is revealed that is intended to be private or secure or only allowed to specific privileged users.
Oracle has just announced a new capability to do exactly this – Deep Data Security. This enables the use of specific user credentials to filter data, redact data and only allow specific columns or attributes to be accessed by that user. The capability is implemented deep in the database, and is set up through SQL/DDL commands and so is constrained by the database language itself. This builds and improves on the Virtual Private Database feature which has been around for a while, but was not so deeply embedded and wasn’t available within the core database language.
But what if your source database doesn’t have specific database users? If the app that maintains the data uses a generic user login, then there is no user to link to – the privacy is only embedded within the app layer. And what about multiple database where the user ids are not aligned? This adds more complexity and security risk.
Fortunately, these is a straightforward answer to this – one that also allows this new feature to be used against data held in user versions of oracle database, and even non-oracle sources.
The recommended approach to use an Oracle AI Database as a federation layer over older databases, database with generic users and over non-oracle data sources. With Oracle links and gateways, over 100 types of data sources can be mapped to oracle tables or views. End users can then use their LLM to query the Oracle AI database using MCP with their personal credentials, the the deep data security specifies which data across all of those sources should be made accessible to the specific end users.
Take a look at Deep Data Security and see what you think
Simon Griffiths 
Leave a comment