Natural language to SQL with MCP changes database access

At a glance

What this is: Supabase’s MCP server turns natural language into live SQL queries, showing how conversational access can become the interface between agents and databases.

Why it matters: This matters because IAM and platform teams must treat MCP-connected database access as an identity and authorisation problem, not just a developer convenience.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read WorkOS's recap of Supabase natural-language SQL through MCP

Context

MCP is becoming a practical access layer, not just a protocol demo layer. In this case, a coding agent can turn plain language into live SQL that reaches authentication checks, inventory data, and operational queries through the Supabase MCP server. That changes the governance question from how fast a query runs to how data access is authorised, scoped, and logged when the requester is an agent rather than a person.

For identity teams, the key issue is that conversational access hides the boundary between intent and execution. The developer or agent can describe a need in natural language, but the database still receives a real query with real permissions. That makes MCP server governance a workload identity and secrets problem as much as a developer-experience problem.

Key questions

Q: How should security teams govern MCP access to production databases?

A: Security teams should treat MCP access as privileged workload access, not a convenience layer. The server should expose only the specific database actions a use case needs, and each action should map to a named service identity with logging, ownership, and review. If the MCP path can reach production data, it needs the same scoping discipline as any other NHI.

Q: Why do MCP servers increase NHI governance risk?

A: MCP servers increase risk when they hide broad database access behind a simple conversational interface. The protocol makes it easier for agents to reach real systems, but the security outcome still depends on secret handling, tool scoping, and the permissions of the underlying workload identity. A weak identity model turns convenience into overexposure.

Q: What breaks when MCP credentials are hard coded?

A: Hard-coded credentials break lifecycle control. They are difficult to scope, hard to rotate, and easy to reuse across tools or environments, which means the same secret can outlive the team or use case that created it. In an MCP context, that creates a standing access path that is far broader than the interface suggests.

Q: How do IAM teams reduce risk when agents query data through MCP?

A: IAM teams should require explicit ownership for every MCP-connected service account, enforce least privilege at the database layer, and review what data the agent can reach, not just which tools it can call. They should also pair access reviews with prompt and query logging so they can prove what actually happened.

Technical breakdown

How MCP turns natural language into executable SQL

MCP sits between an AI client and the tools or data sources it can reach. In this demo, the client converts a human-language request into a structured action that the server can translate into SQL and execute against the database. The important point is that the protocol does not make the query safe by itself. Safety depends on the database permissions, the tool permissions exposed by the MCP server, and whether the session identity is constrained to the minimum data scope needed for the task. If those layers are loose, the protocol becomes a convenience layer over broad access rather than a control plane for governed access.

Practical implication: scope MCP tool permissions to specific database operations and review the underlying service identity before exposing conversational queries.

Why authentication checks become part of the query path

When the demo asks whether a user is authenticated, the MCP server is not just generating SQL syntax. It is translating an identity question into a data-backed control decision, which means the correctness of the answer depends on how authentication state, session context, and database access are wired together. In practice, this creates a tight coupling between IAM and data access logic. If the agent can query auth state but the database identity is over-privileged, the system may answer accurately while still exposing more data than the request warrants. The protocol therefore inherits every weakness in the upstream identity model.

Practical implication: validate that auth-state queries are read-only, narrowly scoped, and separated from any write-capable database identity.

Why SQL is a useful but risky agent interface

SQL is predictable enough for agents to generate reliably, which is why it works so well as a machine-readable interface. But that same predictability makes it attractive for overreach if the agent can compose broader queries than a human would normally write. The issue is not that SQL is unsafe. The issue is that a natural-language front end can obscure whether the underlying request is bounded, approved, and traceable. For NHI governance, the real control question is whether the MCP server exposes a tightly defined execution surface or a general-purpose pathway into production data.

Practical implication: treat natural-language SQL as a privileged execution channel and put approval, logging, and query guardrails around it.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Natural-language SQL creates an identity boundary problem, not just a query problem. Once an AI client can convert conversational intent into executable database access, the security question shifts to who can originate that intent and what identity is carrying it. That is a governance problem for MCP servers, service accounts, and workload credentials at the same time. Practitioners should treat conversational database access as a controlled execution surface, not a chat feature.

