Oracle publishes AI trust blueprint to enforce rules beyond individual apps
Deep Trust AI Architecture combines database-enforced permissions, controlled data access and shared application safeguards. Companies still have to define policies and validate results.
Listen to this story
The audio brief
Story brief
3 key pointsOracle announced Deep Trust AI Architecture on October 26, a four-layer blueprint for enforcing enterprise AI controls in the database and platform rather than relying on each application or agent to implement them. It combines identity-based data permissions, database-level business-rule checks, constrained business-object APIs, validation of natural-language-to-SQL answers, app generation through APEX, and automated infrastructure maintenance. Oracle presents an architectural approach, not a new product release, with no availability date; customers still must define policies, verify outputs, and govern deployment.
- 01
Deep Data Security uses a cryptographically signed corporate-directory token to check identity and apply data permissions regardless of which app or agent makes the request.
- 02
SQL Assertions can reject business-rule violations, while Trusted Data APIs limit agents to controlled business objects instead of unrestricted SQL access to tables.
- 03
Deep NL2SQL combines business terminology and rules with database metadata; Knowledge Change Verification retests previously validated answers after corrections.
An AI agent that goes straight to a database can bypass privacy rules written into an application. Oracle’s response, announced October 26, is Deep Trust AI Architecture: a blueprint that puts controls beneath individual apps and agents. Its premise is that enterprise safeguards should not depend on AI implementing every rule correctly.
The announcement groups Oracle capabilities across four layers: software platform, data, data access and application development. Oracle describes an architectural approach, rather than a specific product release, and gives no new availability date. It says the blueprint applies wherever customers run Oracle, including leading cloud providers and on-premises systems.
Oracle identifies two ways application-level protection can fail: generated code may implement policies incorrectly, and agents may access data without passing through that code at all. An application’s privacy checks offer no protection on a route that bypasses the application. The proposed response is to enforce critical permissions and business rules inside the database.
- For privacy, Deep Data Security defines user-access rules in Oracle AI Database. Oracle says the database checks identity using a cryptographically signed token from the corporate directory, then applies permissions regardless of which app or agent requests the data.
- For business rules, SQL Assertions let the database reject changes that violate defined conditions. Oracle’s example is an expense exceeding an employee’s authorized spending limit: the database rejects the charge rather than relying on the requesting application to stop it.
The data-access layer narrows what an agent can ask the system to do. Oracle Trusted Data APIs expose controlled reading and writing of business objects, such as a complete purchase order, instead of unrestricted SQL access to underlying tables. SQL is the language used to query and change database data. Oracle says the database enforces update rules and data integrity for those objects.
Enterprises are still accountable to define policies, validate results and govern deployment.
Dave Vellante, co-founder and chief analyst, theCUBE Research, quoted by Oracle
Permission to read data does not settle whether an AI answer is right. Oracle acknowledges that natural-language questions can be ambiguous. Its Deep NL2SQL approach organizes business knowledge into topics and combines it with database metadata to interpret questions and generate queries. That context includes terminology, business rules and descriptions of what tables and columns mean.
Oracle also describes a correction process with a human knowledge expert. Users flag an incorrect answer and suggest a correction; the expert, helped by an AI agent, investigates and updates the relevant knowledge. Before publishing that change, Knowledge Change Verification rechecks previously validated “gold” answers. The check addresses a specific risk: fixing one answer can make another worse.
For application development, Oracle draws a boundary between describing functionality and implementing infrastructure. It says APEX AI App Generator translates a plain-language application description into APEXlang, a declarative language specifying what the application should do. The APEX engine executes that definition and supplies the underlying security, scaling and availability capabilities, rather than having AI recreate them in custom code.
The platform layer addresses maintenance beneath those applications. Oracle points to Autonomous AI Database’s automatic security updates across the database engine, operating system, Exadata storage and firmware. It describes rolling patching—updating infrastructure one part at a time while application workloads continue running—and always-on encryption for stored data and data moving between systems.
In Oracle’s accompanying analyst assessments, Vellante says coordinating these controls could reduce the integration work customers face when assembling separate components. His qualification leaves a concrete task with adopters: they must decide the policies, validate the answers and govern deployment. The architecture supplies a proposed enforcement foundation, not a replacement for those decisions.
Sources
- blogs.oracle.comAnnouncing: Oracle Deep Trust AI architecture
- blogs.oracle.comAnalyst perspectives on Oracle AI Database Deep Trust AI Architecture
Reader comments
Newest comments first. Replies stay oldest first.