Witness evidence mapping for Oracle's AI-native database. Covers AI Vector Search, Select AI, AI Pipelines, Oracle ML, and database-level security controls for AI workloads.
Who this is for: Database administrators operating Oracle 26ai with AI features enabled, AI platform teams building on Oracle's in-database ML and vector search, compliance officers governing Oracle AI deployments, and auditors assessing Oracle-based AI systems under ISO 42001 or the EU AI Act. Applies to all deployment models: Oracle Cloud Infrastructure (OCI), third-party clouds, and on-premises.
Oracle holds ISO 42001:2023 certification for both Oracle SaaS Applications and Oracle Cloud Infrastructure AI Services. Oracle also completed the CSA AI Consensus Assessments Initiative Questionnaire (CAIQ). These accreditations establish a governance baseline -- SWT3 extends it with continuous, cryptographic evidence at the workload level.
Oracle Database 26ai is the first Oracle release to brand AI as a core database capability. With 300+ new features centered on AI and developer productivity, it moves AI workloads inside the database engine itself: vector embeddings stored alongside relational data, natural language queries translated to SQL, and ML models trained and served without leaving the database.
This creates a governance challenge that did not exist with previous Oracle releases. When AI inference happens inside the database, traditional application-level monitoring cannot observe it. The database becomes both the AI infrastructure and the data store, collapsing the boundary between "data governance" and "AI governance" into a single system.
Three specific risks drive the need for this crosswalk:
SWT3 witness anchors bridge this gap. By instrumenting the application layer that calls Oracle 26ai features -- whether that application runs on APEX, a microservice, or a standalone client -- teams can produce cryptographic evidence of what AI operations occurred, what data was accessed, and what governance controls were in effect, without modifying the database engine.
| Feature | Category | Governance Relevance |
|---|---|---|
| AI Vector Search | Retrieval / RAG | Embedding storage, similarity queries, retrieval provenance for RAG pipelines |
| Select AI | Inference | Natural language to SQL translation; AI-generated queries execute with user privileges |
| AI Pipelines | ML Ops | In-database ML workflow orchestration; model training data selection and feature engineering |
| Oracle Machine Learning | Model Lifecycle | AutoML, model deployment, scoring, versioning -- all within the database |
| JSON Relational Duality | Data Access | Dual-view data access; AI applications read JSON while governance queries use relational views |
| Property Graphs (SQL/PGQ) | Graph Analytics | Real-time graph analysis on operational data; knowledge graph construction for AI |
| Database Vault | Access Control | Privileged access prevention; blocks DBA access to AI training data and model parameters |
| Data Safe | Data Discovery | Sensitive data identification in AI training sets; masking for non-production AI environments |
| SQL Firewall | Query Control | Allowlist/blocklist for SQL patterns; prevents unauthorized AI query execution |
| Unified Auditing | Audit Trail | Fine-grained audit of all AI feature usage: vector queries, Select AI calls, ML operations |
| Transparent Data Encryption | Encryption | Column-level encryption for embeddings, model weights, and AI training data at rest |
| AI-Optimized SQL | Performance | AI-driven query optimization; changes execution plans autonomously |
| Oracle 26ai Feature | SWT3 Procedure | Evidence Produced |
|---|---|---|
| AI Vector Search | AI-RAG.1 | Retrieval provenance: which embeddings were queried, similarity thresholds, source document IDs |
| Select AI | AI-EXPL.1 | Query transparency: natural language input, generated SQL, execution context, result summary |
| Select AI | AI-INF.1 | Inference attestation: model invoked, prompt context, response metadata |
| AI Pipelines | AI-MDL.3 | Pipeline execution: training data selection, feature engineering steps, model output |
| Oracle ML (AutoML) | AI-MDL.4 | Model lifecycle: version deployed, training date, algorithm selection, performance metrics |
| Oracle ML (scoring) | AI-MDL.5 | Model weights attestation: hash of deployed model, scoring function signature |
| Database Vault | AI-ACC.1 | Access control evidence: realm protections active, DBA exclusions enforced, privilege audit |
| Data Safe | AI-DATA.1 | Data provenance: sensitive columns identified, masking policies applied, discovery scan results |
| Data Safe | AI-FAIR.1 | Bias indicator: protected attribute columns flagged in training data, distribution analysis |
| SQL Firewall | AI-GRD.1 | Guardrail evidence: SQL patterns blocked, violation attempts logged, policy version |
| Unified Auditing | AI-AUDIT.1 | Audit trail: all AI feature invocations with user, timestamp, operation type, object accessed |
| TDE + encryption | AI-SEC.1 | Security posture: encryption status for AI data columns, key rotation schedule, algorithm |
| Property Graphs | AI-DATA.2 | Data quality: graph completeness metrics, relationship integrity, orphan node detection |
| AI-Optimized SQL | AI-GOV.5 | Governance framework: autonomous optimization decisions logged, plan change justification |
| Oracle ML catalog | AI-SBOM.1 | Component inventory: models deployed, versions, training data lineage, dependency chain |
| JSON Duality Views | AI-TRANS.1 | Transparency record: data access paths documented, API vs relational access logged |
Oracle AI Vector Search stores embeddings alongside relational data and executes similarity queries within SQL. When an application uses vector search to retrieve context for a generative AI response (RAG pattern), the retrieval step is a database query -- not an API call to a vector database.
What to witness: The SQL query containing the VECTOR_DISTANCE function, the similarity threshold, the number of results returned, and the source document identifiers of the retrieved rows.
Assessor tip: Ask for the witness anchor covering a specific RAG retrieval. The anchor's factor_a should contain the query fingerprint, factor_b the retrieval count, and factor_c the source document IDs or a hash thereof. Compare against the Unified Audit log entry for the same timestamp.
Select AI translates natural language questions into SQL at query time. The generated SQL executes with the calling user's privileges and returns results directly. Without witnessing, there is no record of what natural language input produced which SQL query.
What to witness: The natural language input, the generated SQL statement, the execution user, the tables accessed, and whether the generated query was modified by any SQL Firewall rules.
Assessor tip: Select AI is a high-risk feature for explainability audits. The witness anchor provides the mapping between human intent (natural language) and machine action (SQL). Without it, an auditor cannot determine whether a Select AI query accessed data the user intended to query.
Every Select AI invocation and every Oracle ML scoring call is an AI inference. Select AI translates natural language to SQL and executes it. Oracle ML applies a deployed model to input data and returns a prediction. Both produce results that influence decisions, and both need an independent record.
What to witness: The inference trigger (natural language prompt or scoring function call), the model or AI feature invoked, the input summary (table, row count, or query scope), and the output summary (prediction, classification, or SQL result shape).
Assessor tip: For Select AI, cross-reference AI-INF.1 (what inference happened) with AI-EXPL.1 (what SQL was generated). Both anchors should share a timestamp window. For Oracle ML scoring, verify the model version in AI-INF.1 matches the deployed version in AI-MDL.4.
Oracle AI Pipelines orchestrate ML workflows inside the database: data extraction, feature engineering, model training, and evaluation. Each pipeline run produces a model artifact. Without witnessing, there is no record of which data was selected, what transformations were applied, or what the model saw during training.
What to witness: Pipeline name and version, source tables and row filters, feature engineering steps (joins, aggregations, normalization), training/test split ratio, and evaluation metric at pipeline completion.
Assessor tip: Pipeline lineage is the chain from raw data to deployed model. The AI-MDL.3 anchor should include enough detail to reproduce the training run. Ask: "Given this anchor, could you retrain the same model?" If not, the lineage is incomplete.
Oracle Machine Learning trains, deploys, and scores models inside the database. AutoML selects algorithms automatically. Models are stored as database objects and can be versioned, but model promotion and deprecation happen within PL/SQL procedures.
What to witness: Model name and version at deployment time, algorithm selected (if AutoML), training data table, row count, feature columns, and performance metrics (AUC, accuracy, F1) at deployment.
Assessor tip: Query ALL_MINING_MODELS to verify the model version matches the witness anchor. Check MINING_MODEL_SETTINGS for algorithm and hyperparameters. The anchor's timestamp should precede or coincide with the model's BUILD_DATE.
Oracle ML models are stored as database objects. The model's internal state (weights, coefficients, decision boundaries) determines its behavior. A model can be retrained or replaced without changing its name. Hashing the model artifact at deployment creates a tamper-evident record of exactly which model was serving predictions.
What to witness: A SHA-256 hash of the serialized model object, the model name and version, the algorithm type, and the timestamp of deployment.
Assessor tip: Use DBMS_DATA_MINING.GET_MODEL_DETAILS_* functions to extract model internals. Hash the output deterministically. If the hash in the witness anchor does not match the current model's hash, the model was modified after attestation -- which is a finding unless a new AI-MDL.4 anchor covers the change.
Database Vault creates realms around sensitive objects, preventing even privileged users (SYS, SYSTEM) from accessing AI training data or model parameters. This is the strongest access control available for AI data in any relational database.
What to witness: Realm configuration (protected schemas, objects), active rule sets, failed access attempts by privileged users, and the last realm policy modification timestamp.
Assessor tip: Database Vault logs are separate from Unified Auditing. Request both the witness anchor (application-level attestation) and the Vault violation report (database-level enforcement). Cross-reference timestamps to verify continuous protection.
Data Safe discovers sensitive data across the database, including columns used in AI training sets. It identifies PII, financial data, and health records that may contaminate model training. Masking policies can de-identify data for non-production AI environments.
What to witness: Data Safe discovery scan results (sensitive columns found in AI training tables), masking policies applied, and the gap between discovery and remediation.
Assessor tip: Cross-reference the Data Safe report with the training data table specified in the AI-MDL.4 anchor. If the training table contains columns flagged as sensitive by Data Safe, verify that masking or consent controls are documented.
Data Safe can identify columns containing protected attributes (gender, race, age, disability status, religion) in AI training tables. When these columns are present in training data, the model may encode protected-class correlations that produce disparate outcomes.
What to witness: Data Safe discovery scan ID, tables scanned, protected attribute columns found, the classification confidence, and whether the columns are used as direct features, dropped, or masked in the training pipeline.
Assessor tip: AI-FAIR.1 is not a claim that the model is fair. It is evidence that protected attributes were identified and their treatment was documented. A finding occurs when protected columns exist in training data but no AI-FAIR.1 anchor documents how they were handled. The absence of evidence is the risk, not the presence of protected data.
SQL Firewall controls which SQL patterns can execute against the database. For AI workloads, this prevents unexpected queries generated by Select AI or application-level prompt injection from accessing unauthorized tables.
What to witness: Firewall policy version, allowlist rules active for AI service accounts, violation events (blocked queries), and policy change timestamps.
Assessor tip: SQL Firewall violations are the database-level equivalent of guardrail triggers. A witness anchor for AI-GRD.1 should include the violation count for the assessment period. Zero violations with an active firewall is stronger evidence than no firewall at all.
Oracle Unified Auditing captures all database activity in a single audit trail. For AI workloads, this includes vector search queries, Select AI invocations, ML model training runs, and scoring operations. Audit policies can target specific AI-related objects and operations.
What to witness: Audit policy configuration covering AI operations, sample audit entries for the assessment period, retention policy, and tamper-evidence (audit trail stored in read-only tablespace or exported to immutable storage).
Assessor tip: The Unified Audit trail is the database's native evidence. The SWT3 witness anchor adds a second, independent record at the application layer. Together they provide dual-source evidence -- what the application intended and what the database executed.
Transparent Data Encryption protects AI training data, model weights, and vector embeddings at rest. Column-level encryption can target specific high-sensitivity columns used in AI workloads without encrypting the entire tablespace.
What to witness: Encryption status for AI-relevant tablespaces and columns, key rotation date, algorithm (AES-256), and whether the encryption key is managed by Oracle Key Vault or an external KMS.
Assessor tip: Query DBA_ENCRYPTED_COLUMNS to verify column-level encryption. For tablespace encryption, check V$ENCRYPTED_TABLESPACES. The witness anchor should reflect the encryption state at assessment time, not just at initial deployment.
Oracle Property Graphs (SQL/PGQ) enable knowledge graph construction from operational data. When used as input to AI systems, graph completeness and relationship integrity directly affect model quality. Data Safe complements this by validating that data used in AI pipelines meets defined quality thresholds.
What to witness: Graph node and edge counts, orphan node percentage, relationship integrity checks (dangling references), and Data Safe data quality assessment scores for AI training tables.
Assessor tip: Data quality evidence is foundational. A model trained on incomplete graph data or low-quality tabular data produces unreliable predictions regardless of algorithm quality. The AI-DATA.2 anchor should precede (in timestamp) any AI-MDL.3 or AI-MDL.4 anchor that references the same data source.
Oracle 26ai uses AI to optimize SQL execution plans automatically. The database changes how queries run -- including AI workload queries -- without human approval. This is an autonomous decision made by an AI system about how to execute AI workloads. The governance question: who approved the optimization, and what changed?
What to witness: Execution plan changes for AI-related queries, the optimization trigger (cost estimate, cardinality change), before/after plan hashes, and whether the change affected AI inference latency or results.
Assessor tip: This is a subtle but important control. AI-Optimized SQL can change the order in which rows are processed by a scoring function, which can affect batch inference results in edge cases. Ask whether AI optimization is enabled for AI workload schemas and whether plan stability (SQL Plan Baselines) is used to constrain autonomous changes.
The Oracle ML model catalog (ALL_MINING_MODELS, ALL_MINING_MODEL_ATTRIBUTES) contains a complete inventory of deployed models, their algorithms, training data sources, and deployment dates. This serves as a database-native AI Software Bill of Materials.
What to witness: Point-in-time snapshot of deployed models, algorithm types, creation dates, and the training data lineage for each model.
Assessor tip: The model catalog is queryable via SQL. Run SELECT model_name, algorithm, build_duration, model_size FROM ALL_MINING_MODELS and compare against the AI-SBOM.1 witness anchor to verify completeness. Models present in the database but absent from the SBOM are a finding.
JSON Relational Duality Views allow the same data to be accessed as JSON documents (by AI applications) or as relational tables (by governance queries). This dual-access model means an AI application may read data through a JSON view while an auditor queries the same data through a relational view. Transparency requires documenting which access path was used for each AI operation.
What to witness: The access method (JSON document API or SQL relational query), the duality view name, the operations performed (read, update, upsert), and the application identity.
Assessor tip: Duality views simplify development but can obscure audit trails if the JSON access path bypasses row-level security or auditing policies configured on the underlying relational tables. Verify that Unified Auditing captures both JSON and relational access paths for AI-relevant tables.
Oracle Database 26ai includes security features that predate the AI branding but become governance-relevant when AI workloads run inside the database. These features were designed for data protection, not AI governance -- but the evidence they produce maps directly to AI governance requirements.
| Security Feature | AI Governance Role | ISO 42001 Annex A Control |
|---|---|---|
| Database Vault | Prevents privileged access to AI training data and model parameters | A.6.2.6 (Security and robustness) |
| Data Safe | Discovers sensitive data in AI training sets; enforces masking | A.8.4 (Data governance) |
| SQL Firewall | Blocks unauthorized AI queries; prevents prompt injection at SQL level | A.6.2.6 (Security and robustness) |
| Unified Auditing | Complete audit trail of all AI operations | A.6.2.5 (Monitoring and measurement) |
| Label Security | Row-level classification for AI training data sensitivity tiers | A.8.4 (Data governance) |
| Real Application Security | Application-context access control for AI service accounts | A.6.2.6 (Security and robustness) |
The governance gap: Oracle's ISO 42001 certification covers the platform. It does not cover what your application does with the platform. A customer deploying a fraud detection model on Oracle 26ai inherits Oracle's platform-level ISO 42001 compliance, but the model's fairness, explainability, and lifecycle governance remain the customer's responsibility. SWT3 fills this gap at the workload level.
SWT3 witnesses AI operations at the application layer. It does not replace or duplicate Oracle's native capabilities:
| Procedure | Vector Search | Select AI | AI Pipelines | Oracle ML | DB Vault | Data Safe | SQL Firewall | Unified Audit |
|---|---|---|---|---|---|---|---|---|
| AI-RAG.1 | ✓ | ✓ | ||||||
| AI-EXPL.1 | ✓ | ✓ | ||||||
| AI-INF.1 | ✓ | ✓ | ||||||
| AI-MDL.3 | ✓ | |||||||
| AI-MDL.4 | ✓ | |||||||
| AI-MDL.5 | ✓ | |||||||
| AI-ACC.1 | ✓ | ✓ | ||||||
| AI-DATA.1 | ✓ | |||||||
| AI-FAIR.1 | ✓ | |||||||
| AI-GRD.1 | ✓ | ✓ | ||||||
| AI-AUDIT.1 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| AI-SEC.1 | ✓ | ✓ | ||||||
| AI-DATA.2 | ✓ | ✓ | ||||||
| AI-GOV.5 | ✓ | |||||||
| AI-SBOM.1 | ✓ | |||||||
| AI-TRANS.1 | ✓ |
16 procedures mapped across 12 Oracle 26ai features. Unified Auditing contributes to 8 procedures as the database-native evidence source. Oracle ML features contribute to 4 model lifecycle procedures. Database Vault, Data Safe, and SQL Firewall each address distinct governance domains. Every procedure has a corresponding evidence card in Section 4 with assessor-specific verification guidance.
The Python and TypeScript examples below cover different procedures to show the full range of Oracle 26ai witnessing patterns. Both SDKs support all 16 procedures with identical API semantics.
from swt3_ai import Witness
witness = Witness(
endpoint="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
agent_id="oracle-26ai-fraud-model"
)
# Witness a Select AI inference
anchor = witness.witness(
procedure="AI-EXPL.1",
factor_a="SELECT AI: What were last month's refund totals by region?",
factor_b="Generated SQL: SELECT region, SUM(refund_amount) FROM transactions WHERE ...",
factor_c="Rows returned: 12, execution user: analytics_svc"
)
# Witness a Vector Search retrieval for RAG
anchor = witness.witness(
procedure="AI-RAG.1",
factor_a="vector_query: policy_embeddings, top_k=5, threshold=0.82",
factor_b="Retrieved: doc-4421, doc-4418, doc-4455, doc-4402, doc-4419",
factor_c="Source: compliance_policies table, embedding_model: all-MiniLM-L6-v2"
)
# Witness Oracle ML model deployment
anchor = witness.witness(
procedure="AI-MDL.4",
factor_a="model: FRAUD_DETECT_v3, algorithm: RANDOM_FOREST",
factor_b="training_table: TXN_FEATURES, rows: 2,847,331, features: 42",
factor_c="AUC: 0.943, deployed: 2026-10-13T14:00:00Z"
)
witness.flush()import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://sovereign.tenova.io/api/v1/witness',
apiKey: 'axm_live_...',
agentId: 'oracle-26ai-fraud-model',
});
// Witness Database Vault access control
await witness.witness({
procedure: 'AI-ACC.1',
factorA: 'realm: AI_TRAINING_DATA, protected_schemas: ML_OWNER, FEATURE_STORE',
factorB: 'violations_blocked: 3, last_violation: SYS attempted SELECT on ML_OWNER.MODEL_WEIGHTS',
factorC: 'policy_version: VAULT_AI_v2, last_modified: 2026-10-01',
});
// Witness SQL Firewall guardrail
await witness.witness({
procedure: 'AI-GRD.1',
factorA: 'firewall_policy: AI_SVC_ALLOWLIST, mode: ENFORCE',
factorB: 'blocked_patterns: 7, categories: cross-schema JOIN, DDL, GRANT',
factorC: 'policy_applied_to: AI_INFERENCE_SVC, AI_TRAINING_SVC',
});
await witness.flush();Oracle, Oracle Database, Oracle Machine Learning, Database Vault, Data Safe, Select AI, and AI Vector Search are trademarks or registered trademarks of Oracle Corporation. This guide is an independent governance mapping and is not endorsed by or affiliated with Oracle Corporation.