Diagram showing an AI coding agent writing directly to a production database through a local MCP server, with an arrow around the CI/CD pipeline gate instead of through it

Every schema change your team makes through a pull request gets a review, a CI run, and an approval before it touches production. But a growing share of the schema changes actually happening in your database never go through that gate at all — they’re issued directly by an AI coding agent talking to your database through a local MCP server, on a developer’s laptop, outside version control entirely. The pipeline you built isn’t broken. It’s just no longer the only door into the database.

What’s happening

The Model Context Protocol (MCP) has become the default way coding agents like Claude, Cursor, and Copilot connect to live systems, including databases. Adoption has been extraordinarily fast: over 97 million monthly SDK downloads and more than 10,000 active public servers as of late 2025, with first-class support across every major AI coding tool (Practical DevSecOps, 2026). What hasn’t kept pace is where and how those connections run. Clutch Security’s audit found that 86% of MCP servers run locally on individual developer machines, with only 5% deployed in anything resembling a production or governed environment (cited in Practical DevSecOps, 2026).

That matters specifically for database access because a local MCP server connecting an agent to a database is, functionally, a second write path that sits beside — not inside — your CI/CD pipeline. Your pipeline enforces branch protection, required reviewers, and a CI run before a migration reaches production. A developer’s coding agent with a database MCP tool configured has none of that in between “the agent decided to run a query” and “the query executed.” It doesn’t need a merge, a green check, or a second set of eyes. It needs only a live connection string and a prompt.

This isn’t a hypothetical gap. In July 2025, a development team connected Cursor to a Supabase database using service-role credentials — a common choice made for development speed. A customer support ticket containing an embedded, invisible instruction was reviewed through the agent, which obediently queried the integration tokens table and posted the results back into the public ticket thread (UpGuard, 2026). No pipeline was compromised. No pull request was involved. The agent had direct, privileged database access, and that was the entire attack surface it needed.

Who this affects

This is squarely a database and platform engineering leadership problem first: whoever owns connection strings, service-role credentials, and database firewall rules is the person whose control just got a second, unmonitored path around it. DBAs and data engineering leads who assume “the pipeline is the only way schema changes happen” need to revisit that assumption specifically for any team using agentic coding tools.

Security and compliance teams inherit this next. A schema change or data query that never touched CI/CD also never generated the audit trail your compliance program assumes exists. If your governance model relies on “every production change came through a reviewed PR,” an MCP-connected agent quietly breaks that invariant without anyone deciding to break it.

Individual developers are affected too, often without realizing it: 24-25% of MCP servers in the wild have no authentication configured at all, and of those that do require credentials, only 8.5% use OAuth — the rest lean on static API keys and personal access tokens, 79% of which are passed through environment variables where they’re easy to leak and hard to rotate (Zuplo State of MCP, and Astrix, cited in Practical DevSecOps, 2026). A developer who wired up a database MCP server for convenience six months ago may not remember it’s still running, still authenticated, and still capable of writing to production.

When this becomes urgent

This is already an active risk, not a distant one. The Supabase/Cursor incident happened in mid-2025; by 2026, 88% of organizations reported a confirmed or suspected AI agent incident in the prior year (Gravitee, cited in Practical DevSecOps, 2026). GitGuardian’s 2026 secrets-sprawl research found 24,008 secrets sitting in MCP-related configuration files on public GitHub, with 2,117 of them still valid — meaning a meaningful fraction of these unmonitored database connections are also currently exploitable by anyone who finds the repo (GitGuardian, cited in Practical DevSecOps, 2026).

The next 12-18 months should make this worse before governance catches up. Only about 23% of organizations currently have a formal AI-agent identity strategy, and only 14.4% of agents reach production with full security approval (CSA/Strata and related survey data, cited in Practical DevSecOps, 2026). Meanwhile agent adoption in day-to-day development keeps climbing, and MCP server counts keep growing far faster than any registry’s ability to audit them. Gartner has already tied the coming wave of GenAI security incidents specifically to MCP-mediated access, projecting a sharp rise in agent-related breaches through 2028-2029. The gap between “agents can connect directly to databases” and “someone is watching when they do” is not closing on its own; it needs a deliberate intervention, and most teams haven’t made one yet.

How it plays out technically

The mechanics are simpler than most security incidents, which is part of what makes this risk easy to underestimate. A developer installs a database MCP server — often one of dozens of community-built connectors for Postgres, MySQL, SQL Server, or a managed platform like Supabase or Neon — and points their coding agent at it with a connection string that has broad read/write privileges, frequently the same service-role or admin credential used by the application itself. This setup happens once, takes minutes, and from then on the agent can query, insert, update, and in many configurations, alter schema, entirely through natural-language prompts.

