Oracle · MCP ServerOn Oracle, a query tool is a PL/SQL execution engine.
Hand an agent SQL access and you've handed it PL/SQL — a BEGIN…END block can EXECUTE IMMEDIATE arbitrary DDL, and DBMS packages can reach the OS, all from what a SELECT-allowlist reads as one statement. Bytebase moves the MCP server in front of the governance layer: the agent connects to Bytebase, Bytebase connects to Oracle.
Strip away the protocol and a typical Oracle MCP server is a thin wrapper around a connection string. Several things fall out of that, none of them good:
Over-privileged credential
Nobody mints a least-privilege schema per agent before a five-minute setup. They paste the connection they have — often carrying DBA, sometimes AS SYSDBA — and that grant reads every table, drops any object, and can schedule a DBMS_SCHEDULER external job.
A SELECT tool isn't read-only on Oracle
There's no connection-string read-only switch to hide behind. A keyword filter that allows SELECT is bypassed by an anonymous block — BEGIN EXECUTE IMMEDIATE 'DROP TABLE orders'; END; is one statement to the parser — and Oracle DDL implicitly commits, so there's nothing to roll back.
One schema, even with Unified Auditing on
Unified Auditing is real and capable — but it records the database user, and every agent shares the one MCP schema. Which agent ran that DELETE, for which person, after which prompt? The audit trail names the same user every time.
The prompt is an attack surface
The agent reads data, ingests untrusted content, and sends it back out — the lethal trifecta in one shot. A scoped credential can't stop an injection that asks for data it's allowed to read.
Governed MCP in Bytebase
The agent connects to Bytebase, never to Oracle directly.
The agent badges in under its own identity — OAuth and a service account, not a shared connection string — and inherits exactly the permissions that identity carries. A DBA role or SYSDBA on the login behind Bytebase doesn't widen the agent's reach, and because the policy lives in Bytebase, one identity, masking, and audit model covers Enterprise, Standard, Autonomous, and RDS alike — with no Advanced Security option to license.
Per-agent identity
The agent authenticates as itself, not as a connection string. Scope follows the identity — only the projects, databases, and tables its role allows, whatever the privileges on the login behind Bytebase.
Masking with no license, SYSDBA can't bypass
Sensitive values are masked before they reach the model — and unlike Data Redaction, the mask needs no Advanced Security option, isn't lifted by SYS or SYSDBA, and isn't inferred through a WHERE predicate. A restricted SSN comes back as ******.
Writes become proposals
A change doesn't run on send. It opens a Bytebase issue, where SQL review and approval apply just as for a human-authored migration.
Run the support-ticket injection against this and it fizzles — the SELECT runs, masking returns ******, scope caps the reach, DBMS_SCHEDULER isn't on the menu, and the audit log names the identity that tried.
What the agent sees
Same query through MCP. Masked by identity.
The agent calls the query tool over MCP; the result comes back masked for the agent's role, with no change to the table:
// Agent calls the Bytebase MCP "query" tool
{ "sql": "SELECT id, email, ssn FROM customers FETCH FIRST 2 ROWS ONLY" }
// Result returned to the model — masked for this identity
ID EMAIL SSN
---------- --------------------- -------------
1 a******@example.com ***-**-4801
2 m******@example.com ***-**-2210An exempted human running the same query in the SQL Editor sees cleartext. Both reads land in the audit log — under the agent identity and the user it acted for.
Audit with two identities
Every action traces from result to prompt to principal.
Because the agent badges in under its own identity, every query and proposed change is logged twice — under the agent and under the person it acted for. A result traces back to the prompt that triggered it and the principal that ran it.
Unified Auditing can tell you a schema ran a statement; it can't tell two agents apart when they share one login, or name the person an agent acted for. Bytebase records both — the same trail whether the database is on-prem Enterprise, Autonomous, or RDS. When the regulator asks which agent saw which customer record, “we pasted a connection string” is not an answer.
Oracle MCP server questions
Common questions.
- What is an Oracle MCP server?
- An MCP (Model Context Protocol) server exposes Oracle to an AI agent as tools — typically a query tool the model can call. A raw one wraps a connection string and runs whatever SQL or PL/SQL the model asks. A governed one, like Bytebase, sits in front of the governance layer so identity, masking, review, and audit apply to every call.
- Our Oracle MCP server only exposes a SELECT tool — isn't that read-only?
- Not on Oracle. A SELECT-allowlist is bypassed by an anonymous PL/SQL block (BEGIN EXECUTE IMMEDIATE 'DROP TABLE …'; END;), which the parser sees as one statement, and Oracle DDL implicitly commits, so a read-only transaction can't roll it back. Read-only also does nothing about the real risk — masked columns flowing into the model. Bytebase scopes by identity, masks on the read path, and routes any write to review.
- Does it mask sensitive data before the model sees it?
- Yes. Masking runs on the read path at the MCP boundary, so restricted values are transformed before they reach the model. Unlike Data Redaction, it needs no Advanced Security option, isn't lifted by SYS or SYSDBA, and isn't inferred through a WHERE predicate; a masked SSN returns as ******. The model cannot leak what it never received.
- Can the agent write to the database?
- Not directly. A schema or data change opens a Bytebase change issue instead of executing on send, where SQL review and approval apply just as for a human-authored migration. The agent proposes; the pipeline governs.
- Which Oracle deployments are supported?
- Any Oracle Bytebase can connect to — on-prem Enterprise, Standard, and Express, Autonomous Database, Database@AWS, @Azure, @Google Cloud, and AWS RDS for Oracle. Governance runs in Bytebase, in front of the database, so there's no edition or option requirement on the instance.