The Oracle MCP server (SQLcl and Autonomous AI Database) lets Claude, Cursor, ChatGPT, and AI agents query your Oracle database in plain English. Here's the setup, the PL/SQL egress and inherited-DBA risks, and how to govern agent access with column-level redaction at the MCP layer.
.webp)
oracle/mcp, explicitly for exploration, not production.run-sql tool runs SQL and PL/SQL as the connected user; it reuses your saved SQLcl connections, so the agent inherits whatever credential (up to DBA) the human stored; and PL/SQL packages like UTL_FILE and UTL_HTTP turn a "database" query into file and network egress.The Oracle MCP server is a Model Context Protocol implementation that exposes an Oracle Database to AI agents as a set of standardized tools — connecting to a database, inspecting schema metadata, and running SQL and PL/SQL. There are three things people mean by it, and the distinction matters:
run-sql), run native SQLcl commands (run-sqlcl), and inspect schema metadata. Crucially, it reuses SQLcl's saved connections — including their stored credentials.oracle/mcp reference repo. Oracle-maintained sample code, explicitly "not intended for production use."oracle-mcp-server and others) with their own defaults — one notable community server is read-only by default, unlike SQLcl.From the developer's seat, the agent suddenly understands the database — it answers questions in SQL and even runs PL/SQL blocks. From the security seat, you've potentially handed an AI client the keys to the most critical database in the enterprise.
That's the value. It's also exactly where a control layer belongs.
Point an agent at the SQLcl MCP server and it works the database directly, running statements as the connected user. In practice it can:
run-sql executes anonymous PL/SQL blocks, so the agent can do far more than read a table.Every one of those runs through Oracle's engine and the privileges of the connection you (or a colleague) saved — which is what makes it powerful, and exactly why the regulated data those statements touch needs an inspection layer in the tool-call path.
Oracle's depth is its danger. Five categories every healthcare, fintech, and enterprise security team should price in:
1. It inherits the saved connection's privileges — often DBA. The SQLcl MCP server reuses SQLcl's named connections and their stored credentials. If a developer saved a SYSTEM or DBA connection, the agent silently inherits full DBA rights. The agent's power is whatever the human's saved connection had, with no separate, narrower credential in between.
2. PL/SQL is a file and network egress path. This is Oracle-specific and serious. Built-in packages — UTL_FILE (read/write OS files), UTL_HTTP / UTL_TCP / UTL_SMTP (make outbound network calls), DBMS_SCHEDULER, DBMS_CLOUD — mean a statement run through the MCP server can exfiltrate data over HTTP or email, or write to the filesystem. A "database query" tool becomes a general-purpose egress tool.
3. Not read-only by default. Unlike AWS's Redshift server, the SQLcl MCP server doesn't default to read-only — run-sql runs whatever the connected user can, including DML and DDL. The only brake is the database privileges of that connection.
4. Crown-jewel blast radius. Oracle underpins ERP, E-Business Suite, and Fusion — HR, financials, and the most sensitive enterprise records. The data an Oracle agent can reach is frequently the highest-value, most-regulated data the company has.
5. Complex controls are easy to misconfigure. Oracle's own access model — roles, Virtual Private Database, Label Security, Data Redaction — is powerful but intricate, and a broadly-privileged agent connection can sail past protections that assume a constrained application user. Oracle's own guidance warns that giving an LLM database access "introduces significant security risks" and that you "might inadvertently expose unintended tables or sensitive details."
Oracle's documentation is unusually direct about this: "Do not grant LLMs direct access to production databases… use a sanitized, read-only replica." That's sound advice — and a governance layer is what lets you enforce it without standing up a separate replica for every agent. The DLP a company already runs doesn't sit in the SQL/PL-SQL path between an agent and Oracle. That reach is precisely why each agent's access to Oracle must be governed: controlled (which schemas and columns it can touch, and whether it can write or run risky PL/SQL), the sensitive data it returns protected, and every statement audited. That is where Strac Oracle MCP DLP lives.
Strac's Oracle MCP DLP is the governance layer that sits between AI agents and the Oracle MCP server. Strac governs every statement: it sees exactly what each agent runs, controls what it can reach and do, protects the sensitive columns it touches, and logs every call as audit evidence. In-policy, non-sensitive queries flow through untouched.
What this looks like in practice, mapped to See / Control / Protect / Prove:
FINANCE.INVOICES but never HR.SALARIES or a secrets table. Writes (UPDATE / DELETE / INSERT), DDL, and risky PL/SQL packages (UTL_FILE, UTL_HTTP, DBMS_SCHEDULER) are blocked or routed for approval — so a misread prompt can't mutate production or exfiltrate over the network.SSN returns masked, a card_number tokenized, a credential vaulted.The same Strac MCP DLP layer covers your other databases and warehouses — Postgres MCP, Snowflake MCP, Databricks MCP, and BigQuery MCP — one control plane across every place AI agents reach your regulated data. See the MCP DLP pillar and the broader MCP data security discipline for the full model.
MCP DLP governs the AI-agent statement surface. Strac's native Oracle DLP governs the data at rest — the same database, but discovered and classified so you know where the regulated columns are before any agent ever queries them. This is DSPM for Oracle, and most teams run both: native discovery to map and label the sensitive data, MCP DLP to govern how agents reach it.
What Strac's native Oracle DLP includes:
CLOB notes column holding clinical data or a config table hiding secrets is caughtFor the broader practice this sits inside, see DSPM for AI. For every SaaS, cloud, database, and endpoint surface Strac covers, see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — customer emails, identifiers, and credit card numbers tokenized inline before the model received them. The same inspection pattern runs on every Oracle MCP statement routed through Strac, applied column-by-column to the returned rows.
Setup is agentless and takes under 10 minutes.
SYSTEM or a DBA role, and without the PL/SQL egress packages granted — so the agent's reach is bounded from the start rather than inherited from a saved DBA connection.json
"mcpServers": {
"oracle": {
"url": "https://mcp.strac.io/oracle",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Oracle MCP DLP control produces evidence mapped to every major compliance framework.
For the broader AI-data-governance program this sits inside, see AI DLP.
Oracle ships two: the SQLcl MCP server built into SQLcl, and the managed Autonomous AI Database MCP server for Oracle's cloud (which enforces RBAC, VPD, and audit server-side). The SQLcl one is the common developer path, but it's not read-only by default and reuses your saved SQLcl connections — so it inherits whatever privilege the stored credential had. Oracle's own advice is blunt: don't give LLMs direct access to production; use a sanitized, read-only replica. The practical alternative is a least-privilege connection plus a DLP layer like Strac that inspects the data and blocks risky operations, so you get the safety without a replica per agent.
Yes — the same thing. The MCP specification says server; Claude and Cursor surface it as the Oracle connector. Both let an agent query your schemas, and Strac's Oracle MCP connector redacts regulated columns at the tool-call boundary regardless of the label.
The SQLcl MCP server is a Model Context Protocol server built into Oracle SQLcl (from SQLcl 25.2, mid-2025). It lets AI agents connect to an Oracle database using SQLcl's saved connections and run SQL and PL/SQL through standardized tool calls — querying tables, switching connections, and inspecting schema metadata. Because it runs PL/SQL and isn't read-only by default, it needs a governance layer for any regulated data.
Three reasons specific to Oracle. First, the SQLcl server inherits the privileges of the saved connection — often a DBA account. Second, PL/SQL packages like UTL_FILE and UTL_HTTP let a statement read/write files and make outbound network calls, turning a query tool into an egress path. Third, Oracle typically holds the most critical enterprise data (ERP, financials, HR). Together that's a higher blast radius than a single-purpose SQL database, which is why Oracle itself recommends a sanitized read-only replica.
Yes. Oracle Data Redaction and Virtual Private Database assume a constrained application user; a DBA-level agent connection can return data those controls would have masked. Strac inspects the actual rows returned at the MCP layer and redacts, masks, or tokenizes regulated values independent of the database-native controls — so the protection holds even when a privileged connection bypasses Oracle's own redaction.
Yes. Strac inspects the statement before it executes. Writes (UPDATE, DELETE, INSERT), DDL, and risky PL/SQL packages (UTL_FILE, UTL_HTTP, UTL_SMTP, DBMS_SCHEDULER) can be blocked outright, allowed only on specific schemas, or routed for human approval — so even a non-read-only server can't let a misread prompt mutate production or exfiltrate over the network.
PII (SSN, driver's license, passport, address, phone, email), PHI (clinical notes, MRN co-occurrence, ICD-10 codes adjacent to identifiers, lab values), PCI (full and partial card numbers via Luhn check), credentials (API keys, AWS / GCP / Azure access keys, OAuth tokens, JWTs — 48+ patterns), and custom detectors trained on your internal classifications. Detection runs column-by-column across the returned rows, including text inside CLOB and JSON columns.
Under 10 minutes for the first database. Connect Strac with a least-privilege Oracle user, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No application changes, no schema migration, no re-grant.
The Oracle MCP server is fast becoming the way AI agents read — and run PL/SQL against — the most critical database in the enterprise. The SQLcl server isn't read-only by default, inherits whatever privilege your saved connection had, and exposes PL/SQL packages that can read files and call out over the network. Oracle thinks the risk is serious enough to tell you not to point an LLM at production at all. Running Oracle MCP in 2026 without an MCP-layer governance control isn't a question of if the first incident reaches your security team; it's when.
Strac Oracle MCP DLP gives you the control plane — see every statement, scope every agent, block writes and risky PL/SQL, protect every regulated column, prove every call — so your team can use Oracle with Claude, Cursor, ChatGPT, and any future AI client without standing up a replica for each one.
If you are running — or about to run — Oracle MCP in production, book a 30-minute demo. We'll walk through the SQLcl-vs-Autonomous decision, the inherited-connection and PL/SQL-egress risks, the policy templates, and a deployment plan for your specific database and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-platform deep dives: Postgres MCP, Snowflake MCP, Databricks MCP, BigQuery MCP.
.avif){kind=icon}
.gif)
