Database & AI Notes

Oracle AI Database 26ai introduces an important new feature called Deep Data Security, built to provide much stronger protection for your organization’s most critical business data.

As agentic AI moves from experimentation into production, protecting data becomes far more challenging. AI agents can generate SQL dynamically, deciding what to query, how to query it, and when to run it.

That creates major opportunities for productivity and automation, but it also introduces real risk. If generated SQL is overly broad, insufficiently constrained, or influenced by prompt injection, sensitive data can be exposed or modified in ways the application never intended.

That is exactly why Oracle Deep Data Security matters.

The Problem With App-Only Security

Many systems still enforce authorization in the application layer. That approach can work when the application is the only place queries are built and executed. It starts to break down when:

• AI generates SQL dynamically at runtime
• multiple apps and tools share the same database
• AI-assisted development produces inconsistent, weak authorization logic
• RAG and vector retrieval flows depend on filtering outside the database

In those environments, it becomes much harder to guarantee that every access path is applying the right security checks every time.

What Oracle Deep Data Security Changes

Oracle Deep Data Security, built into Oracle AI Database 26ai, moves authorization into the database itself.

Instead of trusting every app, agent, or retrieval pipeline to filter data correctly, the database evaluates identity and runtime context at query time and enforces least-privilege access where the data actually lives.

That is a big architectural shift. It means security is no longer just an application concern. It becomes a database responsibility, enforced consistently across all query paths.

Why That Matters to the Business

From a business perspective, Oracle Deep Data Security helps organizations:

• reduce data exposure risk across all access paths
• enforce least-privilege access for both users and AI agents
• adapt faster by separating policy from application code
• strengthen governance with centralized, End User aware auditing
• maintain enterprise performance while applying fine-grained controls

This is not just about better security. It is also about making AI-enabled systems easier to govern, easier to explain, and safer to scale.

Key Concepts, Explained Simply

Oracle Deep Data Security is designed for environments where many applications and identities execute SQL against shared data. A few core concepts matter:

• End users – Human users working through applications, analytics tools, or AI assistants.
• End-user security context – The runtime identity and context Oracle uses to evaluate authorization.
• Application identities – Trusted applications and services, including AI agents, that connect to the database.
• Identity provider (IdP) – The system where users, roles, and attributes are managed.
• Secure identity propagation – The mechanism that makes identity and attributes available to the database at runtime.
• Authorization policies – Declarative rules that define what operations are allowed based on identity and context.

Why This Matters for Agentic Pipelines

This becomes especially important for customers building agentic or AI-assisted pipelines on top of Oracle databases.

In those systems, the real question is not only whether a user or service is authenticated. The bigger question is whether the generated SQL, retrieval step, or downstream data access is authorized to see the requested rows, columns, and values.

Oracle Deep Data Security makes that a database decision instead of an application assumption.

For businesses, that means:

• safer deployment of AI agents that generate SQL dynamically
• stronger protection against prompt injection and unauthorized data access
• more confidence that apps, analytics, RAG flows, and AI agents all see only authorized data
• clearer governance and auditability for both user-driven and machine-driven access

The Demo Story

I built a quick demo (with React, Tailwind CSS, IdP (Auth0, OCI IAM), and Python / Flask) to show how authenticated End User Identity affects Oracle data access and why database-native authorization is such a strong design for AI-enabled systems.

The story is intentionally simple:

1. A user logs in with Auth0.
2. The application obtains an OAuth2 token for that identity.
3. The backend validates the token and forwards user context to Oracle.
4. Oracle Autonomous 26ai Database returns sales data through the same application and database path.
5. Once Deep Data Security is enabled in ADB, the same query intent returns different results based on propagated identity and database policy.

That makes the demo easy to understand in a live walkthrough, because the core point is very clear:

• the database, not the frontend, is the enforcement point
• the same application flow can safely serve different users
• the same AI or SQL workflow can return different authorized results without copying security logic into every application path

Oracle Deep Data Security Demo

A company has a project to provide a new application to view sales data across teams. They have sales staff assigned to different regions, and so they would like to control the visibility of the data with a secure Data Policy.

The application User (Regional Manager – West) signs in through the Auth0 identity provider (IdP) and receives a valid OAuth 2.0 token. That token is then used by the application to obtain the database access token required for secure API calls and protected database access.

