Why Oracle 26ai's newest security feature changes the calculus for AI agents that query enterprise data.
Source: Oracle.com
If you have been following the evolution of AI agent architectures, you have likely encountered the Model Context Protocol — MCP. In simple terms, MCP is a standard that allows AI agents like Claude, GPT, and others to connect to external data sources and tools in a consistent way. Instead of pasting data into a prompt, the agent queries your database, your vector store, or your APIs directly through an MCP server that acts as a controlled gateway.
This is powerful. It means an AI agent can search your Oracle database, retrieve relevant documents, and generate grounded answers — all in real time. But it also introduces a security question that traditional application architectures never had to answer: who controls what the AI agent can see?
• • •
The Trust Boundary Problem
In a traditional application, the trust boundary sits in the application layer. Your Java or Python code decides which SQL to execute, which rows to return, and which columns to display. The database trusts the application to do the right thing. This has worked for decades because the application was deterministic — it ran the same code every time.
An AI agent is not deterministic. It constructs SQL dynamically based on natural language input. It reasons about what to query, how to filter, and what to return. And critically, it can be manipulated — through prompt injection, through adversarial inputs, or simply through an unexpected query that the MCP server developer did not anticipate.
When the application layer is an AI agent, you cannot trust the application layer. The trust boundary must move somewhere else.
This is the core insight behind Oracle's Deep Data Security in Database 26ai. The trust boundary moves from the application into the database kernel itself. The database enforces access policies regardless of what SQL the agent constructs. The agent does not decide what it can see — the database does.
What Deep Data Security Does
Deep Data Security provides three levels of enforcement, all defined declaratively in SQL and enforced transparently inside the database engine during query execution.
Row-level: The agent only sees rows it is authorized for. If your MCP server connects an agent that is authorized for the Oracle Fusion namespace, the agent cannot retrieve documents from Oracle EBS or Oracle NetSuite — those rows are simply not visible. This is similar to Virtual Private Database (VPD), but defined declaratively rather than procedurally.
Column-level: Entire columns can be hidden based on the agent's identity. A general-purpose search agent might see the document title and content but not the client name or revenue figures. The column does not appear in the result set at all.
Cell-level: This is the new capability in 26ai that neither VPD nor Data Redaction provided. Individual cell values can be masked as NULL based on the agent's clearance level. An agent might see salary data for junior staff but receive NULL for executive compensation — same table, same column, different cells, different treatment based on who is asking.
Oracle Technical Detail
Deep Data Security policies are defined using declarative SQL — not procedural PL/SQL as with VPD. This is a meaningful architectural shift. Declarative policies are easier to audit, easier to compose, and easier for tools like OCI Data Safe to manage centrally. The enforcement happens at the SQL execution layer inside the Oracle kernel. There is no mid-tier component, no external policy server, and no way for the connecting application to bypass it.
Why This Matters for MCP
Consider what an MCP server does. It sits between an AI agent and your Oracle database. The agent sends a query — perhaps a vector similarity search against your document embeddings, or a structured SQL query against your metadata tables. The MCP server translates this into a database call and returns the results.
Without Deep Data Security, the MCP server is the security boundary. If the MCP server has a bug, if the agent constructs an unexpected query, or if someone discovers a prompt injection that causes the agent to issue a broad SELECT *, the database returns everything the MCP server's connection is authorized for. The database does not know or care that the request came from an AI agent with a specific role.
With Deep Data Security, the database itself becomes the security boundary. The MCP server sets the agent's identity via an application context at connection time. From that point forward, every query the agent issues — regardless of how it was constructed — is filtered by the database kernel. Unauthorized rows are excluded. Hidden columns do not appear. Masked cells return NULL. The agent cannot see data it is not cleared for, even if the SQL it constructs would normally return that data.
The agent literally cannot construct a SQL statement that returns unauthorized data. The enforcement is below the SQL layer, in the database kernel.
A Practical Example
In my work with the AOBG Oracle practice, we operate an MCP server that provides AI agents with access to a Knowledge Repository of over 925,000 documents across 27 Oracle product namespaces. Different agents have different authorization levels — an RFP generation agent should access methodology documents but not client-specific financial data. A search agent should see document titles but not proprietary accelerator source code.
With Deep Data Security, we define these boundaries once, in SQL, and the database enforces them for every agent on every query. The implementation looks like this:
-- Set the agent's identity at connection time BEGIN DBMS_SESSION.SET_CONTEXT( 'MCP_CTX', 'AGENT_ID', 'rfp-pipeline' ); DBMS_SESSION.SET_CONTEXT( 'MCP_CTX', 'CLEARANCE', 'STANDARD' ); END; -- Row-level: agent only sees authorized namespaces CREATE DATA SECURITY POLICY mcp_namespace_policy ON document_chunks USING ( namespace IN ( SELECT authorized_namespace FROM agent_authorizations WHERE agent_id = SYS_CONTEXT('MCP_CTX', 'AGENT_ID') ) ); -- Column-level: hide client names from standard agents CREATE DATA SECURITY POLICY mcp_column_policy ON documents HIDE COLUMNS (client_name, revenue_amount) WHEN SYS_CONTEXT('MCP_CTX', 'CLEARANCE') < 'EXECUTIVE';Once these policies are enabled, every vector search the MCP server executes — every VECTOR_DISTANCE() query, every metadata lookup, every chunk retrieval — is filtered automatically. No changes to the MCP server code are required. The database handles it.
How This Compares to What We Had Before
Oracle has had row-level security (VPD) since Oracle 8i. It has had Data Redaction since 12c. Both are valuable, and both are still available. Deep Data Security extends and modernizes these capabilities for the AI agent era.
VPD required writing PL/SQL policy functions — procedural code that can be complex to maintain, difficult to audit, and easy to get wrong. Deep Data Security uses declarative SQL, which is simpler to write, simpler to review, and integrable with OCI Data Safe for centralized management.
Data Redaction masks values but the column is still visible — the agent knows the column exists and that data is being hidden. Deep Data Security can hide the column entirely. The agent does not know the column exists in the first place.
And cell-level masking — returning NULL for specific cells based on who is asking — is entirely new. Neither VPD nor Data Redaction could do this. It fills the gap between "you can see this column" and "you cannot see this column" with a more nuanced "you can see this column, but not every value in it."
The Broader Pattern
Deep Data Security is part of a broader shift in how we think about AI security. In traditional architectures, security was an application concern. In agentic architectures, security must become a data concern — enforced at the data layer, below the application, below the agent, below the prompt.
Oracle 26ai positions the database as the trust anchor for AI workloads. The agent can be compromised. The MCP server can have bugs. The prompt can be manipulated. But the data stays secure because the database enforces policies that no layer above it can override.
What You Get on Autonomous Database
Deep Data Security is included at no additional cost on Oracle Autonomous Database. Combined with TDE (always-on encryption), SQL Firewall (injection protection), Unified Audit (column-level logging), and Data Safe (security posture management), you have a comprehensive security stack for AI workloads — all included in the base ADW/ADB pricing.
• • •
I have been working with Oracle database security features for over three decades, from the early days of views-based security through VPD, Database Vault, and now Deep Data Security. Each generation has moved the trust boundary deeper into the database. Deep Data Security is the most significant step yet because it addresses a problem that did not exist when VPD was designed: an application layer that reasons, improvises, and can be manipulated.
If you are building an MCP server, a RAG pipeline, or any architecture where AI agents query Oracle data, Deep Data Security should be on your implementation plan. Not because it is the newest feature, but because it solves the right problem at the right layer. The trust boundary belongs in the database. Oracle 26ai finally puts it there.