Updated 12 hours ago
Oracle outlines four layers of controls in its Deep Trust AI architecture

Oracle outlines four layers of controls in its Deep Trust AI architecture

Oracle’s October 26 blueprint puts platform maintenance, database rules, object APIs and APEX application execution in one architecture. The announcement leaves component availability and independent security outcomes unestablished.

A blueprint for where controls should run

Oracle [announced Deep Trust AI Architecture on October 26](https://www.oracle.com/fr/news/announcement/ai‑world‑oracle‑announces‑deep‑trust‑ai‑architecture‑to‑help‑enterprises‑innovate‑with‑confidence‑2026‑10‑26/) as a blueprint combining Oracle AI Database, Autonomous AI Database and APEX AI Application Generator. Its central design choice is to place controls in the software platform, data, data‑access and application‑development layers, rather than leave their complete implementation to each agent or AI‑generated application. That makes this an architecture announcement spanning several named capabilities. It is not evidence that every component is newly generally available, or that a particular customer has deployed the full design. Oracle’s release does not provide a complete availability, version, prerequisite or pricing matrix.

Platform maintenance and rules at the database

At the [software‑platform layer](https://www.oracle.com/fr/news/announcement/ai‑world‑oracle‑announces‑deep‑trust‑ai‑architecture‑to‑help‑enterprises‑innovate‑with‑confidence‑2026‑10‑26/), Oracle points to Autonomous AI Database’s automated security updates across the database engine, operating system, storage and firmware, alongside encryption for stored and transmitted data. Those are capabilities Oracle includes in the blueprint, not results of a new independent security assessment. For the data layer, Oracle says Deep Data Security lets an organization define end‑user access rules in Oracle AI Database and enforce them on SQL requests. In the described flow, the database checks a cryptographically signed identity token from the corporate directory and determines access. Oracle SQL Assertions supply a separate business‑rule mechanism; the release gives an employee spending limit as its example. Identity‑based access and a rule about an allowed transaction answer different questions.

Object APIs narrow the interface an agent uses

[Deep Trust Data APIs](https://www.oracle.com/fr/news/announcement/ai‑world‑oracle‑announces‑deep‑trust‑ai‑architecture‑to‑help‑enterprises‑innovate‑with‑confidence‑2026‑10‑26/) are described as providing controlled reads and writes to logical business objects, such as purchase orders. Oracle contrasts this with arbitrary SQL access: the application or agent works with objects needed for its task, while the database governs what it can view or change. The same data‑access layer includes Deep NL2SQL. Oracle says it combines business terminology, practices and metrics with information about how data is defined and organized. Continuous Feedback Learning lets users correct responses, and Knowledge Change Verification is intended to validate corrections before they enter the corporate knowledge base. The release describes that correction path; it does not establish how often validation succeeds or how accurately the system answers a particular organization’s questions.

APEX separates an application definition from its execution

For [application development](https://www.oracle.com/fr/news/announcement/ai‑world‑oracle‑announces‑deep‑trust‑ai‑architecture‑to‑help‑enterprises‑innovate‑with‑confidence‑2026‑10‑26/), Oracle describes AI coding agents translating natural‑language requirements into APEXlang, which it calls an open, declarative application‑definition language. APEX then executes those definitions in its centralized runtime. The proposed division is between an AI‑produced definition and the engine that runs the application, rather than treating all generated output as execution code to maintain separately. The four layers therefore address different implementation decisions: platform maintenance, database identity and business rules, bounded data interfaces, and application execution. Their inclusion in one blueprint is a useful map of Oracle’s approach. It does not certify a secure configuration, prove resistance to attacks or establish compliance for an actual deployment. *Oracle headquarters signage photographed on January 18, 2005. Archive company context, not an image of the Deep Trust architecture or its deployment. Photo: [Peter Kaminski](https://www.flickr.com/people/peterkaminski/), [Flickr](https://www.flickr.com/photos/35034359460@N01/3772015/) / [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Oracle_headquarters.jpg), [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/deed.en). Resized and cropped for display.*

Share this article

PostShare

Related News