Oracle AI Database 26ai's Deep Data Security enforces row, column and cell access

What Deep Data Security does

Oracle AI Database 26ai ships with a new authorization framework called Deep Data Security, or "Deep Sec", according to a hands-on walkthrough published on dev.to. Instead of trusting that application code, middleware or an AI agent applies access rules correctly, administrators declare in SQL exactly which rows, columns and even individual cells a given user, role or application may touch. The database then enforces that rule on every query, no matter who or what sent it.

The walkthrough frames Deep Sec as a companion to familiar tools such as Oracle Label Security and Data Masking, but with a cleaner, SQL-native way to express fine-grained access that scales better than row-level security written in PL/SQL. It rests on three building blocks:

• Local end users — lightweight identities for application users that own no schemas or objects, unlike traditional database users.
• Data roles — roles purpose-built to carry fine-grained privileges, either mapped to roles in an external identity provider such as Microsoft Entra ID or OCI IAM, or managed entirely inside the database.
• Data grants — the policy objects themselves, specifying who can SELECT, INSERT, UPDATE or DELETE which rows and which columns, written in ordinary readable SQL rather than hidden procedural logic.

The consequence the author highlights: the same protection applies whether a request comes from a human user, a reporting tool or an autonomous AI agent.

End users start with zero privileges

A local end user is created with a new CREATE END USER statement that mirrors the familiar CREATE USER syntax, and a dedicated dictionary view, DBA_END_USERS, lets administrators monitor these accounts the way DBA_USERS does for standard users.

The first behaviour that trips people up, the post notes, is that creating an end user does not give it the ability to connect. A login attempt as a freshly created end user fails with ORA-01045 because the account holds no CREATE SESSION privilege. That is by design: an end user starts with no privileges at all and must be authorized through a data role before it can do anything, including logging on.

Data roles carry the authorization

The grant chain works like this: a standard database role holding an ordinary privilege such as CREATE SESSION is granted to a data role, and the data role is then assigned to one or more end users with GRANT DATA ROLE. This keeps authorization declarative and centralized instead of scattering direct grants across individual users. Data roles are also the vehicle for the fine-grained data grants that define row- and column-level access.

Under the covers: sessions run as XS$NULL

Because end users own no schema, their sessions actually run as the reserved, schema-less account XS$NULL, with the end-user security context layered on top. Querying USER_USERS from an end-user session returns XS$NULL, while USER_END_USERS returns the end user's own name, and the enabled data role is visible in V$END_USER_DATA_ROLE. It is that layered context, not the underlying session account, that determines data access.

Data roles can still over-grant

The walkthrough includes a deliberate warning: data roles can also be given broad traditional privileges — including DBA — and those privileges flow down to every end user holding the role. The author demonstrates granting DBA to a data role, after which the end user inherits the ability to run any DML against any table in the database. The point is worth demonstrating precisely because it is dangerous: the fine-grained guarantees of Deep Sec depend on administrators not re-importing coarse privileges through the back door.

Why it matters

Fine-grained access control enforced inside the database matters most when the client cannot be trusted to enforce it, and autonomous AI agents are the clearest recent example. Agents that query databases on a user's behalf are only as safe as the credentials they hold; if an agent connects with a broad account, a prompt injection or a hallucinated query plan can reach everything that account can. Deep Sec inverts that model by moving the authorization boundary to the data itself, so a row, column or cell a user should never see stays hidden regardless of which tool, agent or ad-hoc client issued the query.

Separating identity from schema ownership also gives application teams a cleaner pattern than sharing one database account across thousands of application users, and the external identity provider mapping means those identities can live in Entra ID or OCI IAM. The DBA-grant demonstration, though, is the honest caveat: the framework enforces exactly what it is told, and a lazy role grant still leaks everything. All details here come from a single practitioner walkthrough rather than Oracle's official documentation, so specifics may shift as the feature matures.