Your AI Agent Wants Your Data. Here's How to Lock It Down with Jeff Smith, Oracle

Oracle's AI database combines native vector/graph/relational support with MCP (Model Context Protocol) tooling to let AI agents safely and efficiently access

Securing Agent Access to Enterprise Data: An Architectural Analysis of Database-Mediated Tooling over Natural-Language-to-SQL

Abstract

Enterprise adoption of agentic artificial intelligence is constrained less by model capability than by the problem of granting agents safe, accurate, and economical access to operational data. This analysis examines an architectural position advanced by Oracle engineer Jeff Smith: that reliable agent-database interaction should rest on curated, pre-built tooling and database-layer authorization rather than open-ended natural-language-to-SQL (NL2SQL) generation. The approach combines a converged database storing relational, vector, and graph data in a single instance with a Model Context Protocol (MCP) server exposing a deliberately small set of consolidated tools. Three deployment patterns are analyzed - parameterized business reporting, read-only performance diagnostics, and document-derived schema annotation - alongside an authorization model termed deep data security, in which single sign-on (SSO) scopes drive dynamic result-set filtering inside the database. Findings indicate that context engineering and authorization placement, rather than query-generation quality, dominate practical outcomes.

1. Introduction

As organizations move from single-turn chatbot interfaces toward autonomous agents capable of querying operational systems, a structural problem emerges: agents require access to the same financial, human resources (HR), enterprise resource planning (ERP), logistics, retail, government, and healthcare data that production applications already depend on, but the mechanisms used to grant that access carry correctness and governance risk that application-layer access controls were never designed to absorb.

The dominant pattern for connecting LLMs to structured data has been NL2SQL translation, in which a model generates ad hoc SQL against a database schema in response to a natural-language question. This analysis examines a counter-position: that NL2SQL is unreliable enough in production that it should be replaced, or at minimum supplemented, by curated tools - pre-built reports, multi-action utilities, and annotated schema metadata - delivered through the Model Context Protocol (MCP), with authorization enforced at the database layer rather than within any individual tool or client.

