Scoped tokens, per connection
Each agent gets its own Bearer token with an explicit connection allowlist; an empty allowlist reaches nothing. Tokens are read-only by default, revocable at once, and stored only as hashes.
Give AI Agents Database Access the Database Itself Enforces
QueryGlow is a self-hosted database GUI with a built-in MCP endpoint. Point Claude Code, Cursor, Codex or any MCP client at it, and your agents inherit the safety layer your team already uses: scoped tokens, read-only by default, every call in the Activity tab.
A raw database MCP server hands agents a connection string. QueryGlow hands them a scoped token. $79 once. Lifetime license.
- Read-Only by Default
- Enforced in the Database
- Every Call in the Activity Tab
- Pause Any Token
- Self-Hosted
“Beautiful interface and very intuitive.”
Jean-Francois, Mildor Violon, verified customer
See Every Agent Call. Stop Any Agent.
Every tool call an agent makes through QueryGlow lands in the Activity tab, refused and paused ones included. When something looks wrong, pause that token, or every token, with one click.
https://db.your-company.com
Every call in the Activity tab. Time, agent (token name), connection, tool, the SQL with quoted values masked, rows, duration and outcome: ok, dry run, refused, paused, error, timeout, busy or over cap.
Refusals included, with the reason. A refused statement is evidence, not noise. Filter by agent, connection or status, search the SQL, and an unread badge tells you what is new.
Pause one agent, or all of them. A paused token stays valid and the client stays connected, but every tool call is refused with -32002 and recorded until you resume. No revoking, no broken setup.
Errors are redacted before the agent sees them, so a failed query doesn’t leak hosts, ports, usernames or paths.
The Activity tab keeps the newest 5,000 records or 30 days and covers calls through QueryGlow's MCP endpoint. run_query and explain_query also land in Query History, tagged with the token name. Agent Access shipped in 1.2.0; the Activity tab and pause came in 1.2.1, at a buyer's request.
The Fear Is Rational
When engineers discuss giving LLMs database access on Hacker News, the verdicts are blunt, and they're right.
“an insane thing to do”
“In application security, 99% is a failing grade”
“asking an LLM nicely”
The story of an AI agent wiping a production database made the rounds for a reason: when the only thing between an agent and your data is an instruction it was asked to follow, the failure mode is total.
The same threads converge on the accepted answer: schema-only access, read-only enforcement, scoped credentials. QueryGlow ships exactly that pattern as a checkbox, with the enforcement living in the database and the driver, not in a prompt.
Deterministic Enforcement, Not a Text Filter
Read-only and single-statement rules are enforced by the database and the driver protocol; the rest is enforced by QueryGlow on your server. None of it depends on the agent behaving.
Read-only, enforced by the database
A read-only token executes inside a database-enforced read-only transaction (PRAGMA query_only on SQLite). The database rejects any write no matter how the SQL is phrased.
One statement, enforced by the driver
Every agent statement runs through the driver’s single-statement (prepared) protocol, which rejects multi-command strings. A benign-looking read cannot smuggle a second statement behind it.
Writes: opt-in, capped, reversible
A write token may run a single INSERT, UPDATE or DELETE, never DDL. Exceed the row cap (1000 rows by default) and the database rolls the write back. Dry run previews the affected-row count before anything commits.
Timeouts and rate limits
Every agent statement has a timeout, 30 seconds by default, set with QUERYGLOW_AGENT_STATEMENT_TIMEOUT_MS, on every engine. SQLite queries run in a separate process that is killed on timeout, capped by QUERYGLOW_SQLITE_MAX_WORKERS (default 4). The MCP endpoint is rate-limited.
Tested before every release
The enforcement layer is tested against an adversarial suite before every release: statement smuggling, writes hidden inside reads, over-limit writes.
What Agents Can and Cannot Do
Two token modes. The "never" column doesn't change no matter what the agent asks for.
| Action | Read-Only Token (Default) | Write Token (Opt-In) |
|---|---|---|
| Browse schema (tables, columns) | Yes | Yes |
| Run SELECT queries | Yes, row-capped | Yes, row-capped |
| EXPLAIN a query without running it | Yes | Yes |
| See query history for its connections | Yes | Yes |
| INSERT / UPDATE / DELETE | No, the database rejects it | One statement per call, row-capped |
| DROP, TRUNCATE, or any DDL | Never | Never |
| Chain multiple statements in one call | Never, the driver rejects it | Never, the driver rejects it |
| See hosts, ports, or credentials | Never, names only | Never, names only |
| Reach a connection off its allowlist | Never | Never |
| Keep working while paused | No, every call refused and logged | No, every call refused and logged |
Browse schema (tables, columns)
Read-Only (Default)
Yes
Write (Opt-In)
Yes
Run SELECT queries
Read-Only (Default)
Yes, row-capped
Write (Opt-In)
Yes, row-capped
EXPLAIN a query without running it
Read-Only (Default)
Yes
Write (Opt-In)
Yes
See query history for its connections
Read-Only (Default)
Yes
Write (Opt-In)
Yes
INSERT / UPDATE / DELETE
Read-Only (Default)
No, the database rejects it
Write (Opt-In)
One statement per call, row-capped
DROP, TRUNCATE, or any DDL
Read-Only (Default)
Never
Write (Opt-In)
Never
Chain multiple statements in one call
Read-Only (Default)
Never, the driver rejects it
Write (Opt-In)
Never, the driver rejects it
See hosts, ports, or credentials
Read-Only (Default)
Never, names only
Write (Opt-In)
Never, names only
Reach a connection off its allowlist
Read-Only (Default)
Never
Write (Opt-In)
Never
Keep working while paused
Read-Only (Default)
No, every call refused and logged
Write (Opt-In)
No, every call refused and logged
See the GUI before you pay
Open the live demo (read-only sample database, AI switched off), no signup. Agent Access is disabled there; the setup guide covers the agent layer. One license covers both.
Try the live demo
Stripe checkout. You'll enter your GitHub username for the repo invite. No refunds, so try the read-only demo first.
Works With Claude Code, Cursor, and Any MCP Client
QueryGlow exposes a standard MCP endpoint. Paste the config into any client that speaks MCP over HTTP, and the agent gets exactly five tools, no more surface than the token allows. Run several agents side by side, for example Qwen, Codex, Claude Code and GLM, each with its own token.
Claude Code
claude mcp add --transport http queryglow https://your-domain.com/api/mcp --header "Authorization: Bearer qg_your_token_here"Cursor and other HTTP MCP clients
{
"mcpServers": {
"queryglow": {
"url": "https://your-domain.com/api/mcp",
"headers": {
"Authorization": "Bearer qg_your_token"
}
}
}
}Claude Desktop (via mcp-remote, needs Node.js)
{
"mcpServers": {
"queryglow": {
"command": "npx",
"args": [
"-y", "mcp-remote", "https://your-domain.com/api/mcp",
"--header", "Authorization: Bearer qg_your_token_here"
]
}
}
}list_connections
The connections this token may use: names, types and environments, never hosts or credentials.
get_schema
Tables and columns of a connection, so the agent writes correct SQL.
run_query
Runs SQL and returns rows. Read-only tokens: reads only. Write tokens: also a single INSERT, UPDATE or DELETE, with dry-run preview.
explain_query
Returns the query plan without executing anything.
get_query_history
Recent queries, human and agent, for the allowed connections, with quoted values masked.
Honest note: Agent Access is disabled in the public live demo, so you can't poke at it there. The setup guide walks through the full setup. There is no trial: once you own QueryGlow, start with a read-only token against a test database.
Why Not Just Hand-Roll a Database MCP Server?
You genuinely can. A competent developer can wire up a read-only MCP server against Postgres in an afternoon; people have, and it works. If that's all you need, build it.
The catch is the tail. A hand-rolled server is a weekend project with an unbounded security surface: your own SQL classifier, your own statement-splitting rules, your own row caps, your own activity log. Each one is a thing you now maintain, and each one is a place to be 99% right.
QueryGlow's answer is to make the accepted safety pattern a checkbox instead of a codebase: read-only transactions enforced by the database, single statements enforced by the driver protocol, row-cap rollback, an Activity tab and a pause switch. Already built, tested against an adversarial suite before every release, and attached to a GUI your team uses anyway.
One Safety Layer, 6 Databases
The same token model and enforcement layers work across every engine QueryGlow supports.
Frequently Asked Questions
Is it safe to point an AI agent at a production database?
Treat it like any credential decision. In QueryGlow, a token only reaches connections you explicitly put on its allowlist; an empty allowlist reaches nothing, and a production connection is only included if someone ticks it, and the dialog warns when they do. Tokens are read-only by default: reads run inside a database-enforced read-only transaction, so the database rejects writes no matter how the SQL is phrased. The safest setup is a read-only token scoped to a staging database or read replica; give an agent production write access only with a clear reason.
What data does the agent actually see?
The agent sees connection names, types and environments (never hosts, ports, usernames, or passwords), the schema of its allowed connections, and the row-capped results of queries its token permits. Driver errors are redacted before the agent sees them, so a failed query doesn’t leak infrastructure details.
What happens if an agent tries to write with a read-only token?
The statement is rejected: read-only tokens execute inside a database-enforced read-only transaction, so the database itself refuses the write regardless of how the SQL is phrased. The refused attempt shows up in the Activity tab with the agent’s token name and the reason, so you can review exactly what the agent tried.
How do write tokens stay safe?
Writes are opt-in per token. A write token may run a single INSERT, UPDATE or DELETE per call, never DDL like DROP or TRUNCATE. You set a row cap (1000 rows by default), and any write that touches more rows than the cap is rolled back at the database. A DELETE or UPDATE without WHERE is refused unless Power Mode is on; with Power Mode on, such a statement can still change a table no larger than the cap, and on MySQL/MariaDB cascaded rows are not counted. A dry-run mode previews a write’s affected-row count before anything commits.
How do I stop or revoke an agent’s access?
Open the Agent Access dialog. Pause stops one token, and Pause all agents stops every token: the tokens stay valid and the clients stay connected, but every tool call is refused and recorded until you resume. Revoke deletes a token and the agent loses access immediately. Tokens are stored only as hashes, are scoped per connection, and the MCP endpoint is rate-limited. Your team still shares one QueryGlow deployment; the scoped tokens exist for the machines.
Can I try Agent Access in the live demo?
No. Agent Access is disabled entirely in the public demo, and the source code is only available after purchase (no refunds), so there is no way to try it first. Read the setup guide and the Activity tab section above to see exactly how it works; after purchase, start with a read-only token against a test database.
Let the Agents In. Keep the Keys.
One license covers the GUI and the agent layer: $79 once, no subscription, every 1.x update included. The live demo shows the GUI (Agent Access is disabled there); the docs cover the rest.
After you pay: a GitHub invite to the private repository, then ./queryglow install on your server. Every 1.x update is one ./queryglow update away.