Securing LLM-Assisted Oracle Diagnostics: Licensing, Audit Trails and Change Guardrails
Content reflects the state as of December 2025. AI tooling and model capabilities in this area change frequently.
An LLM does not need DBA, raw SQL binds, or a production change credential to diagnose Oracle. Giving it those capabilities turns an evidence-correlation system into an unauditable privileged operator.
Technology and product capabilities in this series are evaluated as of June 30, 2026.
Situation
The first three Oracle articles collected waits, plans, blockers, redo, RAC, storage, and cloud evidence. Those artifacts reveal more than performance: literals and binds can expose customer values, while plans, modules, and audit records disclose system design.
Oracle puts diagnostic capabilities behind distinct privilege and licensing boundaries. A user may query a view while the organization lacks entitlement. Enabling a pack feature does not prove a purchased or included license.
The safe design therefore treats evidence acquisition, data disclosure, LLM reasoning, and production change as four separate authorization decisions.
The Problem
A read-only connection is not low risk by definition. Broad dictionary access discloses SQL, users, objects, sessions, and security configuration; expensive diagnostics compete with the workload; audit exports can leak governed values.
Telemetry is untrusted input: SQL comments, modules, errors, and logs can contain instructions the model must treat as data. Prompt controls cannot make an unrestricted database tool safe.
Audit without shared identity also fails. Oracle, the LLM gateway, and the change system may each record events without a common incident, evidence, recommendation, and executor chain.
How do we let an LLM reason over enough Oracle evidence to be useful while preventing it from expanding collection scope, bypassing licenses, exposing sensitive values, or authorizing its own remediation?
Build a Separated Oracle Diagnostic Control Plane
flowchart TD
A[human investigator and incident identity] --> B[policy broker and approved collection templates]
B --> C[read-only diagnostic collector]
C --> D[Oracle approved views and packages]
D --> E[restricted raw evidence vault]
E --> F[deterministic minimization and redaction]
F --> G[sanitized evidence pack]
G --> H[LLM observations hypotheses gaps and actions]
H --> I[recommendation record and policy evaluation]
I --> J[human DBA and service-owner approval]
J --> K[separate production executor]
K --> L[validation and rollback evidence]
C --> M[Oracle and collector audit records]
H --> N[model prompt and output records]
K --> O[change-system and database audit records]
No arrow from the LLM reaches Oracle production. The model receives a document, not a connection. The change executor receives an approved, typed action, not free-form model text.
Every artifact carries incident and request IDs, UTC interval, database and PDB, collector version, sources, entitlement, sensitivity, transformations, content and parent hashes, and retention class. This creates source-to-change lineage.
Symptoms
| Control smell | Risk | Required correction |
|---|---|---|
Collector uses DBA or SELECT ANY DICTIONARY | Excessive disclosure and blast radius | Explicit grants to approved sources |
| One account collects evidence and changes production | Recommendation becomes execution authority | Separate collector and executor identities |
| AWR data is available, so the pipeline uses it | Availability is mistaken for entitlement | Deployment-specific license registry |
Raw V$SQL_BIND_CAPTURE leaves the boundary | Bind values may contain sensitive data | Omit values or tokenize approved classes |
| Audit export is sent directly to the LLM | SQL_TEXT and SQL_BINDS can leak | Sanitize audit evidence separately |
| Client identifier is accepted as authenticated identity | Caller can set session metadata | Bind identity at trusted gateway and audit both |
| LLM output becomes a shell or SQL command | Untrusted text controls privileged execution | Typed allowlisted change workflow |
| Approval and execution share one record | Reviewer cannot prove what actually ran | Immutable recommendation and execution hashes |
First Five Checks
1. Inventory entitlement before evidence sources
Build a registry by offering, edition, contract, and environment. Classify each source as base, Diagnostics Pack, Tuning Pack, another option, cloud-included, or prohibited. Store its owner and decision date.
Oracle assigns AWR, ASH, ADDM, Performance Hub, V$ACTIVE_SESSION_HISTORY, and most DBA_HIST_* data to Diagnostics Pack. SQL Monitoring, profiles, and Tuning Advisor belong to Tuning Pack, which requires Diagnostics Pack. Direct underlying-data queries still count.
CONTROL_MANAGEMENT_PACK_ACCESS controls functionality, not commercial entitlement. Cloud inclusions vary, so never copy one environment’s decision to another.
2. Give the collector only the evidence it needs
Create a diagnostic identity per collection tier with only approved dynamic-view or curated-interface access. Exclude DBA, catalog roles, SELECT ANY DICTIONARY, ownership, mutations, ALTER SYSTEM, session termination, scheduler or SQL-management administration, and unrestricted packages.
Oracle warns that broad catalog privileges require extreme care. Explicit fixed-view access creates a reviewable boundary. Validate package requirements; DBMS_XPLAN.DISPLAY_CURSOR, for example, documents READ or SELECT on supporting fixed views.
Restrict network source, service, PDB, connections, templates, time range, rows, frequency, and timeout. A replica cannot reconstruct primary instance-local waits and blockers.
3. Minimize before the model boundary
Default-deny raw SQL, binds, objects, users, hosts, client identifiers, contexts, errors, and free-form logs. Prefer SQL ID, plan hash, typed bind class, stable token, selectivity bucket, normalized metric, and object alias. Keep an encrypted restricted original and produce a manifested sanitized artifact.
V$SQL exposes full text. V$SQL_BIND_CAPTURE can expose values sampled at most every 15 minutes per cursor—sensitive and not necessarily the incident execution. UNIFIED_AUDIT_TRAIL can contain SQL, binds, contexts, and identity. None crosses automatically.
Oracle Data Redaction is not this sanitizer. The Advanced Security feature has deployment-specific licensing, operates at query return, has privileged exemptions, and cannot cover SYS-owned objects. Dynamic evidence still needs collector-side minimization.
4. Join database, model, and change audit trails
Set module, action, and client identifier through the controlled collector, but do not treat mutable session values as authentication. DBMS_SESSION.SET_IDENTIFIER is executable by PUBLIC; the gateway’s authenticated principal and signed request remain authoritative.
Audit selected collector and executor actions. Separate AUDIT_ADMIN, which manages policies and trails, from read-only AUDIT_VIEWER. Export required records to retention the collector and executor cannot alter.
Record model version, prompt and evidence hashes, context, output, tool attempts, policy result, user, time, and cost. Record exact change parameters, reviewer, executor, preconditions, validation, rollback, and database audit IDs. Never log secrets.
5. Enforce capability tiers below the prompt
| Tier | Capability | Authority |
|---|---|---|
| 0 | Correlate a supplied sanitized pack | LLM may run without database access |
| 1 | Execute preapproved read-only collection templates | Policy broker under fixed limits |
| 2 | Request new sensitive or higher-load evidence | Human DBA approval before collection |
| 3 | Recommend configuration, SQL, plan, topology, or capacity changes | LLM proposes; owners verify |
| 4 | Execute a production change | Separate human-approved workflow only |
The LLM cannot grant itself a higher tier. A recommendation must be converted into a typed change with explicit target, expected outcome, risk, validation metric, and rollback condition. The executor rejects free-form SQL, shell commands, scope changes, stale approvals, and parameter differences.
Decision Tree
flowchart TD
A[diagnostic request] --> B{source licensed and approved}
B -->|no| C[deny source and choose permitted evidence]
B -->|yes| D{collector has explicit read scope}
D -->|no| E[security review and narrow grant]
D -->|yes| F[collect to restricted raw vault]
F --> G{sanitization policy passes}
G -->|no| H[quarantine and human review]
G -->|yes| I[LLM analyzes sanitized pack]
I --> J{additional evidence requested}
J -->|yes| A
J -->|no| K{production change recommended}
K -->|no| L[record findings and close]
K -->|yes| M[independent approval and typed execution]
M --> N[validate audit and rollback]
In Practice
Oracle’s 26ai licensing information says all access methods to Diagnostics and Tuning Pack functionality, including direct access to underlying data, require the corresponding license. It also documents different included entitlements across Oracle offerings. The derived control is an external entitlement registry, not inference from a visible page, view, or parameter.
Oracle’s V$SQL exposes full SQL text, and V$SQL_BIND_CAPTURE exposes captured string values with documented sampling limits. UNIFIED_AUDIT_TRAIL can contain SQL text, binds, client identifiers, objects, privileges, action results, UTC timestamps, and policy names. These documented schemas make diagnostic and audit data sensitive by construction.
Oracle’s auditing guidance separates AUDIT_ADMIN policy and trail management from AUDIT_VIEWER analysis. Its custom-policy guidance supports auditing roles, system privileges, administrative users, object actions, and top-level statements. Audit scope should be tested for coverage and volume before production rollout.
Oracle’s privilege guidance warns that broad dictionary privileges require extreme care. Its Data Redaction documentation explains privileged bypass, while the licensing guide places Data Redaction under Oracle Advanced Security. Redaction complements least privilege; it does not replace it.
Remediation Options
| Proven control gap | Response | Validation |
|---|---|---|
| Collector has broad dictionary access | Replace with explicit approved grants | Negative privilege tests fail closed |
| Licensed source lacks entitlement record | Disable it and use permitted evidence | Manifest rejects future collection |
| Raw values reached model storage | Revoke access, contain, rotate where needed, purge per policy | Access review and deletion evidence complete |
| Audit identity is ambiguous | Add trusted request identity and session attribution | One request traces across all records |
| Audit policy misses executor actions | Correct and test policy scope | Success and failure cases appear |
| Model can invoke mutation tools | Remove capability and separate executor | Adversarial tool tests cannot mutate |
| Executor accepts free-form output | Require typed schema and allowlist | Altered targets and parameters are rejected |
Rollback Plan
Security changes need rollback without reopening the original exposure. Preserve prior grants, audit policies, collector versions, sanitizer rules, and executor schemas through version control and approved change records. Test revocation, credential disablement, collector shutdown, and model-provider cutoff before production use.
If a new audit policy creates unacceptable load or volume, disable the new policy through the authorized audit administrator, preserve already-generated records, and restore the previous tested policy set. Do not solve overhead by disabling all auditing. If sanitizer changes reduce diagnostic utility, revert to the previous sanitized schema—not the raw export.
For a suspected disclosure, stop model submission, quarantine affected artifacts, revoke access, preserve forensic logs, follow incident-response and contractual notification procedures, and rotate exposed credentials or identifiers where applicable. Deleting the prompt alone is not containment when copies exist in gateways, traces, backups, or provider retention.
Where It Breaks
| Failure mode | Why the control fails | Better boundary |
|---|---|---|
| Read-only equals safe | Reads can disclose or overload | Narrow views, templates, budgets, network limits |
| Pack parameter equals license | Technical enablement is not entitlement | Contract-aware registry and owner attestation |
| Data Redaction protects all diagnostics | Privileged exemptions and SYS objects remain | Deterministic evidence sanitizer |
| Unified Auditing is the complete lineage | It does not contain model reasoning or human decision | Joined database, model, and change records |
| Client identifier proves the human | Session metadata is caller-controlled | Authenticated gateway identity plus attribution |
| Prompt says never change production | Prompt text is not enforcement | No mutation capability and separate executor |
| Human clicks approve on prose | Scope can change during translation | Typed immutable action and parameter hash |
| LLM reports high confidence | Confidence cannot prove license, safety, or causality | Evidence, contradiction, validation, and owner sign-off |
What the LLM Cannot Do
The model cannot determine entitlement, classify unknown data as safe, authenticate session metadata, expand access, accept its own recommendation, or decide business tolerance for availability, durability, cost, and compliance.
It cannot terminate sessions, alter parameters, gather production statistics, flush caches, move services, change plans, resize resources, modify audit policy, or execute arbitrary SQL. Those remain separate operational capabilities.
What to Do Next
- Problem: Oracle performance evidence crosses licensing, privilege, privacy, workload, and production-change boundaries that a prompt cannot enforce.
- Solution: Separate collector, audit reader, approver, and executor identities; sanitize deterministic evidence before model access; and join database, model, approval, execution, validation, and rollback records.
- Proof: Run entitlement, negative-privilege, redaction, prompt-injection, audit-coverage, stale-approval, altered-parameter, emergency-revocation, and rollback tests before enabling production collection.
- Action: Create the Oracle evidence-source registry and capability-tier matrix first. Do not connect an LLM until every source has an owner, entitlement, sensitivity class, collector grant, audit policy, retention rule, and denial test.
This completes the Oracle track: time-model triage, SQL-regression proof, infrastructure diagnosis, and a control plane separating investigation from production authority.
Sources
- Oracle AI Database 26ai — Licensing information
- Oracle AI Database 26ai — V$SQL
- Oracle AI Database 26ai — V$SQL_BIND_CAPTURE
- Oracle AI Database 26ai — UNIFIED_AUDIT_TRAIL
- Oracle AI Database 26ai — Introduction to auditing
- Oracle AI Database 26ai — Creating custom unified audit policies
- Oracle AI Database 26ai — Configuring privilege and role authorization
- Oracle AI Database 26ai — DBMS_SESSION
- Oracle AI Database 26ai — Data Redaction exemptions
- Oracle AI Database 26ai — Data Redaction usage limitations
Interactive tools for this topic