Authorization controls what agents can do. Attestation proves what agents did. Oracle 26ai handles authorization. SWT3 provides independent attestation.
Who this is for: Oracle DBAs and enterprise architects evaluating 26ai, compliance officers at Oracle-centric organizations, security teams implementing Select AI Agent governance, and data engineers building agentic AI pipelines on Oracle infrastructure.
Oracle 26ai is live. Enterprise Edition shipped January 2026 for on-premises Linux x86-64. Select AI Agent, managed MCP server, and Private Agent Factory are generally available on OCI, Oracle AI Database@AWS, @Azure, and @Google Cloud.
Oracle AI Database 26ai is Oracle's AI-native database release, with over 300 new features. The capabilities most relevant to AI governance:
Define, run, and govern AI agents inside the database using in-database tools, external tools over REST, or MCP servers. Agents can execute SQL, call external APIs, and chain operations. Tools are created via DBMS_CLOUD_AI_AGENT and exposed as MCP tools.
A multi-tenant Model Context Protocol server that acts as an enterprise access control layer between AI agents and the database. Three application roles control access:
sql_runAuthentication uses OAuth 2.0 with PKCE through OCI Identity Domains. Credentials are stored in OCI Vault.
A no-code platform for deploying data-centric agents as portable containers. Agents are built from database tools and deployed as self-contained units with their own identity and access scope.
Native VECTOR data type with hybrid search across vectors, relational, JSON, graph, and spatial data in a single SQL query. Supports binary vectors, sparse vectors, and hybrid vector indexes.
Row-, column-, and cell-level controls with dynamic data masking. Quantum-resistant encryption. Both human users and AI agents see only authorized data.
Oracle frames its governance around five security questions: Who acted? Under which identity? From what network path? Against which tool? Where is the audit record? These are answerable by design when the MCP server is managed by the database.
Oracle 26ai answers the five questions above from inside the Oracle trust boundary. The database controls who can act, logs what happened, and enforces access policies. This is authorization and audit.
What Oracle does not provide is independent, external evidence that an auditor or regulator can verify without access to the Oracle database itself. Oracle's audit logs are controlled by the same infrastructure that executed the agent. SWT3 provides the independent attestation layer.
| Oracle 26ai Feature | What Oracle Controls (Authorization) | What SWT3 Independently Witnesses (Attestation) |
|---|---|---|
| Select AI Agent | Which tools the agent can invoke, which SQL it can run | That a tool call occurred, with hashed name + arguments + outcome |
| MCP Server Roles | Role-based access (Administrator / Operator / User) | That access was granted or denied, with resource + scope + identity |
| Private Agent Factory | Container deployment, agent lifecycle management | That agents in a chain executed in sequence, with identity + provenance |
| Vector Search / RAG | Which data the agent can retrieve, index access | How many chunks were retrieved, corpus integrity, relevance scores |
| Data Privacy Protection | Row/column/cell masking, who sees what | That data minimization was applied, consent was recorded |
| Oracle Audit Trail | Internal audit records in Oracle format | Independent SHA-256 audit integrity hash, RFC 3161 external timestamp |
Together, Oracle authorization and SWT3 attestation create a complete evidence chain: Oracle proves the agent was permitted to act; SWT3 proves the agent did act, with cryptographic proof that is verifiable outside Oracle's infrastructure.
| Oracle 26ai Feature | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| Select AI Agent Execution | AI-TOOL.1 | Tool/function call invocation | Factor A: tool name hash, Factor B: arguments hash, Factor C: outcome (success/failure) |
AI-INF.1 | Inference provenance | Factor A: model identifier, Factor B: provider, Factor C: clearing level | |
| MCP Server Access Control | AI-ACC.1 | Agent access control event | Factor A: resource hash, Factor B: scope hash (read/write/execute), Factor C: outcome (granted/denied) |
AI-ID.1 | Agent identity assertion | Factor A: agent ID hash, Factor B: signature present (1/0), Factor C: reserved | |
| Vector Search / RAG | AI-RAG.1 | Context retrieval provenance | Factor A: chunks retrieved, Factor B: corpus hash present, Factor C: average similarity |
AI-RAG.2 | Retrieval relevance scoring | Factor A: relevance method, Factor B: threshold, Factor C: pass/fail | |
| Private Agent Factory | AI-CHAIN.1 | Multi-agent chain witnessing | Factor A: chain length, Factor B: chain hash, Factor C: completion status |
AI-GOV.3 | Approved model registry | Factor A: model identifier, Factor B: approval status, Factor C: registry version | |
| Data Privacy Protection | AI-DATA.3 | Data minimization verification | Factor A: fields requested, Factor B: fields returned, Factor C: minimization ratio |
AI-CONSENT.1 | Consent record witnessing | Factor A: consent type, Factor B: scope, Factor C: expiration | |
| Audit Trail | AI-AUDIT.1 | Audit log integrity | Factor A: entries checked, Factor B: integrity verified (1/0), Factor C: log format |
AI-AUDIT.2 | External timestamp attestation | Factor A: TSA provider, Factor B: RFC 3161 token, Factor C: digest algorithm | |
AI-LOG.1 | Logging pipeline attestation | Factor A: log destination, Factor B: pipeline hash, Factor C: rotation policy | |
| Model Management | AI-MDL.1 | Model weight integrity | Factor A: model identifier, Factor B: weight hash, Factor C: version |
AI-MDL.2 | Model version tracking | Factor A: previous version, Factor B: current version, Factor C: change summary | |
| Security | AI-GRD.1 | Guardrail enforcement | Factor A: guardrail ID, Factor B: action taken, Factor C: severity |
AI-GRD.2 | Guardrail bypass detection | Factor A: bypass method, Factor B: detection confidence, Factor C: blocked (1/0) |
Oracle 26ai does: Select AI Agent invokes tools created via DBMS_CLOUD_AI_AGENT. The MCP server enforces which tools the agent can call based on its role (MCP_Administrator, MCP_Operator, MCP_User).
SWT3 independently witnesses: The wrap_tool() call captures a SHA-256 hash of the tool name, a hash of the serialized arguments, and the outcome (success or failure). This creates a verifiable record of every tool invocation that exists outside Oracle's audit trail.
AI-TOOL.1 anchors in the witness ledger correspond to tool calls in Oracle's audit log. The tool name hash in Factor A can be verified against the tool definition in DBMS_CLOUD_AI_AGENT. Discrepancies between Oracle's audit and SWT3's anchor chain indicate tampering in one system or the other.
Oracle 26ai does: The managed MCP server enforces database roles, network ACLs, and private endpoint configurations. OAuth 2.0 with PKCE handles authentication through OCI Identity Domains.
SWT3 independently witnesses: The wrap_access() call captures which resource was accessed, the scope of access (read, write, execute), and whether access was granted or denied. The anchor provides independent proof of the access event.
AI-ACC.1 anchors with Factor C = 0 (denied) document access control enforcement. A series of anchors showing consistent granted/denied patterns demonstrates that Oracle's RBAC is functioning as designed. The SWT3 record is independent of Oracle's internal audit.
Oracle 26ai does: AI Vector Search retrieves context chunks from the database using hybrid queries across vectors, relational, JSON, graph, and spatial data. The database controls which data the agent can access.
SWT3 independently witnesses: The witness_rag_context() call records how many chunks were retrieved, whether a corpus integrity hash was captured, and the average similarity score. This creates an independent record of what data influenced the AI's output.
AI-RAG.1 anchors prove that retrieval occurred and quantify it. Factor A (chunks retrieved) shows the volume of context. Factor B (corpus hash present) proves the corpus was verified at retrieval time. Factor C (average similarity) shows retrieval quality. Compare against Oracle's query history for cross-validation.
Oracle 26ai does: The MCP server authenticates agents via OCI Identity Domains using OAuth 2.0. Each agent operates under a database user identity with associated roles and privileges.
SWT3 independently witnesses: The agent identity is captured as a SHA-256 hash in every witness call. When signing_key is configured, the identity assertion includes an HMAC-SHA256 signature, creating a cryptographic binding between the agent and its attestation chain.
AI-ID.1 anchors with Factor B = 1 (signed) prove the agent's identity was cryptographically bound to each attestation. The agent ID hash in Factor A should be consistent across all anchors from the same agent. Identity mismatches indicate agent impersonation or misconfiguration.
Oracle 26ai does: The database maintains comprehensive audit records. The managed MCP server design ensures that the five security questions (who, identity, network, tool, audit record) are answerable.
SWT3 independently witnesses: The witness_audit() call computes a SHA-256 hash of the audit log entries and records whether integrity was verified. Combined with AI-AUDIT.2 (RFC 3161 external timestamps), this creates a tamper-evident chain that is independent of Oracle's audit infrastructure.
AI-AUDIT.1 anchors prove that Oracle's audit logs were integrity-checked at specific timestamps. If Factor B = 1 (verified), the log was intact at that time. Cross-reference with SWT3 daily Merkle rollups for additional tamper evidence. The combination of Oracle audit + SWT3 anchor + Merkle proof + RFC 3161 timestamp creates four independent layers of evidence integrity.
Oracle 26ai does: Private Agent Factory deploys multiple agents as portable containers. Agents can chain operations, with one agent's output feeding another's input.
SWT3 independently witnesses: The references field on witness calls links anchors into chains. AI-CHAIN.1 captures the chain length, a hash of the chain composition, and the completion status. This creates a verifiable record of multi-agent workflows that spans across individual agent boundaries.
AI-CHAIN.1 anchors document the full agent workflow. Factor A (chain length) shows how many agents participated. Factor B (chain hash) provides a unique identifier for the workflow. Follow the anchor references to trace the complete execution path from first agent to last.
Oracle's managed MCP server and SWT3 operate in parallel, producing independent evidence chains:
Authorization path (Oracle): An AI agent sends a request to the Oracle MCP server. The server authenticates the agent via OCI Identity Domains, checks database roles and ACLs, and either permits or denies the operation. If permitted, the agent's tool call executes against the database. Oracle logs the event in its internal audit trail.
Attestation path (SWT3): The SWT3 SDK wraps the agent's inference and tool calls at the application layer. Before the agent's request reaches the Oracle MCP server, SWT3 captures the agent identity, tool name, arguments, and context. After the response returns, SWT3 records the outcome. Each event produces a SHA-256 fingerprinted Witness Anchor that is stored in the SWT3 ledger, independent of Oracle's infrastructure.
Verification: An auditor can compare Oracle's audit trail against SWT3's anchor chain. Both should reflect the same events. If they diverge, the independent attestation identifies where the discrepancy occurred. Anchors are verifiable at sovereign.tenova.io/verify without requiring access to the Oracle database.
| Examiner Question | Where to Look |
|---|---|
| Which tools did the AI agent invoke in this Oracle database? | AI-TOOL.1 anchors. Factor A = tool name hash. Cross-reference with DBMS_CLOUD_AI_AGENT tool definitions. |
| Was access control enforced for this agent? | AI-ACC.1 anchors. Factor C = 1 (granted) or 0 (denied). Match against Oracle MCP server role assignments. |
| What data did the RAG pipeline retrieve? | AI-RAG.1 anchors. Factor A = chunks retrieved, Factor B = corpus integrity verified, Factor C = similarity score. |
| Can you prove agent identity across this workflow? | AI-ID.1 anchors with Factor B = 1 (HMAC signed). Consistent agent ID hash across all anchors in the chain. |
| Is the Oracle audit trail intact? | AI-AUDIT.1 anchors with Factor B = 1 (integrity verified). AI-AUDIT.2 anchors with RFC 3161 external timestamps. SWT3 Merkle rollup for inclusion proof. |
| How do you trace a multi-agent workflow? | AI-CHAIN.1 anchors. Follow the references field to trace the full execution path. Factor A = chain length, Factor B = chain hash. |
| Do you have evidence independent of Oracle's infrastructure? | Every SWT3 Witness Anchor is verifiable at sovereign.tenova.io/verify. SHA-256 fingerprints, Merkle proofs, and RFC 3161 timestamps exist outside Oracle's trust boundary. |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup