Oracle wants agent security enforced by the database, not trusted to the agent. Deep Trust moves rules down

An agent that can write SQL can write any SQL. That is the architecture problem behind Oracle’s Deep Trust AI Architecture, announced on October 26, and it is a sharper version of a problem enterprise applications have always had.

For decades, most business rules lived in application code. The order screen checked the credit limit; the HR application filtered salaries by manager. The database trusted the application, because only the application talked to it. AI breaks that arrangement twice: agents generate their own queries and tool calls, and AI coding tools generate new applications faster than anyone reviews them. A rule that lives only in the old application is not applied to either.

Oracle’s answer is to move the rules down to the layer that every request has to cross.

Where a rule lives, before and after

The same rule in two architectures

	Application-enforced	Database-enforced (Deep Trust)
Who sees which rows	Filtered by each app, if it remembers	Deep Data Security checks the end user on every SQL request, via a signed token from the corporate directory
Business invariants	Validation code in each app	SQL Assertions reject any change that breaks the rule, whoever submits it
What an agent may call	Raw tables or a custom API	Data APIs over logical business objects instead of arbitrary SQL
Questions in plain language	Generic text-to-SQL	Deep NL2SQL with business metadata and change verification
AI-generated apps	Generated executable code	Generated APEXlang definitions, run by Oracle's runtime

The fifth row is the least discussed and probably the most interesting. Oracle’s APEX AI Application Generator turns a description into APEXlang, an open declarative language that Oracle’s runtime executes. The AI writes a definition, not program code, so security and behavior come from the runtime rather than from whatever the model produced. It is the same move as the others: keep the model away from the part that enforces.

Why this is the right direction

We have argued that prompt guardrails are not a security boundary; the boundary has to be somewhere the agent cannot talk its way past. For data access, the database is the obvious candidate, because every path ends there. Enforcing who-sees-what with the end user’s identity, verified on each request, also fixes a common agent flaw: the agent running with a service account that sees everything. It pairs naturally with per-agent credentials such as IBM’s new Agent Identity and Vault 2.2, which decide which agent is connecting; the database then decides what the person behind it may see.

What it is not

Deep Trust is a blueprint, which Oracle compares to its Maximum Availability Architecture: a recommended combination of capabilities across four layers, from automatic patching in Autonomous AI Database to the application runtime. It is not one product with one availability date, and the release does not state the status of each component. Before you plan around it, ask Oracle for each piece you need, which database version and deployment it requires (Autonomous on OCI, other clouds, Cloud@Customer, on premises), and whether it is generally available.

Two other limits are worth stating. Database-level rules protect data inside that database; an agent that also calls SaaS APIs, files and email still needs controls there. And “cannot be bypassed” is a design goal, not a guarantee; misconfigured policies and over-broad roles remain possible. Test them as you would any access control, with requests that should fail.

The practical step, even for teams that do not run Oracle, is to list the rules your agents depend on and write next to each one where it is enforced. Every rule whose answer is “in the prompt” or “in an app the agent does not use” is a rule the agent can break.