ai newsFr., 6. Nov.
EilmeldungOpenAI is stepping back from NDAs for data center projects

Why we stopped letting AI agents connect directly to the database

The request usually sounds like this: "the agent needs to query the ERP". And the first reaction from whoever runs IT is the right one: nobody wants to hand a production database username and password to software that decides on its own which query to run. The risk isn't theoretical — it's a malfor

dev.toDonnerstag 23:58 · 05.11.4 Min. Lesezeit
Bild: dev.to

The request usually sounds like this: "the agent needs to query the ERP". And the first reaction from whoever runs IT is the right one: nobody wants to hand a production database username and password to software that decides on its own which query to run. The risk isn't theoretical — it's a malformed query at peak time, a sensitive field exposed in a reply, a credential leaking into a log.

This guide is for the IT director who needs to say "yes" to the agent without saying "yes" to direct access. It explains why Zihin removed direct database connections and which path data takes instead.

On October 4, 2026, version 2.2.2 of Zihin's MCP package shipped alongside the removal of the direct database connection tools — the db_config type and the db_event trigger. Since then, data integrations go through API tools or MCP servers, such as the MCP Bridge. The change is recorded in the product changelog.

The decision starts from a simple observation: giving an agent a connection string to the production database creates three problems that no prompt layer can solve.

Note: Removing a feature is an expensive decision for a product. We did it because direct database access was the point where the customer's security architecture stopped applying. The path that replaces it isn't more limited — it's more predictable.

The current design separates who holds the data, who queries it and who carries the answer. There are three components, each with a clear job.

Replay keeps a read-only copy of the agreed tables in a Postgres database inside your network. You decide which tables go in. Oracle and SQL Server are copied via change data capture; systems like Sienge, via API. The production database never receives a query from the agent — ever.

The practical result: the ERP keeps serving operations, and the copy serves the AI's questions. If a query is heavy, it's the replica that feels it, not billing.

On top of that copy, the MCP Bridge publishes read-only queries with contracts specific to the business domain: "open orders by supplier", "stock balance by item", "bills coming due". The agent gets a list of tools with a defined name, description and parameters. It chooses which one to call and with which arguments — it doesn't write the query.

That changes the security conversation. Instead of asking "what can the agent do in the database?", the answer is the list of contracts you approved. Nothing outside it exists for the agent. For Protheus, the Bridge is documented in production; SAP and Oracle EBS are planned. See the details at /integrations.

That leaves transport. The Tunnel opens an outbound connection from your network to the platform over port 443 — the same one your browser uses. No inbound ports, no VPN, no firewall changes. Credentials for internal systems are resolved inside your network and never leave it.

ERP / production database └─ Replay → read-only copy (Postgres, inside your network) └─ MCP Bridge → contract-based queries, read-only └─ Tunnel → outbound connection, 443, no open port └─ the agent gets the answer, never the credential Enter fullscreen mode Exit fullscreen mode What the IT director gets from this design Whoever evaluates the architecture usually asks four questions. In this model, the answers are short.

Tip: Start with an inventory of questions, not an inventory of tables. List the five queries your team runs against the ERP every day and turn each one into a Bridge contract. That's less surface than replicating the whole database — and it already covers most real usage.

Read-only solves data integrity, but on its own it doesn't solve confidentiality. That's where contextual security policies (CSP) come in: rules enforced on every execution, not suggested to the model. A data policy restricts sensitive fields and entities; a schedule policy defines when the agent can operate; an origin policy limits where it can be triggered from. They inherit from the broadest scope to the most specific — define them once for the company and refine them per team, agent or user.

Combined with the platform's RBAC (what people and API keys can do) and the credential vault encrypted with AES-256-GCM, the whole set is described in plain language at /security.

A note of honesty: the availability and deployment scope of Replay, MCP Bridge and Tunnel depend on your infrastructure, your data agreement and your access requirements. Check with the sales team what applies to your case — the answer is in the deployment FAQ.

Letting an AI agent access a database safely doesn't mean giving it a well-configured database user. It means not giving it database access at all — but a read-only copy, through queries you approved, over a connection your network initiates. Zihin removed the direct connection because it was the weakest link in the design. What remains is a path where the credential never leaves your network, the ERP doesn't feel the load, and every read is on record.

If your IT team is holding back AI adoption at exactly this point, it's worth mapping the flow with real data from your ERP. Book a diagnostic.

Originally published in Portuguese on the Zihin blog. I work at Zihin, which connects AI agents to a company's systems and processes, with permissions, human approvals and cost tracking.

Quelle: dev.to (dev.to). Original öffnen