Hard-coded secrets are the failure mode that makes MCP convenience dangerous. If the MCP server depends on embedded credentials or broad database tokens, the protocol becomes an efficient path to overreach. A conversational interface then sits on top of a trust model that was never designed for dynamic tool use. The implication is straightforward: teams need to know whether the MCP layer is masking old secrets sprawl or actually reducing it.

Identity blast radius: the real risk is not the query itself but how far one MCP-connected identity can move once natural language becomes an execution trigger. If a single service identity can read, search, and act across multiple data domains, the blast radius expands faster than most access reviews can track. That makes least privilege a runtime property, not a provisioning checkbox. Practitioners should audit the reachable data surface, not just the tool list.

MCP adoption is pulling NHI governance into developer workflows. The protocol makes workload identity, secrets handling, and tool scoping part of everyday application development rather than a back-office control. That narrows the gap between platform engineering and IAM, which is where the discipline now has to operate. The practical conclusion is that identity teams need to govern MCP servers the same way they govern other privileged machine identities.

Access scoping matters more than interface polish. A polished natural-language layer can make data access feel benign even when the underlying permissions are broad. The field should read this as a reminder that usability often outruns governance, especially when AI intermediates the request. Practitioners should make scoping and auditability visible before they make the interface conversational.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which explains why conversational access so often outruns governance.
• For a wider view of agentic risk, 80% of organisations report AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.

What this signals

MCP adoption is collapsing the distance between application development and identity governance. As natural-language interfaces become real execution paths, platform teams will need to prove that service accounts, secrets, and data scopes are managed as tightly as user access. Conversational execution surface: that is the emerging control point, and it will matter as much as any API gateway or query proxy.

The practical signal for IAM and security architects is that auditability must move upstream. If the request arrives in natural language and leaves as SQL, you need evidence for both the intent and the execution, plus a clear ownership chain for the workload identity behind the query. That is where MCP governance will separate controlled adoption from shadow AI sprawl. See also Ultimate Guide to NHIs , Key Research and Survey Results and OWASP Agentic AI Top 10.

For practitioners

• Inventory every MCP-connected data path Map which databases, auth checks, and operational systems are reachable through the MCP server, then tie each path to a named service identity and an owner. This should include read-only and write-capable operations.
• Scope tool permissions to narrow database actions Limit the MCP server to the smallest set of SQL operations needed for each use case, and separate lookup, auth, and mutation capabilities so a conversational client cannot drift into broader access.
• Rotate and replace embedded credentials Search configuration files for hard-coded values, remove static secrets from the MCP layer, and move database access to short-lived credentials with explicit lifecycle ownership.
• Add query logging and review to conversational access Log the originating identity, natural-language prompt, generated SQL, and target data domain so reviewers can reconstruct how an agent reached a result and whether the query exceeded intent.
• Use your lifecycle guide for machine identities Apply joiner-mover-leaver and access review discipline to the service accounts behind MCP rather than treating them as infrastructure defaults. The reachable data surface should be recertified on a fixed cadence.

Key takeaways

• MCP-connected natural-language queries turn database access into an identity governance problem, because the protocol is only as safe as the service account and scopes behind it.
• Hard-coded credentials and weak tool scoping are the practical failure modes that let conversational access become overbroad access.
• Teams should govern MCP servers like privileged machine identities, with explicit ownership, logging, and lifecycle review for every reachable data path.

Key terms

• MCP server: An MCP server is the component that exposes tools and data sources to an AI client through the Model Context Protocol. In practice, it becomes an execution boundary for machine requests, so its permissions, secrets, and logging determine whether the connection is governed or merely convenient.
• Workload identity: Workload identity is the identity assigned to software, services, or agents when they access resources without a human user behind them. It should be scoped to a specific purpose, issued with clear ownership, and reviewed throughout its lifecycle because it can reach real systems with real privileges.
• Tool scoping: Tool scoping is the process of limiting which actions an AI client or service account can invoke through a protocol or platform. It is the control that prevents conversational access from becoming broad execution, and it should align with the smallest set of operations needed for the task.
• Hard-coded secret: A hard-coded secret is a credential embedded directly in code or configuration instead of being managed in a secure secrets system. It creates persistence, reuse risk, and weak lifecycle control, which is especially dangerous when the credential grants access to a protocol-driven execution path.

Deepen your knowledge

MCP server governance and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are bringing conversational access into production systems, it is worth exploring.

This post draws on content published by WorkOS: Supabase: Natural Language to SQL, Holiday Edition. Read the original.