Attacks are accelerating with AI—partly because it speeds up the reverse-engineering of patches.
Oracle uses this as a cornerstone for its blueprint Deep Trust AI Architecture. The components it brings together are guided by a single principle: embedding security and governance into the database infrastructure.
Patch automation on Autonomous AI Database is part of it. A hallmark of the managed service model, it is presented here as an asset in shortening the window attackers have to exploit vulnerabilities.
Integrating Access Control into the Database
The flagship piece of the blueprint is called Deep Data Security. Introduced last March, it consists of embedding access control directly into the database, reinforced by declarative SQL policies.
Oracle thus presents itself as an alternative to implementing security at the application layer. An approach that, it suggests, shows its limits with AI agents. Rationale: their autonomy increases the risk of bypass (direct SQL queries after schema inspection) and, more broadly, of unauthorized access (queries crafted from inputs and the reasoning of the underlying models, without predefined logic).
Oracle also flags two other limits in relation to RAG and the vibe coding. It sees a governance challenge for the former via application logic: validating vector searches often relies on a secondary model that can be a source of errors, and the option to filter results impacts performance. As for vibe coding, it views it as a potential vector for propagating authentication/authorization logics that may carry flaws.
Deep Data Security is also intended to offer an alternative to traditional controls at the database level. Among other arguments:
- Complexity of row-level security, especially when based on UDFs or stored procedures
- Lack of granularity at the column level
- The footprint of dynamic masking, which is also vulnerable to inference attacks (manipulating query filters to deduce values)
Oracle also positions itself as an alternative to external authorization systems. On one hand, by presenting them as a bypassable dependency that adds latency. On the other hand, noting that these services can lack precision unless they are optimized for schemas and SQL semantics.
Deep Data Security Does Not Replace RAS and VPD
Policies can apply down to the cell level. For every SQL query, a security context is attached, in the form of an in-memory JSON object combining the user’s identity, roles, and attributes.
Data access is organized around two main models. On one hand, via the user’s own identity (direct authentication or authorization delegated to the application). On the other, via the application’s identity (the database trusts the application to convey identity attributes or verify the user’s legitimacy).
Ultimately, user management could be handled within the database. But Oracle recommends an IAM. Two are currently compatible: Oracle’s own and Entra ID. OAuth2 tokens are transmitted via client drivers, without needing to manage it at the application level.
Oracle promises a “negligible” impact on performance, as long as you define its SQL predicates clearly (visible to the optimizer). Standard best practices apply here, for example leveraging indexes and, if possible, partitioning.
At the announcement of Deep Data Security, we were promised planned integrations with APEX and Data Safe to provide other options for writing authorization policies. They remain on the roadmap.
The VPD (Virtual Private Database) and RAS (Real Application Security) components remain in the catalog. Deep Data Security is not a substitute, but a complement, Oracle assures. It has the advantage of removing client-side APIs (the server manages the lifecycle of the security context) and requires no changes to the data access layer (callbacks integrated into the SQL driver automatically extract the security context from the application’s framework).
Oracle Integrates APEXlang into Its Blueprint
Within the blueprint, Deep Data Security is paired on the data layer with SQL assertions, usable to lock down the execution of business rules.
Deep Trust AI Architecture also includes APIs to restrict agent access to defined business objects. Oracle pairs this with a variant of its enhanced text-to-SQL, built on a knowledge graph, with an integrated regression test and a feedback loop.
The top tier of the blueprint is called the APEX AI Application Generator. Introduced this summer, it adds an abstraction layer—namely APEXlang, a compiled language for defining applications that runs within APEX. No generated code, which Oracle notes reduces the attack surface.
