Chat2DB

The AI assistant runs every database tool with the full stored credential of whichever datasource it chooses. Although the chat request carries the datasource the user selected, a model-supplied datasource id overrides it, and list_all_datasources hands the model every saved connection (up to 200, including production-tagged ones). There is no dedicated or read-only identity for AI work and no authorization check between the model's choice and the credential; the only thing that narrows damage is the separate non-query SQL refusal scored under tool scoping.

Chat2DB does not let the AI run write SQL itself. Every execute_sql call is parsed into statement types; anything other than SELECT/SHOW/DESCRIBE is refused and handed back to the user to run manually in the SQL console, and the policy hook that could allow non-query execution is hard-wired to false with no setting to change it. The exact SQL the model attempted is shown in the chat trace, so the human runs exactly what they see. The gap is in what counts as safe: statements classified as queries run unattended, and the classification is not a strict boundary.

The six AI tools are narrow wrappers with typed parameters, bounded page sizes (500 rows max, 50 rows shown to the model) and a 20-table cap on schema requests, and execute_sql is filtered by a dialect-aware SQL parser that only lets query-type statements run. But execute_sql still accepts arbitrary SQL text, the read-only check is a statement-type classification rather than a read-only connection, and no tool validates which datasource or database the model points it at. The default tool set is effectively read-only, which is the strongest part of this design.

The model-generated code in Chat2DB is SQL, and it runs directly on the user's real databases through the normal JDBC connection with the stored credential. There is no isolation boundary: no read-only connection or transaction, no rollback wrapper, no sandbox database, and no query timeout. The statement-type filter (credited under tool scoping) is the only thing standing between model SQL and the database.

The assistant reads plenty of content its user did not write: database rows, table and column comments, DDL, and uploaded files, all of which enter the conversation with the same standing as the user's request (uploaded files are even framed as 'evidence provided by the user'). Nothing tracks that taint. What limits a hijack is that writes are always refused regardless of source. Data exfiltration is not limited: the chat UI offers an unattended egress path.

Chat2DB has no long-term memory, retrieval store, or auto-loaded instruction files. The only persistence that feeds back into the model is the chat history of the current session: the last five rounds of user and assistant text are re-sent on each turn, loaded only for the session the user owns. Poisoned content can therefore persist within a conversation but not spread to new ones, and the user can delete sessions.

The AI layer itself loads no plugins or MCP servers in this release; the third-party code that runs alongside it is JDBC drivers, which execute inside the same JVM that holds every decrypted credential. Built-in drivers are fetched by version-pinned file name from the vendor's CDN with no checksum, and the MySQL drivers are pre-downloaded automatically at startup. Custom drivers are uploaded by the operator, which the security policy treats as trusted.

Stored datasource passwords and AI API keys are encrypted at rest with AES-256-GCM using a per-installation key, and the main AI request path logs only content-free summaries with masked API keys. Elsewhere protection is thin: the log-redaction controls do not cover every path, chat transcripts with query results are stored as plain JSON, and nothing redacts sensitive data from query results before they go to the model provider. Usage telemetry is on by default but content-free.

Each chat turn's tool calls (name, exact arguments, timestamp) and tool results are streamed to the UI and saved with the assistant's message in the local chat history, and every executed AI query is also written to the SQL operation log tagged AI_TOOL. That gives a usable local record, but it is saved only when the stream completes normally, operation logging is asynchronous and best-effort, refused statements and list calls are absent from the operation log, MCP calls are tagged the same as in-app AI calls, and the client can turn history persistence off per request.

There are no hard limits on an AI turn. No tool-call round cap is configured for Spring AI's internal tool loop, the HTTP stream emitter has no timeout, AI-issued SQL has no query timeout, and output token limits apply only if the user sets them in the model config. Stopping a response closes the stream and disposes the subscription, but a query already running on the database continues.