The desired Data Access Policy for the sales team is straightforward: the Sales SVP, Regional Manager West, and Pacific Sales Rep should each see only the data for the regions they are securely authorized to access.

The application backend captures the identity context from the IdP login and propagates that user identity to the database layer:

The application uses the python-oracledb 4.x driver to create the end-user security context and attach that security context to the active database session.

In the application backend, Python calls
create_end_user_security_context(…) and then set_end_user_security_context(…) to establish the Oracle Deep Data Security runtime identity for the session.

Oracle then exposes that attached runtime identity through ORA_END_USER_CONTEXT, which represents real Oracle session state for the current end user.

Once the end-user security context has been established, Deep Data Security policies can be enforced in the database, allowing Data Grants and related security controls to apply the intended data policy automatically.

Baseline SQL Test
To demonstrate the difference, we first run a standard SQL query against the dataset. At this stage, the query is unprotected, meaning no Deep Data Security policy has been applied yet.

Based on our business data security policy, this Regional Manager should only be able to see sales data for two regions: Pacific and Mountain. That creates a clear security gap in the current unprotected query path, because the end
user can still see data from the other two regions as well.

As shown below, private sales data from all four sales regions is visible.

SQL query results:

Enforcing a Deep Data Security Policy

To demonstrate Deep Data Security, we created a second table that contains the same sales data but is protected by a Deep Data Security policy.

Protected Table: SALES_DATA_DDS

Data Roles have been added for the team to support the policy model shown in the application:

Data Role: REGIONAL_MANAGER_ROLE

Application: Show Data Roles

DDL: Create Data Roles

Also, Data Grants have been added to support the policy model:

Data Grant: REGIONAL_MANAGER_SALES_DATA_ACCESS

Application: Show Data Grants

DDL – Create Data Grant
(using ORA_END_USER_CONTEXT.username)

Grant the DATA ROLE to this End User:

Run a Deep Data Security Protected SQL Query

After switching to the Protected tab, we can see that the appropriate Data Role has been assigned. At this point, the secure data policy is enforced by Oracle Deep Data Security through the following controls:

Data Role: REGIONAL_MANAGER_ROLE
Data Grant: REGIONAL_MANAGER_SALES_DATA_ACCESS
Deep Data Security protected table: SALES_DATA_DDS

Protected SQL Query Results: Only the “authorized data” has been returned for the allowed regions (Pacific, Mountain), as we are now controlling the data access with our DeepSec Data Grant policy and role.

Validated SQL Results

Notice that the SQL query itself does not require any additional WHERE clause predicates to protect the data. The protection is applied automatically by the Data Grant. In this DeepSec model, the policy is enforced directly at the table level inside the database, not through special views or application-side ACL logic.

The result is that different End Users automatically see different authorized slices of the same sales dataset based on their assigned Data Role. Because Deep Data Security is enforced natively in the database, those protections apply consistently across applications, tools, AI-driven query paths, and backend services.

In other words, you are no longer relying on each application path, or each development team, to remember to filter data correctly and apply the right policy logic every single time.

Architectural Summary

The overall flow is shown below:

1. The user signs in through the identity provider (IdP).
2. The trusted user identity and claims are passed to the application backend.
3. The backend establishes the end-user security context inside the database session.
4. A standard SQL or natural language (NL2SQL) query prompt is selected
5. The SQL query then runs with that real, context-aware runtime identity attached to the DB session.
6. Oracle Deep Data Security uses that runtime identity to enforce the appropriate data policy automatically at query time.
   

This app demonstrates how authenticated user identity flows from the application into Oracle Autonomous AI Database, where End User SQL execution and Deep Data Security combine to return only authorized data.

Final Thought

As AI systems become more autonomous, strong authorization becomes even more important. The more decisions that are made dynamically at runtime, the greater the risk that AI-generated behavior can drift beyond intended policy boundaries.

Oracle Deep Data Security addresses that challenge at the right layer: the database itself. By enforcing authorization where the data lives, it gives organizations a cleaner, stronger, and more scalable foundation for applications, analytics, RAG pipelines, and agentic AI systems.

In this rapidly changing world of agentic AI, Oracle AI Database 26ai and its new Deep Data Security feature deliver both meaningful business value and stronger data protection where it matters most.