The MySQL MCP server lets Claude, Cursor, ChatGPT, and AI agents query your MySQL database in plain English. There's no production-grade official server — here's the fragmented landscape, the real risks, and how to govern agent access with column-level redaction at the MCP layer.
.webp)
oracle/mcp repo but labels it "not intended for production use… a proof of concept." The real landscape is community servers (designcomputer, benborla), vendor-managed options (PlanetScale, Google Cloud SQL via MCP Toolbox), and multi-DB proxies (DBHub).FILE privilege turns a query into a filesystem read/write; and a server that omits the database name can read across tenant schemas.The MySQL MCP server is a Model Context Protocol implementation that exposes a MySQL (or MariaDB) database to AI agents as a set of standardized tools — listing tables, reading schemas, sampling rows, and executing SQL. Once connected, an agent like Claude can query your database in natural language.
Unlike Postgres or Redshift, there is no single canonical, production-blessed server — and that shapes everything:
designcomputer/mysql_mcp_server exposes execute_sql, get_schema_info, and get_table_sample; benborla/mcp-server-mysql is read-only by default with writes behind opt-in flags. Both are popular and both hold your DB credentials.oracle/mcp is HeatWave/AI-oriented and explicitly not for production.--readonly mode.From the user's seat, the agent suddenly understands the database. From the security seat, you've handed query access — and, depending on the server, write access — to whatever MySQL user you wired in, through code you may not have audited.
That's the value. It's also exactly where a control layer belongs.
Point an agent at a MySQL MCP server and it works the database directly, turning plain-English requests into SQL against the tables the connected user can touch. Depending on the server, it can:
execute_sql on some community servers runs SELECT and DML, governed only by the MySQL user's grants.FILE privilege, LOAD_FILE() and SELECT … INTO OUTFILE read and write server files within secure_file_priv.Every one of those runs through MySQL's engine and the privileges of the user you connected — which is what makes it useful, and exactly why the regulated data those queries return needs an inspection layer in the tool-call path.
MySQL's ubiquity plus a fragmented server ecosystem creates a distinct risk profile. Five categories every healthcare, fintech, and enterprise security team should price in:
1. Supply-chain trust — you're running unvetted code with DB credentials. With no production-grade first-party server, teams pip/npm install a community server and hand it production database credentials. The server becomes a privileged, third-party participant in your data path that you may never have security-reviewed.
2. SQL injection through string-built queries. Several community servers construct SQL from interpolated input; designcomputer had to add identifier validation (^[a-zA-Z0-9_$]+$) precisely because the naive pattern invites injection. A malformed or adversarial prompt can reshape the query.
3. The FILE privilege is a filesystem escape hatch. This is MySQL-specific. A connected user with FILE can LOAD_FILE() to read server files or SELECT … INTO OUTFILE / LOAD DATA INFILE to write them — turning a "database" tool into a file read/write and exfiltration path, bounded only by secure_file_priv.
4. Multi-tenant cross-schema reach. Both designcomputer and benborla enter "multi-database mode" simply by omitting the database name — so one connection can read across every schema the user can see. On a shared MySQL host, that's cross-tenant exposure from a single misconfiguration.
5. There is no column filter in the path. Whatever the connected user can read, a wide SELECT returns — plaintext PII, financial data, secrets in config tables — straight into the model's context window, far more than any human would copy by hand.
The DLP a company already runs doesn't sit in the SQL path between an agent and MySQL. The query result goes straight from the database into the AI agent's context window. That reach is precisely why each agent's access to MySQL must be governed — regardless of which server you chose: controlled (which tables and columns it can touch, and whether it can write or reach the filesystem), the sensitive data it returns protected, and every query audited. That is where Strac MySQL MCP DLP lives.
Strac's MySQL MCP DLP is one consistent governance layer that sits between AI agents and whichever MySQL MCP server you run. Strac governs every query: 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:
orders and accounts but never payment_methods or secrets. Writes (UPDATE / DELETE / INSERT), file operations (OUTFILE / LOAD_FILE), and cross-schema reach are blocked or routed for approval — so a misread prompt can't mutate production or read the filesystem.ssn returns masked, a card_number tokenized, a secret vaulted behind a short-lived retrieval link — the agent still gets a usable result set, but the regulated values never enter the model context.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 query surface. Strac's native MySQL 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 MySQL, 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 MySQL DLP includes:
TEXT notes column holding clinical data or a config table hiding tokens 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 MySQL MCP query routed through Strac, applied column-by-column to the returned rows.
Setup is agentless and takes under 10 minutes.
root, and without the FILE privilege — consistent with the community servers' own security guidance to use a minimal-privilege user and require SSL.json
"mcpServers": {
"mysql": {
"url": "https://mcp.strac.io/mysql",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac MySQL MCP DLP control produces evidence mapped to every major compliance framework.
For the broader AI-data-governance program this sits inside, see AI DLP.
Not a production-grade one. Oracle ships a MySQL MCP server in its oracle/mcp repo, but it explicitly says it's "not intended for production use… a proof of concept," and it's oriented toward HeatWave/MySQL-AI rather than plain CRUD. In practice, teams use community servers (designcomputer, benborla), vendor-managed options (PlanetScale, Google Cloud SQL via MCP Toolbox), or a multi-DB proxy like DBHub. The lack of a blessed first-party server is exactly why a consistent governance layer in front matters.
It depends on your setup, and each has different defaults. benborla is read-only by default with writes behind opt-in flags; designcomputer's execute_sql runs SELECT and DML governed only by the MySQL user's grants; DBHub has an explicit --readonly mode; PlanetScale uses OAuth scopes and blocks UPDATE/DELETE without a WHERE. None of them redact regulated columns from the rows they return. So whichever you pick, connect a minimal-privilege user (never root, no FILE privilege), require SSL, and put a DLP layer like Strac in front so the data itself is inspected, not just the privileges.
Yes — the same thing. The MCP specification says server; Claude and Cursor surface it as the MySQL connector. Both let an agent query your tables, and Strac's MySQL MCP connector redacts regulated columns at the tool-call boundary regardless of the label or which underlying server you run.
Not by itself. You're typically running community code that holds your DB credentials, defaults vary from read-only to full DML, the FILE privilege can read and write server files, and a server that omits the database name can read across schemas. For production use against regulated data you need an MCP-layer control like Strac MySQL MCP DLP that scopes table and column access, blocks writes and file operations, and redacts sensitive columns before any row reaches the model.
FILE privilege risk with MCP?It's a MySQL-specific escape hatch. A connected user with the FILE privilege can use LOAD_FILE() to read files on the database server, and SELECT … INTO OUTFILE or LOAD DATA INFILE to write them — within whatever secure_file_priv allows. Through an MCP server, that turns a "database query" tool into a filesystem read/write and exfiltration path. Strac blocks file operations at the MCP layer, and the right baseline is to never grant the agent's MySQL user the FILE privilege in the first place.
Yes. Strac inspects the SQL before it executes. Write statements (UPDATE, DELETE, INSERT, DDL) and file operations can be blocked outright, allowed only on specific tables, or routed for human approval — so even a write-enabled community server can't let a misread prompt mutate production.
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 JSON columns.
Under 10 minutes for the first database. Connect Strac with a least-privilege MySQL 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 MySQL MCP server is fast becoming the way AI agents read — and often write — your MySQL data, but the ecosystem is fragmented and there's no production-grade official server to standardize on. That leaves teams running unvetted community code with production credentials, defaults that range from read-only to destructive, and MySQL-specific escape hatches like the FILE privilege. Running MySQL 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 MySQL MCP DLP gives you one control plane in front of whichever server you run — see every query, scope every agent, block writes and file operations, protect every regulated column, prove every call — so your team can use MySQL with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — MySQL MCP in production, book a 30-minute demo. We'll walk through the server choices, the least-privilege setup, the FILE-privilege risk, 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)
