Oracle has extended Deep Data Security, its in-database authorization feature for Oracle AI Database 26ai, to Oracle APEX and Oracle REST Data Services. The update arrives with Release Update 23.26.4 and was announced on the Oracle Database blog on October 26, 2026.
With it, an APEX 26.2 application or an ORDS 26.3.0 REST service can pass the signed-in user's identity to the database. The database then decides which rows, columns and values that user may read or change, whatever path the SQL took to get there.
What Oracle Deep Data Security Does
Deep Data Security first became available in Oracle AI Database 26ai on May 1, 2026. It moves the "who may see what" rules out of the application and into the database, so the same rules apply to an app, a report or an AI agent.
The rules are written as SQL policies. A data role describes a job, such as Manager or Recruiter, and a data grant states which rows and columns that role may use. When a user holds several roles, the grants add up, so the user gets the combined access of all of them.
Oracle's main argument is about AI agents. An agent writes its own SQL, often over a powerful shared connection, so the application cannot be sure the query stays inside the user's rights. When the database checks every statement against the end user, a cleverly worded prompt cannot return more data than the user is allowed to see.
What Is New in Release Update 23.26.4
Release Update 23.26.4 (DBRU 23.26.4) adds five changes to Deep Data Security:
- Data grant filters: extra SQL conditions that narrow the access a user already has from all of their grants.
- Reusable SQL macros: a complex authorization condition is written once and used in many grants and filters.
- APEX and ORDS integration: APEX 26.2 and ORDS 26.3.0 can send the end user's identity and roles to the database in OAuth 2.0 tokens that the database verifies.
- Keycloak support: Keycloak joins OCI IAM and Microsoft Entra ID as a validated identity provider.
- Richer auditing: Unified Audit can now log the app, the data roles and the person behind each audited SQL operation.
How It Works with Oracle APEX and ORDS
On the APEX side, the integration builds on Social Sign-In. When users sign in through an identity provider such as OCI IAM or Microsoft Entra ID, APEX can forward their identity, application roles and other attributes to the database as signed tokens.
Each APEX application can use a separate app identity and its own set of data roles, which keeps the data of different apps apart.
ORDS does the same for REST services. Existing modules and handlers can stay as they are while the database enforces row, column and operation rules for each caller.
ORDS can also publish a controlled Model Context Protocol (MCP) endpoint. AI agents and MCP clients then reach the data under the signed-in user's rights instead of a shared account.
Oracle describes two token types. On-behalf-of tokens carry a user and an application, while database access tokens identify an application on its own, for background work such as scheduled jobs or autonomous agents that run without a person signed in.
Data Grant Filters and SQL Macros in Practice
Grants open access and filters close it down. Imagine a sales application in which a Sales Rep grant lets a user see all orders. A filter tied to a regional role can then limit that same user to orders from their own region, and the database applies both before any row comes back.
This suits dashboards and reports, where senior staff need the whole data set and others need only their part of it. Because the filter lives in the database, the same limit applies in the APEX page, the REST API and an AI assistant built on the same tables.
SQL macros address a different problem: the same long condition copied into many policies. Written once as a macro, the condition can be changed in one place, and every grant and filter that uses it follows.
What It Means for APEX and ORDS Developers
Deep Data Security does not replace APEX authorization schemes. Oracle's APEX 26.2 announcement draws the line clearly: APEX authorization controls what a user can open or do in the app, while Deep Data Security controls what data the SQL can read or change.
Many APEX teams handle row-level rules today with Virtual Private Database policies or with WHERE clauses repeated across pages. Deep Data Security offers a declarative alternative that also covers REST services and AI agents with one set of rules.
To try it you need Oracle AI Database 26ai at DBRU 23.26.4, APEX 26.2 or ORDS 26.3.0, and an OAuth 2.0 identity provider for sign-in.
APEX 26.2 has been available for on-premises installations since October 6, 2026, and Oracle says the Autonomous AI Database rollout will follow. If you build AI Agents in APEX, this is the part to watch: SQL that agent tools run on a user's behalf is checked against that user's own grants.
For the techniques this builds on, see these guides on vinish.dev:
- Row-Level Security in Oracle APEX with VPD
- Oracle APEX Authorization and Application Security
- How to Secure ORDS APIs with OAuth2 Client Credentials
How to Get Started
The Oracle Deep Data Security guide in the 26ai documentation explains data roles, grants and the token setup. Oracle also offers free LiveLabs workshops, including Getting Started with Oracle Deep Data Security and hands-on labs for data grant filters and SQL macros.
Conclusion
With Release Update 23.26.4, Oracle Deep Data Security reaches the two tools most APEX developers use every day. APEX 26.2 and ORDS 26.3.0 can now hand the user's identity to Oracle AI Database 26ai, and the database applies one set of data rules to pages, REST calls and AI agents alike.
Data grant filters, reusable SQL macros and Keycloak support make those rules easier to fit to real business structures.
Sources
- Oracle Database Blog: Oracle Deep Data Security Expands Authorization Across Analytics, APEX, ORDS, and AI Agents (October 26, 2026)
- Oracle APEX Blog: Announcing Oracle APEX 26.2 General Availability (October 6, 2026)
- Oracle Database Blog: Oracle Deep Data Security Is Now Available in Oracle AI Database 26ai (May 1, 2026)
See my articles more often when you search Google.
