Enabling it takes about ten minutes. What you have created is a new connection into production with no session, no ticket, and no reviewer — and the only control surface it offers is the connection itself.
This is the Agents spoke of the Infozense Non-Human Database Access library. Its argument in one line: an MCP endpoint is scoped to a database connection, so every control you want has to be a property of that connection — which makes the connection a policy object rather than a bookmark.
Someone on your data team wants an assistant to help with reporting. They open a database connection, tick a box marked Enable MCP, save, and copy the generated configuration into their tool. Total elapsed time: about ten minutes. No change request. No architecture review. Nothing that would show up in a CAB agenda.
What just happened is not “AI integration.” Production acquired a new client.
Every database access control your organization runs assumes a human being on the other end.
Single sign-on assumes a person to authenticate. Ticketed access requests assume a person to make the request and a second person to approve it. Session review assumes sessions belong to someone with a name. Four-eyes on production assumes two pairs of eyes. Periodic recertification assumes a manager who can be asked, once a quarter, whether this individual still needs this access.
Strip the person out and every one of those controls degrades into a formality. The credential still works. The grant is still there. Nothing revokes itself when the human it was designed around stops being present.
This is not a new problem — your cron jobs and ETL pipelines have been quietly exempt from all of it for years. What is new is that the exemption now applies to something that composes its own queries.
Strip away the framing and look at what the endpoint actually exposes to whatever connects to it. The documented capabilities include datasource information, catalog listing, schema listing, table listing, full table detail including DDL — columns, constraints, indexes, comments — and SQL execution, with results returned as CSV.
Schema discovery and arbitrary query execution. That is not an integration. That is a database client, minus the human.
Nothing here is a criticism of the design. A database client is exactly the right thing to build. The mistake is on our side of the line: we classify it as an AI feature and route it through an AI governance conversation, when it should be classified as a production database client and routed through the process that governs those.
Here is the detail that matters, and it is easy to skim past. The endpoint is scoped to a connection. Each connection has its own endpoint, its own token, and must be configured separately.
Sit with that for a moment, because it constrains everything downstream. If the endpoint is connection-scoped, then every control you want to impose has to be a property of that connection — or it does not exist. There is no layer between the agent and the connection where you can insert a policy. The connection is the policy surface.
For twenty years a saved connection has been a convenience. A bookmark with a password attached. Something a developer creates without thinking, copies between machines, and names “prod-copy-2.” The security boundary lived somewhere else entirely — in the approval workflow, in the reviewer, in the simple physical fact that a human being can only type so fast.
That is over. The connection is now a policy object, and most organizations are still treating it like a bookmark.
The practical consequence is a reframe, and it is a liberating one.
Stop asking “what should this agent be allowed to do?” That question has no enforceable answer — it lives in a prompt, and prompts are not access control.
Ask instead: what grant sits behind this connection? That question has a precise, testable, auditable answer, and it is enforced by your database engine rather than by a model's cooperation.
Which means the work is ordinary database engineering:
The blast radius of an agent is exactly the grant behind its connection. No more, no less. That is good news, because it converts a novel and frightening problem into one your DBAs solved a long time ago — applied to a consumer they have not met yet.
We could not find a documented read-only mode, query restriction, or row and column policy on the MCP endpoint itself, and we have not tested the licensed build to confirm either way. Check your own version before relying on it.
But notice that the answer does not change the recommendation. If a read-only toggle exists, it is a property of the connection — which is the argument. And a control you configure per connection is only as reliable as your discipline in configuring every connection. The grant in the database is enforced whether or not anyone remembers to tick a box.
Build the guarantee at the layer that cannot be forgotten.
Agents are the visible case, not the whole case. The same gap runs through every non-human connection you own: the ETL job whose credential has not rotated since 2023, the reporting service account that accumulated write access nobody removed, the pipeline that connects to production using a connection profile still labelled Development.
Most of your database traffic is not human any more. The MCP endpoint is simply the newest instance, and the one with an executive sponsor.
Pick your three most important databases and ask what every non-human identity connected to them can currently read, and what it can currently change.
If that takes more than a day to answer, the answer is that you do not know — and the agent conversation is premature, because you cannot reason about the marginal risk of a new client when the existing ones are unmapped.
That mapping is a two-week engagement, it is read-only, and it needs no license purchase.
