Enterprise data is no longer accessed through a predictable set of applications. Analytics platforms, REST APIs, cloud services, and AI agents are creating new ways to access and act on sensitive information, often through highly privileged database connections. Yet authorization enforcement remains scattered across a growing number of applications. This makes it difficult to maintain consistent security policies and increases the risk of excessive privileges and unauthorized data exposure. AI agents further amplify these risks because they can generate SQL dynamically and cannot be relied on to enforce the end user’s authorization for enterprise data.

Oracle Deep Data Security, introduced with Oracle AI Database 26ai, provides a common authorization model for applications and AI agents and enforces end-user authorization directly in the database. It defines data authorization through declarative SQL policies called data grants and enforces those policies consistently in the database based on the end user’s authorization. Deep Data Security uses the established authorization context to control row, column, and cell-level operations, even when applications or AI agents access data on a user’s behalf.

Oracle AI Database Release Update 23.26.4 (DBRU 23.26.4) extends Deep Data Security’s authorization capabilities to address a broader range of enterprise application requirements. Data grant filters further restrict data access based on a user’s business scope. SQL macros enable authorization predicates to be defined once and reused across data grants, simplifying policy maintenance. Configured Oracle Application Express (APEX) and Oracle REST Data Services (ORDS) integrations can pass end-user identity and authorization context to enforce data authorization with Deep Data Security.

How Deep Data Security defines access

The basic building block of Deep Data Security is a data grant that defines which rows and columns a data role can access. Data roles are assigned to end users for responsibilities such as Employee, Manager, or Recruiter.

For example, one data grant may allow a manager to view their own complete employee record, while another data grant allows partial access to employee records of team members reporting to the manager. If multiple grants apply to an end user, Deep Data Security effectively takes the union of the access provided by those grants. In other words, the grants are additive.

Our previous update extended this model to supported remote data sources, related tables, and advanced SQL analytics. This release adds ways to restrict combined privileges, reuse complex authorization predicates, and carry trusted identity through additional application platforms.

Apply fine-grained restrictive authorization to analytics

Analytics applications often need restrictive filters in addition to data grants. These applications allow end users to access extensive and diverse datasets through dashboards and reporting tools. Access to specific facts in the fact table is restricted based on dimension attributes such as organizational hierarchy, region, business unit, department, or product. Higher-privileged users may access the full dataset, while lower-privileged users have restricted access based on their business scope.

DBRU 23.26.4 introduces fine-grained restrictive authorization through data grant filters. Data grants provide end users with access to data, while data grant filters further restrict that access. Data grant filters apply additional SQL predicates to restrict the combined access provided by all applicable data grants. Policy authors can introduce a data grant filter to further restrict the access users already have through data grants.

Consider a Human Capital Management (HCM) Talent Acquisition scenario. An employee with the Recruiter role can view all job requisitions. Area of Responsibility (AOR) roles further restrict the employee’s access by business unit, country, and department. A recruiter with AOR-specific roles should see only requisitions that meet those restrictions.

Deep Data Security can represent this access with a data grant for the Recruiter role and data grant filters for the AOR-specific roles. The database evaluates both data grants and data grant filters before returning results.

The data authorization can therefore govern the recruiter’s application, an analytics dashboard, or an AI assistant that retrieves requisition data on the recruiter’s behalf.

Data grants establish access, while data grant filters restrict access with additional SQL predicates
Figure 1: Data grants establish access, while data grant filters restrict access with additional SQL predicates

Extend Deep Data Security authorization to APEX and ORDS

Oracle APEX enables developers and AI agents to rapidly build data-driven enterprise applications, while ORDS exposes database data and services through REST APIs. APEX 26.1 further enables AI agents to generate applications and integrate AI capabilities with enterprise data. As applications increasingly incorporate AI agents and expose data through multiple access paths, maintaining consistent end-user authorization becomes more important. Customers need the same database authorization policies to apply when users access data through low-code applications, REST services, or AI agents.

With DBRU 23.26.4, APEX 26.2 and ORDS 26.3.0 can be configured to propagate end-user identity and authorization context to Oracle AI Database using OAuth 2.0 tokens that the database can cryptographically verify. The context can include the end user, the application identity, data roles, and other attributes used by the authorization policy. Deep Data Security can then use the trusted context to enforce consistent authorization in the database across both low-code and REST access paths.