None of this activity touches git. There’s no branch, no commit, no PR, no CI run, no required reviewer — the controls your team built specifically to govern schema and data changes simply don’t apply, because they’re triggered by version-control events, and this path never generates one. The change lands in the database the same way a DBA running a query directly in a SQL client would, except now the human is a step removed: they’re reviewing the agent’s proposed action, if they review it at all, rather than authoring the SQL themselves.

Two separate categories of risk compound here. The first is unreviewed change: an agent asked to “fix the slow query” or “clean up test data” can run a DDL statement or a bulk delete that would have been caught by a migration review, but wasn’t, because the medium it traveled through has no review step. This connects directly to the schema-change approval queue gap already documented for parallel agents proposing PRs — except an MCP-connected agent doesn’t even need to propose a PR to make the change; it just makes it. The second is the credential and prompt-injection risk illustrated by the Supabase incident: any untrusted text the agent processes — a support ticket, a GitHub issue, a document — is a potential vector for an attacker to redirect that same direct database access toward exfiltration, using permissions that were provisioned for a developer’s convenience, not for an adversary’s benefit.

Command injection and path traversal compound the exposure at the protocol layer itself: independent scans found 43% of tested MCP servers vulnerable to command injection and 82% of file-operation-capable servers prone to path traversal across more than 2,600 implementations (Equixly and Endor Labs, cited in Practical DevSecOps, 2026). A database-connected MCP server doesn’t have to be malicious to be dangerous — it only has to be unpatched, misconfigured, or connected with more privilege than the task requires.

Actions to take now

  1. Inventory every MCP server with database access this week. Check developer machines, CI runners, and any agent framework configuration for connection strings pointed at production or staging databases. You cannot govern what you haven’t found, and most teams currently have no list at all.

  2. Kill shared service-role credentials in MCP configs immediately. Any database MCP server authenticated with the same broad credential your application backend uses is a standing risk with no upside. Issue narrowly scoped, agent-specific credentials with the minimum privilege the task actually requires — this mirrors the same discipline covered in auditing AI agent credentials and connections, applied specifically to the MCP layer.

  3. Route database-write MCP tools through a proxy that logs and rate-limits, not a direct connection. A database firewall or query gateway sitting between the MCP server and the database — the same pattern described for AI agent database firewalls — turns an invisible write path into an observable, auditable one, even when it still bypasses git.

  4. Require human approval for any DDL or bulk-write operation issued through an MCP connection, full stop. Read-only or narrowly-scoped query access is a reasonable convenience; unattended schema changes or bulk deletes issued outside your pipeline are not. Configure the proxy or connector layer to hold these for explicit sign-off rather than trusting agent judgment alone.

  5. Treat MCP server installation as a security-reviewed action, not a developer convenience. Given that only 8.5% of servers use OAuth and a quarter have no authentication at all, don’t assume a community connector is safe by default. Require MCP servers touching any database to come from a vetted, internally-approved list, and block auto-approval settings that let an agent add new server connections without review.

  6. Rotate and monitor for leaked MCP credentials the same way you’d treat any other secret sprawl. Run a secrets scan specifically targeting MCP configuration files across your repos — GitGuardian’s research shows this is a real, not theoretical, source of live, valid credentials sitting in public view.

  7. Build MCP-specific scenarios into your incident response plan. If your playbook doesn’t already include “an AI agent’s database MCP connection was used for unauthorized access or exfiltration,” add it now. None of the documented MCP incidents to date triggered a traditional SIEM alert, so detection has to be designed in deliberately rather than assumed.

  8. Extend your governance model, don’t just extend your pipeline. The long-term fix isn’t forcing every MCP interaction through git — that’s not how these tools are used day to day. It’s building parallel, equally rigorous controls (approval, logging, credential scoping) for the direct-access path, so “went through CI/CD” and “went through an agent’s MCP connection” carry the same level of assurance instead of one being governed and the other invisible.

Key takeaways

  • 86% of MCP servers, including database connectors, run locally on developer machines rather than in any governed environment, creating a write path to production that sits entirely outside CI/CD.
  • A real 2025 incident — an AI coding agent with direct Supabase database access leaking integration tokens after processing a poisoned support ticket — shows this risk is already active, not hypothetical.
  • Only 8.5% of MCP servers use OAuth and roughly a quarter have no authentication at all, meaning the direct-access path is frequently also the least-secured path into the database.
  • This isn’t primarily a code-review problem; it’s a governance problem, because the controls teams built around pull requests and pipelines simply don’t trigger on agent-to-database MCP traffic.
  • Closing the gap requires inventorying MCP database access, scoping credentials narrowly, proxying writes through an auditable gateway, and requiring human approval for DDL and bulk operations issued outside the pipeline.

If you don’t know how many AI agents have a live connection string to your production database right now, that’s worth finding out before an attacker does. Get in touch if you want help mapping and locking down the access paths your CI/CD pipeline was never designed to see.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.