The central thesis is that the dominant bottleneck in agent-database integration is not model reasoning quality but context engineering (what occupies an agent's limited context window) and authorization placement (where access control decisions are actually enforced). Section 2 establishes the architectural foundation, including the converged database and MCP's role as a model-agnostic interface. Section 3 analyzes three concrete use cases - business reporting, DevOps/performance tuning, and schema exploration. Section 4 consolidates implementation findings. Sections 5 and 6 address broader implications and conclusions.

2. Background and Related Work

Two architectural trends frame this discussion. The first is the converged database: over roughly three decades, Oracle has incorporated additional data types and workloads - including native vector storage and graph support - into a single engine. This matters for agentic AI because it allows a database to participate directly in Retrieval-Augmented Generation (RAG) pipelines, including Graph RAG, without replicating relational data into a separate vector store. The practical consequence is a single SQL interface spanning heterogeneous business domains, and correspondingly a single MCP server as the agent's point of entry, rather than a proliferation of domain-specific data stores each requiring their own connector.

The second is context engineering. MCP server designs that expose one tool per capability - one tool per report, one tool per administrative action - consume disproportionate context budget before any actual work occurs, particularly once the number of exposed capabilities reaches the hundreds. MCP itself is described as model-agnostic: tools built once against the protocol function across agent frameworks, since compliance depends only on the existence of an MCP server and defined tools, not on a specific model provider. The protocol is reported to evolve on roughly quarterly release cycles.

3. Core Analysis

3.1 Parameterized Reporting as an Alternative to Ad Hoc Query Generation

The first use case addresses a persistent organizational pattern: business analysts, who are not SQL experts, generate a continuous stream of ad hoc questions (sales by region, discount rates, and similar aggregations) that are currently answered through manual spreadsheet or BI Publisher work. NL2SQL is identified as a tempting but hazardous solution to this problem. The core failure mode is characterized as an "if it compiles, ship it" mentality: a generated query executes successfully and returns a result, but the result answers a different question than the one the analyst intended. Compounding this, LLMs tasked with locating relevant data without guidance tend to "brute-force" the database schema - issuing exploratory queries to discover tables, columns, and relationships - a process that is unreliable, token-expensive, and slow.

The proposed alternative is to pipeline existing SharePoint and network-drive reports directly into the database as pre-built, parameterized tools, rather than letting the agent construct SQL from scratch. Critically, the MCP server exposes only two tools regardless of how many reports exist - list reports and execute reports - avoiding the context bloat that would result from registering one tool per report. For users with appropriate OAuth 2.0 scope, the underlying SQL behind a report can optionally be revealed, allowing the agent to learn the data model incrementally and generate more accurate ad hoc queries later. MCP servers additionally support toggling between fully ad hoc SQL execution and a restricted custom-tools-only mode, depending on the trust level granted to a given deployment.

3.2 Read-Only Diagnostics and Database-Layer Security in DevOps Workflows

The second use case concerns performance tuning. LLMs are described as trustworthy sources of diagnostic advice - for example, recommending that an index be dropped or rebuilt - but not as safe to execute such changes directly against production systems. The solution leverages Data Guard, Oracle's read-only standby instance that mirrors production, as a sandboxed environment in which an agent can investigate performance issues without risk of modifying live data.

However, read-only access is explicitly identified as insufficient on its own: row- and column-level restrictions remain necessary even within a safe, non-production environment, since a read-only replica may still expose sensitive data to users without an organizational need to see it. This leads to the paper's central security claim: "The best place to always implement security for the database is... at the database," because tool-level restrictions can be bypassed by any other client - human or automated - connecting directly to the database rather than through the sanctioned tool. Diagnostic tooling in this use case bundles multiple related actions (six actions within a single performance-tuning tool) rather than registering one tool per action, consistent with the context-engineering rationale established in Section 2. Underlying mechanisms include the Automatic Workload Repository (AWR), which generates performance profile reports, and the cost-based optimizer, whose execution plan quality depends on data profile statistics such as column cardinality - meaning that keeping statistics current is itself a performance lever available to the agent.

3.3 Schema Annotation and Document-Derived Metadata

The third use case addresses the problem of undocumented legacy schemas, where business-critical data may reside in cryptically named objects (the example given is sales data stored in a table named XHR_123) with meaning preserved only in Confluence pages or institutional memory. Two tools address this gap. A schema information tool returns a compressed JSON dictionary of schema attributes in a single call, replacing what would otherwise require an agent to issue multiple exploratory queries (listing tables, columns, comments, and sample rows). This tool supports multiple verbosity levels - verbose, slim, and medium - plus keyword filtering, allowing the context cost of schema exploration to be tuned to the task. A separate generate annotations tool ingests unstructured documents - PDFs, PowerPoint files, Excel workbooks, and Word documents, including Confluence exports - extracts and organizes their text, and stores the result back into the database as schema metadata. This annotated metadata is reported to materially improve NL2SQL reliability by resolving ambiguous units of measure or column semantics, demonstrated using personal Strava workout data as an illustrative example.

4. Technical Insights

Several implementation patterns recur across the three use cases and generalize beyond this specific database vendor:

• Tool consolidation over tool proliferation. Exposing few, multi-purpose tools (e.g., list reports/execute reports, or a single six-action tuning tool) rather than one tool per capability is presented as a direct response to context-window constraints, not merely an API design preference.
• Authorization at the data layer, not the tool layer. Because any client capable of reaching the database can bypass a tool's internal checks, access control implemented only within a tool is treated as structurally insufficient; the recommended enforcement point is the database engine itself.
• SSO-driven dynamic filtering ("deep data security"). Rather than issuing agents direct database credentials, authentication flows through organizational SSO (e.g., Azure AD), which returns role and scope information (such as "HR manager"). The database uses these scopes to strip disallowed rows or columns from result sets before they reach the agent, regardless of which tool or client issued the query.
• Read-only environments as a necessary but insufficient safeguard. Data Guard standby instances eliminate the risk of write-side damage from agent experimentation, but do not substitute for row/column-level controls, since read-only data can still be over-exposed.
• Statistics freshness as an optimizer lever. Because the cost-based optimizer's plan quality depends on data profile statistics, agent-assisted tuning workflows benefit from explicit statistics-generation steps rather than relying on stale metadata.

A notable trade-off is the loss of flexibility: pre-built reporting tools cannot answer questions outside their parameterized scope, reintroducing some of the rigidity that ad hoc NL2SQL was meant to eliminate. This is partially mitigated by the optional SQL-disclosure mechanism, which lets sufficiently authorized agents learn from existing report logic rather than being permanently confined to it.

5. Discussion

These findings suggest that the industry conversation around agentic data access has, in some deployments, prematurely optimized for query-generation sophistication rather than for authorization architecture and context economy. The repeated emphasis on bundling capabilities into few tools indicates that context-window budgets, not model reasoning limits, are an active constraint on tool design even as context windows grow in absolute size - a consequence of the cost and reliability penalties associated with large tool manifests rather than a hard ceiling.

The "deep data security" model also reframes a familiar access-control pattern - row-level security driven by SSO roles - as newly significant in an agentic context, because it is enforced independently of which agent framework or model is issuing the request. This positions the database, rather than the agent or the orchestration layer, as the durable security boundary, which has implications for organizations evaluating multi-agent or multi-vendor deployments: security policy defined once at the data layer persists even as the tooling or model provider changes.

An open question concerns the generalizability of the pre-built-report pattern to less report-centric organizations. The approach presupposes a substantial existing inventory of parameterized reports (SharePoint, BI Publisher) that can be migrated into the MCP layer; organizations without that inventory would face a cold-start cost not addressed in the source material.

6. Conclusion

The central contribution of this analysis is an architectural reframing of agent-database integration: rather than treating NL2SQL as the default access pattern and layering security around it, the examined approach treats curated tools and database-resident authorization as the default, with NL2SQL reserved for contexts where sufficient trust and schema annotation exist. Practically, this suggests that teams building agentic data access should prioritize consolidating existing reporting assets into few, well-scoped MCP tools, enforce row/column security at the database rather than the application or tool layer, and invest in schema annotation before expanding ad hoc query generation. These steps address the reliability and cost problems identified with brute-force schema discovery while preserving a path toward more flexible natural-language querying as trust and documentation mature.

Sources

• Your AI Agent Wants Your Data. Here's How to Lock It Down - Jeff Smith, Oracle - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub