DBX blocked our tested writes. One response flag still needed a closer look.

The question before connecting anything real

A database tool that an AI agent can call deserves a specific question: what stops the agent from changing data? We tested DBX 0.4.105 against a disposable PostgreSQL 16.14 database containing synthetic orders.

MCP, in this context, is the interface that lets an AI application call the database tool. A read-only setting at that tool layer and a restricted role at the database layer are separate controls. We wanted to see how each behaved in a small local experiment.

No customer records or live database connections were used. The point was to inspect the behavior before considering anything more consequential.

Two setups, two boundaries

In the first profile, DBX's compatibility setting DBX_MCP_ALLOW_WRITES=0 was enabled on a policy that had never been saved through its central Settings interface. That qualification is essential: we were testing that configuration path, not every way the application can store policy.

The second profile used a database role restricted to reads on the test tables. This let PostgreSQL enforce a separate permission boundary for the tested mutations.

There was some setup friction worth recording. The DBX connection type string was postgres, and the connection had to be added before the tool's read-only setting was enabled because read-only mode also blocked connection management. These details describe the tested version; they should be checked again if the software changes.

What the checks showed

Under the tool's read-only profile, reads worked and all six tested write paths were rejected. Those checks covered ordinary data mutations, a schema change, a mixed batch, and a write within a common table expression.

The restricted database role also rejected the five tested row-mutation checks. Independent verification compared the full rows afterward and confirmed they were unchanged. The attempted new table was absent.

Check	Observed result
Tool read-only write paths	6 of 6 rejected
Restricted-role mutation checks	5 rejected
Read profiles	2 passed
Full rows afterward	Unchanged
Attempted new table	Absent

The database was stopped after the test. These observations support a narrow conclusion: the configured boundaries held for the operations we actually tried in this local setup.

The success flag that needed context

One batch in the restricted-role profile returned outer isError: false. Inside that response, however, the second statement had failed. Its per-statement result carried execution_error: true.

An integration that only looked at the outer flag could tell a user the whole batch succeeded. That would be an inaccurate account of the result even though the database permission boundary had done its job.

The practical lesson is to inspect every statement result. Tool-call completion, SQL execution, and the final database state answer different questions. The independent row comparison was useful precisely because it checked the resulting state rather than trusting the wrapper response.

The untested territory

We did not test the central Settings UI and its saved-policy behavior. We did not cover other engines, every SQL form, concurrency, connection changes in a production environment, or a real application's complete permission model.

A SELECT-only role in this fixture is not a universal production configuration recipe. Database permissions must fit the real schema, ownership, extensions, and workflows. Our test was designed to observe a few boundaries, not certify the product for sensitive data.

Our take

DBX remains an optional local-development tool from this experiment. The results justify further bounded evaluation with restricted database permissions. They do not justify pointing it at a live database on the strength of a single environment flag.

The prompt above is a planning brief for a disposable test. It asks for explicit scope, a baseline, per-statement inspection, and independent readback. Those are the parts of this experiment we would want to carry forward.

Sources and field notes

• DBX repository
• Download the dated ENAS field notes
• Download the test-planning prompt

The measurements come from ENAS's October 3 local RPC results and verification record. This is a dated test report about DBX 0.4.105, not a claim about the current release or every deployment.