Oracle Database Vault in 26ai - A vault is not just a wall — and that finally matters in the age of agentic AI.
I have a small confession: I have never been fond of security metaphors borrowed from construction. We talk about firewalls, perimeters, gates, moats, and now, increasingly, vaults. The trouble is that most of these analogies stopped being accurate decades ago. A real-world vault is a heavy steel box that does exactly one thing — it keeps people out. An Oracle Database Vault, on the other hand, is a programmable policy engine baked into the kernel of an AI database, deciding in microseconds who is allowed to do what, from where, with which credential, on which row of which table. So while I am not entirely sold on the name, the thing behind it has quietly become one of the more interesting pieces of database security on the market — and with the Oracle AI Database 26ai release it has been pushed into a new role that the original 2006-era Database Vault (introduced in Oracle Database 10g Release 2) was never designed for: protecting data against AI agents that can write their own SQL.
1. Why a "vault" inside the database at all
The classic security stack assumes that the database is a passive repository — a box you put data into and read it back out of — and that everything dangerous happens on the network in front of it. Network firewalls, web application firewalls, and even Oracle's own Database Firewall all operate from the outside, inspecting traffic between clients and the database engine.1
That model has aged badly. In a modern enterprise the database is reached through dozens of paths: application servers, batch jobs, BI tools, ad-hoc developer sessions, RPA scripts, ETL pipelines, and now LLM-driven assistants generating SQL on the fly. The privileged user — the DBA, the SYS account, the shared application credential — is statistically the single largest source of data compromise, and that user is, by definition, already inside every perimeter you can build. Plugging holes in the network does not help when the threat actor is holding a password to SYSTEM.
This is the gap Oracle Database Vault was created to close. Rather than wrapping a wall around the database, it is built into the database kernel itself, sitting on the SQL execution path and enforcing policy as close to the data as it is physically possible to get.2 A DBA with the most powerful system privileges in the dictionary can still be denied a SELECT on the HR.EMPLOYEES table — not by being demoted, but because the kernel itself refuses the operation.
Database Vault doesn't protect data by hiding it behind something. It protects data by changing what the database is willing to do, even for the people who own it.
2. The four building blocks
Database Vault has, at its core, the same four primitives it has carried for years. What changes between releases is mostly the depth of integration and the breadth of the contexts they understand. The 26ai documentation describes them in essentially the following terms.3
2.1 Realms
A realm is a protection zone wrapped around a set of database objects — a schema, selected tables, particular roles, or a combination. It defines who is authorized to operate on those objects, regardless of object grants or system privileges elsewhere. There are two flavors:
- Traditional realm — respects existing object grants for SELECT/DML, but requires explicit realm authorization for DDL. Useful when applications must keep working but DBAs should not be quietly altering the schema.
- Mandatory realm — blocks both system and object privileges; even the schema owner cannot read its own tables without realm authorization. This is what you reach for when "the data must not be visible, full stop" is the requirement.3
2.2 Command rules
Where realms protect objects, command rules protect statements. A command rule says "this SQL command, against this object scope, is allowed only when this rule set evaluates to true." The vocabulary covers SELECT, DML, DDL, and administrative statements such as ALTER SYSTEM.4 Typical use cases:
- Forbid
DROP TABLEon the HR schema entirely. - Allow
TRUNCATEonly during a defined maintenance window. - Permit a destructive operation only when it originates from an approved IP, host, or program.
2.3 Factors
Factors are the contextual variables Database Vault understands at session time: client IP, hostname, OS user, program name, time of day, authentication method, and similar attributes. They are the nouns that command rules and rule sets reason about — and they are what makes "trusted path" enforcement possible.
2.4 Rule sets
A rule set is a Boolean combination of one or more rules — small SQL or PL/SQL expressions — that ultimately evaluates to true or false. Command rules and realm authorizations both consume rule sets; this is where conditional logic lives. A rule set can return a custom error message, can require all rules to be true, or can require any one of them.
3. What 26ai actually adds
Oracle AI Database 26ai is the long-term-support successor to 23ai, released in early 2026.5 Database Vault has been part of the database for many releases, so the headline in 26ai is not "Database Vault exists" — it's that the surface area Database Vault is asked to defend has grown, and Oracle has spent this release lining up new and adjacent features that plug directly into it.
3.1 Operations control, hardened
Operations control — the ability to prevent multitenant common users from accessing application data inside a pluggable database — remains a built-in Database Vault capability, and Oracle continues to position it as the standard answer for DBA fleet operations against PDBs that contain sensitive tenant data. A common DBA can patch, back up, tune, and reconfigure a PDB without ever being able to SELECT from its application schemas.
3.2 Simulation mode as a first-class deployment tool
The 26ai documentation continues to push simulation mode ( DBMS_MACUTL.G_SIMULATION) as the recommended on-ramp: deploy realms and command rules in non-blocking mode, observe what would have been denied, then promote to enforcement once the exception list is clean.3 This matters in practice because the single biggest reason Database Vault deployments stall is fear of blocking a job nobody documented.
3.3 Deep Data Security — the new neighbor
The most interesting 26ai-specific story is not strictly inside Database Vault, but next to it. Oracle introduced Deep Data Security in 26ai — a database-native authorization framework that enforces identity- and context-aware, fine-grained access control down to the row and column, designed explicitly with agentic AI in mind. Where Database Vault answers "is this user allowed to run this command on this object?", Deep Data Security answers "given the identity propagated from the application or AI agent, which rows and columns are this principal allowed to see right now?" The two are designed to compose: Database Vault sets the outer boundary, Deep Data Security shapes what is visible inside it.
3.4 Built-in companion: SQL Firewall
SQL Firewall ships as a kernel-integrated feature in Oracle AI Database 26ai Enterprise Edition — Oracle describes it as a kernel-integrated defense that blocks SQL injection, credential misuse, and unauthorized access with no agents, bypasses, or dependencies, and positions it alongside Database Vault as part of the same defense-in-depth bundle.2 The practical implication is that Database Vault sits next to a second kernel-resident defense rather than being the only one inside the engine.
4. Database Vault meets agentic AI
The reason any of this matters more in 2026 than it did in 2016 is that the threat model has changed. A modern Oracle AI Database is a multi-modal store — relational, JSON, graph, spatial, and vector data live in the same engine — and increasingly it is being talked to by software that writes its own SQL. Select AI in 23ai already let analysts pose questions in natural language and have an LLM translate them into queries; agentic frameworks in 26ai go further, chaining tool calls and reasoning steps on the user's behalf.
Two things follow from this:
- The query population is no longer human-shaped. An LLM can generate syntactically valid SQL that no developer in your organization has ever written, that no QA cycle has ever reviewed, and that no static allow-list will recognize. Some of those queries will be useful. Some will be prompt-injected. Most importantly, they will look identical at the wire level.
- The "user" identity is now layered. An AI agent connects with a service account, but it is acting on behalf of a human end-user whose entitlements should govern the result. Trusting only the connection-level principal collapses every end-user into one — exactly the design that makes stolen application credentials so damaging.
Database Vault's response is structural rather than behavioral. Instead of trying to recognize "bad" queries, it constrains what the database is willing to do for any given session: which schemas are reachable, which commands are permitted, from which IPs, with which programs, during which hours. Combined with Deep Data Security's row- and column-level identity propagation, the overall effect is that an AI agent can write whatever SQL it likes — it simply will not be allowed to read or change anything its real human principal could not have read or changed.6
Allow-listing what an LLM can say is a losing arms race. Allow-listing what the kernel will do for the LLM's session is not.
5. Vault vs. SQL Firewall vs. Audit Vault — who guards what
A persistent source of confusion among customers is the line between Database Vault, the in-kernel SQL Firewall, and the network-resident Audit Vault and Database Firewall (AVDF). They overlap in marketing language and sometimes in licensing, but they answer different questions. The table below summarizes the distinction as it stands in 26ai, drawn from Oracle's own positioning of the three.12
| Capability | Database Vault | SQL Firewall (kernel) | Audit Vault & Database Firewall (AVDF) |
|---|---|---|---|
| Where it runs | Inside the database kernel | Inside the database kernel | Out-of-band network appliance / agents |
| Primary question | "Is this operation allowed for this principal in this context?" | "Has this session ever been allowed to execute this SQL pattern?" | "Across the fleet — including non-Oracle DBs — what was executed and by whom?" |
| Mechanism | Realms, command rules, factors, rule sets | Per-user allow-lists of SQL signatures and session contexts | Network traffic capture, audit data consolidation, alerting |
| Bypassable by privileged user? | No — enforced before privilege check | No — enforced in the SQL execution path | Possible if attacker avoids the network path or disables audit |
| Covers non-Oracle DBs? | No | No | Yes |
| Typical role in defense-in-depth | Innermost ring, closest to the data | SQL-shape line of defense, especially against injection and credential misuse | Fleet-wide audit, compliance, and external monitoring |
The pragmatic reading: these are not competitors. Database Vault decides what the kernel is willing to do, SQL Firewall decides which exact SQL shapes a given session is permitted to run, and AVDF watches the whole estate from the outside and consolidates the evidence. In a mature deployment all three are on, and they inform each other — SQL Firewall's allow-list training, for example, is far cleaner once Database Vault has already eliminated the noise from privileged users wandering through schemas they have no business in.
6. Operating model: simulation, separation of duties, trusted paths
A pattern that holds across most successful Database Vault deployments — and the one Oracle's own getting-started material walks the reader through — has three moves.34
6.1 Start in simulation mode
Define the realms and command rules you believe you want, but enable them with DBMS_MACUTL.G_SIMULATION. Run the workload — month-end close, backup windows, the works — and let Database Vault log every access that would have been blocked. Resist the temptation to grant exceptions proactively; the violations log is the most honest inventory you will ever get of who is actually using your database, and for what.
6.2 Establish separation of duties
Database Vault ships with the DV_OWNER and DV_ACCTMGR roles for a reason: the people who configure the security policy should not be the same people who hold operational privileges on the data, and neither should be SYS. This is unglamorous, it is irritating to retrofit, and it is the single change that makes the rest of the controls credible. Auditors will ask, and "we have Database Vault installed" is not the same answer as "no individual account can both grant access and read the data."
6.3 Enforce trusted paths
Once the realms hold, layer command rules that bind sensitive operations to context: an application schema may only authenticate from a known IP range, a destructive DDL may only run during a maintenance window, a service account may only connect from the approved program name. This is what turns a stolen credential from a catastrophe into a logged failure. It is also where command rules earn their keep — they are simple to write, cheap to evaluate, and the audit record they leave behind is exactly the one a SOC analyst wants to see.4
7. Take-away
Is "vault" the right word for what Oracle ships in 26ai? Probably not, in the strict sense — vaults do not negotiate, and Database Vault is, in essence, a programmable negotiator. But the metaphor still does useful work. It communicates the right intuition: data security worth the name has to live next to the data, not on the road leading to it.
For Oracle AI Database 26ai specifically, the practical case for turning Database Vault on is stronger than it has been in any prior release. The kernel now has to defend against three kinds of caller it was never originally built for — multi-modal workloads, AI agents writing arbitrary SQL, and identities that propagate through application layers — and the controls that match those threats are realm-based, command-rule-based, and context-aware, not network-based. Database Vault is the seam those controls bolt onto, and with Deep Data Security and SQL Firewall lined up alongside it, that seam is finally wide enough to do the job.
The headline does not need to be that Oracle reinvented database security. It is that the pieces have, after almost two decades, converged on the right place to put it: inside the database, on the SQL execution path, where the data actually lives.
References
- Oracle, "Database Vault — Data Security." https://www.oracle.com/security/database-security/database-vault/
- Oracle, "Database Vault product page — features and SQL Firewall positioning." https://www.oracle.com/security/database-security/database-vault/
- Oracle AI Database 26ai Documentation, "Oracle Database Vault Realms." https://docs.oracle.com/en/database/oracle/oracle-database/26/dvgsg/oracle-database-vault-realms.html
- Oracle AI Database 26ai Documentation, "Command Rules." https://docs.oracle.com/en/database/oracle/oracle-database/26/dvgsg/command-rules.html
- Oracle, "Oracle AI Database 26ai New Features." https://docs.oracle.com/en/database/oracle/oracle-database/26/nfcoa/index.html
- Oracle Blogs, "Introducing Oracle Deep Data Security: Identity-Aware Data Access Control for Agentic AI in Oracle AI Database 26ai." https://blogs.oracle.com/database/introducing-oracle-deep-data-security-identity-aware-data-access-control-for-agentic-ai-in-oracle-ai-database-26ai
- Oracle, "Deep Data Security — feature overview." https://www.oracle.com/security/database-security/features/deep-data-security/
Comments