{"id":112048,"date":"2026-08-17T12:00:00","date_gmt":"2026-08-17T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112048"},"modified":"2026-08-03T15:55:26","modified_gmt":"2026-08-03T15:55:26","slug":"how-to-implement-deep-data-security-deepsec-in-oracle-26ai-complete-step-by-step-guide-part-one","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/oracle-databases\/how-to-implement-deep-data-security-deepsec-in-oracle-26ai-complete-step-by-step-guide-part-one\/","title":{"rendered":"How to implement Deep Data Security (DeepSec) in Oracle 26ai: complete step-by-step guide (part one)"},"content":{"rendered":"\n

So you\u2019ve been tasked with deploying a Generative AI, RAG (retrieval-augmented generation)<\/a>, or Agentic AI application. Have you thought about how to secure your most sensitive structured data<\/a> – as well as your vectorized unstructured<\/em> data? <\/p>\n\n\n\n

The good news is, it\u2019s relatively simple to implement complex security policies through the latest release \u00adof Oracle Database 26ai Deep Data Security (DeepSec)<\/a>.<\/strong> <\/p>\n\n\n\n

In this guide, part one of my Oracle 26ai Deep Data Security (DeepSec) series<\/a>, I’ll show you how – and will explain everything you need to know along the way.<\/strong><\/p>\n\n\n\n

Welcome to a security nightmare <\/h2>\n\n\n\n

Imagine this scenario. You\u2019re the only Oracle<\/a> DBA on a team of seasoned application developers, and you\u2019ve just received a new mandate from the Chief of Police. Passed down from the new Mayor, the mandate involves implementing an AI-enabled chatbot that\u2019ll access public and private information about crimes committed within the City.<\/p>\n\n\n\n

The Chief wants to make it simpler for authorized personnel – such as district commanders, detectives, cops on the beat, criminologists, reporters, etc – to review data on crimes dating back to 2001. The Chief also knows that there is sensitive data within the current<\/em> database that not everyone should see. <\/p>\n\n\n\n

So, he needs you to guarantee one thing: only law enforcement personnel with proper permissions and clearances should see that information.<\/p>\n\n\n\n

How do you achieve this level of privacy?<\/h3>\n\n\n\n

The basic ERD (entity relationship diagram)<\/a> below shows how crime data is organized within the CPD schema. The callouts illustrate the complexity of the data security<\/a> policies you\u2019ll need to implement to ensure each user only sees the data they\u2019re permitted to see.<\/p>\n\n\n\n

\"An
Chicago Police Department (CPD) schema and security requirements.<\/em><\/figcaption><\/figure>\n\n\n\n

Implementing data security requirements already looks a bit tricky, even with only five database objects.\u00a0Now imagine how difficult it would be to build a comprehensive security strategy<\/a> with only a series of database views that restrict viewing of specific rows<\/em> within some tables for each user, based on which police district(s) they’re currently assigned to. <\/p>\n\n\n\n

All while simultaneously hiding content of specific columns<\/em> within other<\/em> tables<\/em>, of course.<\/p>\n\n\n\n

Another crucial requirement is the ability to immediately<\/em> reassign<\/em> security privileges whenever a law enforcement officer (LEO) needs to urgently view data. <\/p>\n\n\n\n

Perhaps they’ve been assigned to investigating crimes in one or more police district, or they’re restricted from viewing crime data that\u2019s been marked as sensitive, secret, or confidential. They now need access to the data, and fast.<\/p>\n\n\n\n

What about when it all goes wrong?<\/h3>\n\n\n\n

We\u2019ve all watched enough police procedurals to know what happens when it goes wrong for a LEO. Let’s say, for example, they’re suddenly under investigation for bribery. The immediate result? They need to be blocked – urgently – from seeing internal affair reports on their potentially illicit activity.<\/p>\n\n\n\n

What about a copper whose close friend has been accused of domestic violence? Perhaps the friend wants to find out what particulars their victim has reported? Worse still, maybe even find out in which shelter the victim now resides?<\/p>\n\n\n\n

In all of these cases, the implications of poor security administration are potentially devasting. Fortunately, you’re reading this article, so the answer is simple. You must implement Oracle 26ai Deep Data Security (DeepSec).<\/strong><\/p>\n\n\n\n

Why data security is a complex web of limiting access<\/h2>\n\n\n\n

I first began investigating Oracle database security features a few years ago, during a stint as DBA for an Oracle Database 19c<\/a> project. The DBA team I advised needed to implement a sure-fire method to limit users from viewing or changing data they shouldn\u2019t.<\/p>\n\n\n\n

The team had already attempted to implement Virtual Private Database (VPD)<\/a>, but with limited success. They’d rolled back their efforts after extreme frustration, and with good reason. Their complex data security requirements spanned dozens<\/em> of tables, views, and materialized views<\/a> across multiple schemas.<\/p>\n\n\n\n

After some research, I helped them prototype a new security model using Real Application Security (RAS)<\/a>, VPD’s successor.<\/p>\n\n\n\n

We also needed to tackle unexpected issues to implement RAS. We needed it to enforce row-level<\/a> and column-level security within several robust and complex Application Express (APEX)<\/a> applications. It didn\u2019t help that, at the time, reliable documentation on how to integrate RAS with APEX was lacking.<\/p>\n\n\n\n

\n
\n
\n
\n

Protect your data. Demonstrate compliance.<\/h3>\n
\n With Redgate, stay ahead of threats with real-time monitoring and alerts, protect sensitive data with automated discovery & masking, and demonstrate compliance with traceability across every environment. <\/div>\n <\/div>\n Learn more<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

That wasn’t all…<\/h3>\n\n\n\n

There was one final wrinkle – my client\u2019s user base, which also included several \u201cpower users\u201d. These users typically used either SQL*Plus<\/a> or SQL Developer<\/a> to access their production database directly. They would then extract data in read-only mode for their own data warehouses<\/a> or analytics. This meant we had to configure these power users as external RAS users.<\/p>\n\n\n\n

Further, my client didn\u2019t have the funding (or expertise) to set up an identity management system<\/a> like Microsoft Active Directory (AD) or Oracle Identity Access Management (IAM)<\/a>. We therefore had to rebuild the security control mechanisms that were stored within their central database.<\/p>\n\n\n\n

Last year I wrote about how RAS would be deployed in this scenario for the CPD schema within an Oracle 26ai database<\/a>. I followed it up by explaining how RAS worked in concert with an AI chatbot deployed through Oracle APEX to limit end users from viewing outside their range of privileges<\/a>.<\/p>\n\n\n\n

That\u2019s a good counterpoint to what I\u2019ll be showing in this article, as well as future entries in the series. I suggest having a look at them before reading on.<\/p>\n\n\n\n

How to implement Oracle DeepSec<\/h2>\n\n\n\n

The good news is, if you\u2019re working with APEX 24.2<\/a> and<\/em> Oracle Database 26ai, DeepSec is easy to implement. It’s also perfect for limiting access to data at both the row and column level with APEX applications.<\/p>\n\n\n\n

Let’s focus on a typical workflow (below) to implement Oracle DeepSec. I’ll run through the whole process step-by-step, in detail.<\/p>\n\n\n\n

\"An
Oracle DeepSec implementation strategy<\/em>.<\/figcaption><\/figure>\n\n\n\n

Prerequisites and assumptions before getting started<\/h3>\n\n\n\n

The rest of this article assumes the following prerequisite steps have already been completed:<\/p>\n\n\n

\n