Agentic AI data assistant: text-to-SQL, multi-agent workflows, code execution over databases
github.com/eosphoros-ai/DB-GPT · 2026-10-03 · 5905245
Defense-in-depth score
1.9 / 10
As shipped, DB-GPT's data agent runs model-written shell commands and Python directly on the server host with the server's full environment, including its API keys, and none of it needs human approval. The web server's default network exposure and authentication are not locked down. The Docker sandbox is opt-in, and even then skill scripts run on the host. Treat a default install as remote code execution for anyone who controls data the agent reads.
DB-GPT caps each agent run at a fixed number of steps, times out shell and Python calls, and shows a confirmation prompt for catalog connector write tools. Beyond that the defaults are weak: model-written code runs on the server host with the server's full environment and no approval, and the server's network exposure and authentication are not locked down. The safest setup turns on the container sandbox and builds most of the protection around the server yourself.
| Setup | How | What it gives you |
|---|---|---|
| A read-only database role | Connect each datasource with a database account that can only read the tables the task needs | The database itself refuses writes and schema changes, whatever SQL the agent sends C3 |
| A dedicated, low-limit identity | Run the server as its own OS user whose environment holds only a scoped LLM key with a spending limit set at the provider | Code the agent runs reaches only that account and that key, not your other credentials C1 |
| Access for trusted users only | Serve DB-GPT only on a private network or behind an authenticating proxy that admits people you trust | Only people you chose can send the agent instructions C5 |
| The container sandbox | Set SANDBOX_RUNTIME=docker (or podman or nerdctl) in the server's environment | Shell and Python calls run in a throwaway container that receives only explicit variables, and a failed backend stops rather than falling back to the host C4 |
| Reviewed skills only | Import only skills whose instructions and scripts you have read, from a copy you keep | Skill scripts, which run on the host even with the sandbox on, are code you have checked C7 |
| Its own container or VM | Run the whole server in a container or VM with outbound access limited to the model provider and your databases | An outer boundary around host-run code and package installs, and a narrow path for data to leave C5 |
| Logs kept off the host | Ship the tracer's files under logs/ to storage the server account can't modify | A record of every agent action that the agent's own shell can't edit or delete C9 |
SafetyCard
logs/ and in SQLite; store them like the data the agent read.0.00 / 1.00
The web server's default network exposure and authentication are not locked down. The agent's tools run as the server's operating-system user with the server's full environment, including the LLM API key, and connect to databases with whatever stored credentials the datasource holds. There is no per-tool or per-request narrowing of authority, and no authorization layer between the agent and its tools.
0.20 / 1.00
The only human approval in the agent path is a confirmation prompt for connector (MCP) tools that a catalog marks as writes. Shell commands, Python, SQL, and skill scripts never require approval. The connector approval gate is not a strict boundary.
0.15 / 1.00
The default tool set hands the model a raw shell, raw Python, and a SQL tool, all running on the server host. The SQL tool's 'SELECT only' rule is not a strict boundary and the connector beneath it executes writes and DDL. A few tools validate properly (read_file resolves real paths against an allowlist), but the skill script runner's path handling is not a complete boundary, and the shell tool makes every other check moot.
0.42 / 1.00
By default, model-written Python and shell commands run as ordinary subprocesses on the server host, with the server's full environment (including the LLM API key) and unrestricted network access; Python code checks are explicitly switched off and the bash check is a short denylist. Docker, Podman and nerdctl backends exist and fail closed if selected, but they are off unless SANDBOX_RUNTIME is set, use a stock root container with networking on, and the skill script runner always executes on the host regardless of the setting.
0.00 / 1.00
The agent reads untrusted content (uploaded files, knowledge-base documents, database rows, MCP connector results, and anything it fetches with curl) into the same context that chooses its tools, with nothing to separate data from instructions. In the same session it holds database credentials and the LLM key, can run shell commands, and can send data anywhere on the network, all without human approval.
0.05 / 1.00
Skills are folders of instructions and scripts on disk; when one is loaded its SKILL.md is injected into the system prompt with an order to follow it strictly, and the agent's unsandboxed shell can write new skill folders into that same directory, which serves every user. Past conversation turns are reloaded into later rounds, and knowledge-base documents feed retrieval. Conversations are keyed by a user name, and skills and knowledge spaces are shared.
0.00 / 1.00
The shell tool's own description invites the model to run pip, apt, and curl, so the agent can install and execute third-party packages on the host whenever it decides to, without asking. Skills imported from GitHub are fetched from a branch tip with no pinning or integrity check, and their scripts run as host subprocesses with the server's full environment. MCP connectors are remote servers the user adds explicitly; custom connectors bypass the catalog entirely.
0.20 / 1.00
The setup wizard writes its config, which can hold the LLM API key, to a file created with owner-only permissions, and secret-named arguments are masked in approval prompts. Elsewhere, database passwords are stored as plain text in the metadata database, connector-credential encryption is not robust, and every code and skill subprocess receives the server's full environment, so the model can read any key it wants. A local tracer records LLM replies and tool results by default; there is no third-party telemetry.
0.40 / 1.00
A tracer that is on by default writes a span for every agent action, including the model's reply and the tool output, to a local JSONL file and an SQLite store, and the conversation history with every step is saved at the end of each turn. These records do not reliably say who asked, approvals are not recorded, spans are batched and flushed late, and everything sits on the same host the agent's unsandboxed shell can edit.
0.45 / 1.00
The main agent is capped at 30 reasoning steps, shell commands at 30 seconds, Python at 60 seconds, and each sub-agent at 15 steps and 10 minutes, with at most three sub-agents per dispatch and no nested dispatch. There is no token or cost cap and no overall time limit, and each dispatch hands sub-agents fresh budgets. Closing the stream cancels the agent and kills the local process tree, but the skill script runner leaves its subprocess running when it times out.