The usual way to get an AI agent working with a database is to paste a CSV export into a prompt, or describe the schema by hand and let the model guess at the rest. It goes about as well as it sounds.
The fix we wanted was narrow and boring: a small set of parameterised operations the model can call, with the connection kept on our side of the fence and writes switched off unless someone asks for them. That's the local MySQL tool, and it ships with Infersec today.
What the model can do with your database
Attach the tool to an endpoint and the model gets eight operations. Two are introspection: one lists the tables, the other returns a table's columns and types. select is the workhorse - it takes structured arguments (table, columns, a where object, order, limit), and every value in that where clause becomes a query parameter, so there's no SQL smuggling through them. Table and column names are validated and quoted separately. In practice the model reads the schema, asks for what it needs, and stops.
The rest are writes - insert, update, delete, truncate, and raw sql - and none of them exist until you connect with --allow. --allow insert,update gives the model exactly those two and nothing else. update and delete refuse to run without a non-empty where condition, so no "fix everything" statements, and Conduit applies a LIMIT to any bare SELECT sent through sql. Conduit also caps results at 1000 rows per query and cuts every query off at 30 seconds, both adjustable if you want them stricter.
The credentials never leave your infrastructure
Here's the part that matters to whoever signs this off. The tool runs inside Infersec's Conduit application - the agent you self-host next to your hardware. The MySQL connection is made from Conduit, on the machine that can already reach the database, and the credentials you supply at connect time never touch the Infersec platform. The tool's record in the Infersec Console holds a type and an optional description. The connection details stay in the environment of the machine running Conduit, and nowhere else.
When the model makes a call, Infersec relays the operation to your Conduit instance over an authenticated channel, Conduit runs it, and the result rows flow back into the conversation. The platform sees the tool-call arguments and the results - the same view the model has. It never holds the keys.
Connect your database in three steps
-
Create a tool of type MySQL/MariaDB under Inferencing → Tools. The description is optional; the model reads it.
-
Connect it from the machine that can reach the database, passing credentials through
MYSQL_*env vars so nothing lands in shell history or process listings:
MYSQL_URL=mysql://user:pass@host:3306/db \
npx @infersec/conduit tool connect <tool-id> --key <api-key>
Read-only by default. Add --allow when, and only when, you want writes.
- Attach the tool to an endpoint as a tool service. Infersec injects the tool definitions into the request and runs the tool loop server-side for up to 10 rounds, returning the finished answer as an ordinary chat completion - streaming included.
Cloud or self-hosted, same tool
The tool behaves identically in both Infersec deployments, because Conduit does the database work either way. On the cloud platform an intercepted request costs €0.005 plus €0.002 per executed tool call. The self-hosted variant has no per-call billing at all - tool counts are governed by the licence tier instead, 3 on Standard, 10 on Pro, 50 on Max. Pointing Conduit at one or the other is a single flag - --api-url defaults to the Infersec cloud, and a self-hosted instance is just a different URL. If the database has no business leaving the building, self-hosted keeps the console and the tool relay on your own network.
The model needed a narrow door, opened from your side.
Sign up for early access, or read up on the self-hosted variant.