APEX applications using Social Sign-In with an identity provider (IdP) such as OCI IAM or Microsoft Entra ID can propagate the user’s identity, application roles, and relevant context attributes to the database through user and application tokens that support cryptographic verification of the identity context. Deep Data Security uses these tokens to evaluate the applicable data grants for each SQL operation. Each application can use its own application identity and data roles to isolate data access.

ORDS extends data authorization with Deep Data Security authorization to REST services. Developers can preserve the application’s existing service structure while the database enforces authorization for rows, columns, and operations. The application identity can also distinguish one REST service or application from another. ORDS can additionally expose a governed Model Context Protocol (MCP) endpoint for compatible clients and agent frameworks, with Deep Data Security enforcing the signed-in user’s authorization at the database.

ORDS propagates user and application context so the database can enforce data authorization
Figure 2: ORDS propagates user and application context so the database can enforce data authorization

Across these access paths, Deep Data Security uses a common token model for requests made on behalf of users and for workloads without a human end user. On-behalf-of tokens carry user and application context, while database access tokens establish the application identity for services, scheduled jobs, and autonomous agents.

Connect existing OAuth 2.0 identity providers

Enterprise applications already rely on identity providers to authenticate users and obtain access tokens. Deep Data Security allows customers to use those existing identity providers while giving the database the context it needs to enforce data authorization. OAuth 2.0 provides a common framework, but identity providers may use different claims in their tokens to represent end-user, application, or agent identities, roles, and other attributes differently.

Deep Data Security addresses these differences by mapping identity-provider-specific token claims to a consistent set of database attributes. Administrators configure the token issuer, the location of the public key used for verification, the audience or intended recipient, and the claims that identify the end user, application, agent, and data roles. Applications can continue to use the existing identity provider for identity and role management, while the database interprets the resulting context consistently.

DBRU 23.26.4 adds Keycloak as a validated identity provider alongside OCI IAM and Microsoft Entra ID. The same claim-mapping model can support additional OAuth 2.0-compatible identity providers as they are validated.

Deep Data Security maps token claims to end-user identity, application identity, and data roles
Figure 3: Deep Data Security maps token claims to end-user identity, application identity, and data roles

Simplify complex data grant predicates with reusable SQL macros

Enterprise applications often apply the same complex authorization predicate across multiple data grants and data grant filters. In the earlier HCM example, the predicate that determines a recruiter’s requisitions may be used by an application query, an analytics view, and a REST service. Repeating that predicate across SQL statements makes policy changes harder to manage and increases the risk of inconsistent enforcement.

Reusable SQL macros let policy authors define a complex authorization predicate once and reuse it in multiple data grants and data grant filters. When the policy changes, policy authors can update the macro centrally, so every data grant that references it uses the revised predicate. This reduces duplication of predicates and helps keep authorization behavior consistent as applications grow.

Reusable SQL macros simplify and centralize authorization predicates
Figure 4: Reusable SQL macros simplify and centralize authorization predicates

Improve visibility with Unified Audit

With end-user, agent, and application context available in the database, Unified Audit can record the application identity, data roles, and end-user context for audited SQL operations, based on the applicable audit configuration. This gives customers visibility into what operation was performed, by which user and application, and under which security context. This additional context can support operational troubleshooting, compliance reviews, and security investigations.

Key takeaways: Extend consistent data authorization across analytics, applications, and AI

DBRU 23.26.4 makes it easier to enforce consistent, fine-grained data access across analytics applications, application platforms such as APEX and ORDS, and AI agents. Developers can build different applications while using the same end-user based authorization for the underlying data.

  • Enforce analytics application authorization at the database
    Use data grants and restrictive data grant filters to support broad data access with business-scope restrictions, and reusable SQL macros to simplify policy management.
  • Extend consistent authorization across application and AI workflows
    Apply Deep Data Security across APEX, ORDS, and AI agents, so the same authorization policies can be enforced consistently across supported application and AI access paths.
  • Use validated OAuth 2.0 identity providers
    Integrate OAuth 2.0-compatible identity providers and capture richer user, application, and security context for end-user authorization directly in the database.

Get started with Oracle Deep Data Security

The following resources can help you get started with Oracle Deep Data Security:

FastLabs

LiveLabs