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 instantly, 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, or any MCP client at it, and your agents inherit the safety layer your team already uses — scoped tokens, read-only by default, every query audited.
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
- Full Audit Trail
- Self-Hosted
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
Every guarantee below is enforced by the database or the driver protocol. No layer depends on the agent behaving.
Read-only, enforced by the database
A read-only token executes inside a database-enforced read-only transaction. The database rejects any write no matter how the SQL is phrased — the token cannot write; the database enforces it.
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 and the database rolls the write back. Dry-run previews the affected-row count before anything commits.
Timeouts and rate limits
Per-statement timeouts are enforced in the database, so a runaway query cannot freeze the server. The MCP endpoint itself is rate-limited.
Adversarially tested
The enforcement layer ships with an adversarial test suite — statement smuggling, writes hidden inside reads, over-limit writes — built by attacking it, not just describing it.
Agent Access — New Token
Token name
claude-code
Connections this token may use
- staging-postgresStaging
- analytics-replicaRead Replica
- prod-postgresProduction
Read-only (recommended)
Allow writes — single INSERT/UPDATE/DELETE, row-capped, never DDL
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 — driver rejects it | Never — driver rejects it |
| See hosts, ports, or credentials | Never — names only | Never — names only |
| Reach a connection off its allowlist | Never | Never |
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 — driver rejects it
Write (Opt-In)
Never — 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
One Audit Trail — Humans and Agents
Every agent query lands in the same Query History your team uses, tagged with the token's name. That includes blocked attempts — when the guard rejects a statement, the rejection is logged too, so you can review exactly what an agent tried, not just what succeeded.
Nothing runs unrecorded. Agent queries and plan requests are written to Query History, every time.
Blocked attempts included. A rejected statement is evidence, not noise — it stays in the trail.
Errors are redacted before the agent sees them, so a failed query doesn't leak infrastructure details.
Query History
- agent · claude-code OK
SELECT id, email FROM users ORDER BY created_at DESC LIMIT 50 - agent · claude-code OK
EXPLAIN SELECT * FROM orders WHERE status = ? - you OK
UPDATE orders SET status = ? WHERE id = ? - agent · claude-code Blocked
DROP TABLE users
Works With Claude Code, Cursor, and Any MCP Client
QueryGlow exposes a standard MCP endpoint. Paste the config, and the agent gets exactly five tools — no more surface than the token allows.
{
"mcpServers": {
"queryglow": {
"url": "https://your-domain.com/api/mcp",
"headers": {
"Authorization": "Bearer qg_your_token"
}
}
}
}list_connections
The connections this token may use — names 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/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.
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; the fastest way to evaluate it is a local deployment 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 audit log — each one a thing you now maintain and each one a place to be 99% right. Even the deprecated reference Postgres MCP server carried a documented SQL-injection case study.
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, one audit trail — already built, already adversarially tested, 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 never included by accident. 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 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 blocked attempt is recorded in Query History, tagged with the token name, 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, and any write whose real affected-row count exceeds it is rolled back at the database, so a missing-WHERE mistake cannot wipe a table. A dry-run mode previews a write’s affected-row count before anything commits.
How do I revoke an agent’s access?
Open the Agent Access dialog and revoke the token — 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, so there is nothing agent-shaped to poke at there. The demo shows the rest of the GUI. To evaluate the agent layer, read the documentation or deploy QueryGlow on your own machine and create a token against a test database.
Let the Agents In. Keep the Keys.
One lifetime license covers the GUI and the agent layer — $79 once, pay never again. The live demo shows the GUI (Agent Access is disabled there); the docs cover the rest.