Your databases in Claude, ChatGPT, and Cursor, with the governance intact
In April, PocketOS founder Jer Crane posted that a Claude-powered Cursor agent destroyed his production database in nine seconds. The agent hit a credential mismatch mid-task, decided on its own to clear the obstruction, found an infrastructure token, and used it to delete the volume the database lived on, backups included. The team had written rules telling the agent never to guess and never to run destructive commands unasked. Afterward, the agent acknowledged it had broken both. An instruction is only a request. QueryDesk would have stopped this. The agent could act because it held a credential with direct access, and nothing stood between its decision and the execution. With QueryDesk, an AI agent never gets direct access to the database. It reaches data only through QueryDesk, so engineers still get the data they need without handing the AI a credential it could misuse.
QueryDesk doesn’t fix this by making the model safer. It makes the dangerous part subject to human review. Read-only queries run right away and return their results. Writes wait for a person to review the SQL and approve it. The engineer keeps the assistant, the schema awareness, and the speed on everything that can’t hurt them. A delete like the one at PocketOS never runs on its own. QueryDesk blocks it and holds it until an approver reviews the request.
Your engineers already work with AI agents like Claude, ChatGPT, and Cursor, and they want those agents to pull up the data they need without switching to a SQL client. That’s a reasonable ask. The question is whether an AI model touching your database is governed exactly like a person touching it, or becomes a privileged side channel around every control you built.
QueryDesk’s MCP server answers that by making the AI model inherit the querying user’s permissions and nothing more. The same policy engine, the same masking, and the same approvals apply whether a person typed the SQL or a model composed it, and the audit log shows which one did. That’s deliberate. QueryDesk governs the query, not the session or the person typing it, because the query is what touches the data.
What it is
QueryDesk exposes your governed databases over an MCP endpoint. Any MCP-compatible client (Claude, ChatGPT, Cursor, and others) connects to that endpoint and gets a catalog of tools for working with the databases that the user is allowed to access.
The important word is governed. The MCP server is not a new path to the data that skips the policy engine. It is another entry point to the same engine. A query that arrives over MCP is evaluated identically to one that arrives from the web UI or from DataGrip pointed at the QueryDesk proxy.
Auth: the AI acts as a person or a service account
An AI client connects in one of two ways, and either way it gets no more access than the identity behind it.
As a person, through OAuth. When an engineer connects Claude, ChatGPT, or Cursor, the client signs in through your SSO and acts as that engineer. It can see and do exactly what they can, through the same policy engine, and it gets nothing extra for being an AI. If the engineer can’t read the customers table, neither can their agent.
As a service account, with a token. Some agents run on their own, such as a scheduled job or a support bot. For those, an admin creates a service account and gives the agent its token. The admin assigns the account its roles and picks which tools it can use. The token can expire, and the admin can rotate or revoke it at any time. A service account can submit a write but never approve one, because only a person can approve a query. Its queries appear in the audit log under the service account’s name.
The tool catalog
Once connected, the client sees a catalog of tools. Every tool goes through the same policy engine, so none of them is a way around it.
-
Schema discovery. The AI reads the table and column structure of the databases the user can access, so the SQL it writes uses your actual schema instead of guessed names. Nobody pastes DDL into a chat window.
-
Governed query execution. The AI submits SQL, and QueryDesk applies your policy before anything runs. On a read-only credential, results come back right away, and columns holding sensitive data such as PII can be protected so that data never leaves the database. On a credential that requires review, the query waits until a person approves the exact SQL. The AI gets fast answers, and nothing risky runs without a person seeing it first. Every query is logged under the person or service account behind it and marked as coming from an AI.
-
Saved queries. Run a query from the organization’s saved query library, so the AI reuses a known-good statement instead of writing a new one.
-
Audit log search. Ask the AI what ran against a table last week, or what you ran yesterday, and it searches the audit log for you. Each record has the SQL, who ran it, and who approved it, so retracing an incident or answering an auditor takes one question instead of a log export.
What a governed AI query actually looks like
Say an engineer asks their AI client to find why a specific customer’s checkout is failing. The client uses schema discovery to understand the tables, then composes a SELECT against the orders and subscriptions tables. That read runs under a zero-review read-only credential, so it returns without review, with the email column coming back as *** because that credential carries a data-protection policy. The AI narrows the problem to a subscription row with a null where the billing code expects a value, and composes an UPDATE to fix it.
The AI wrote the UPDATE, but it can’t run it on its own. The change waits for review, an approver sees the exact SQL, and it runs only after they approve. The audit log records the engineer, the statement, the approver, and the result. If you later ask “who changed this row, and who signed off,” the answer is one record. It shows that the query came from an AI, and that the same policies applied to it as to a person.
Setup
Setup is short because OAuth handles identity:
-
Point your MCP client at the QueryDesk /mcp endpoint.
-
Complete the OAuth flow. The client registers itself, and your SSO signs in the person using it.
-
The client now sees the tool catalog scoped to that user’s permissions. There is nothing else to provision.
For an agent that runs on its own, skip the OAuth step. An admin creates a service account, picks its tools, and gives the agent its token.
From there, the developer works in their AI client as they already do, and every database action it takes is subject to the same policy, masking, approval, and audit as if it had been run by hand.
Tighter limits for AI
Inheriting a user’s permissions does not make the agent trustworthy.
The MCP server guarantees that the AI is not a privileged side channel. It is another authenticated identity, held to the same rules as a person. Anything that needs review waits for a human, and sensitive columns can be masked before they leave the database. That guarantee is real, and it is narrow.
Governing the AI doesn’t stop at parity with the user behind it. QueryDesk also has controls that only apply when the caller is an AI: data protection policies scoped specifically to AI-issued queries, a hard cap on how many rows any AI-composed query can return, and an explicit allowlist of which databases and credentials an AI is even permitted to reach. These settings can make the AI’s limits tighter than the person’s, never looser. For the full set of AI controls, see Let AI query production without building it a side channel.
This is database access over MCP, not a general AI platform. QueryDesk hands your governed databases to the AI clients your team already uses. It is not trying to be your agent framework, and every tool in the catalog ends in a governed query against a database.
If you want to see what your own databases look like inside Claude, ChatGPT, or Cursor with the governance intact, the 14-day trial doesn’t require a credit card.
