The Model Context Protocol (MCP) lets AI assistants like Claude and Cursor connect to real systems — including your database. The problem: most setups hand the AI a connection string with full write access, and rely on the model choosing not to run a DELETE without a WHERE.
That's the part I wanted to remove. Not "the AI probably won't write" — "the AI can't write." So I built BoltSchema: a Postgres MCP server that's read-only by default and structurally can't modify your database. Here's how it works under the hood.
The threat model
The scary part of AI + database access isn't the AI being malicious. It's:
- A hallucinated UPDATE that "fixes" a row.
- A DROP TABLE suggested confidently during a "cleanup."
- SQL injection through a tool call you didn't sanitize.
Read-only credentials are the obvious answer — and everyone means to set them up. But read-only-by-discipline breaks the one time you forget, or grab the wrong connection string. I wanted read-only to be the default, enforced at multiple layers.
Defense in depth
Layer 1 — Read-only transaction on every query.
Every single query runs inside:
BEGIN READ ONLY;
-- your query
COMMIT;
Even if someone hands the server a superuser connection string, Postgres itself refuses any write inside a READ ONLY transaction. The database is the last line of defense, and it doesn't trust my code.
Layer 2 — A SQL guard that isn't fooled by string literals.
A naive keyword blocklist is trivially bypassed — SELECT 'DROP TABLE users' would trip a dumb filter, and '; DROP TABLE-- would slip past one. So the guard:
- Strips comments and string literals (single-quoted, double-quoted, and dollar-quoted) first,
- Then keyword-matches against a banlist (DROP, DELETE, INSERT, UPDATE, ALTER, TRUNCATE, GRANT, …),
- Rejects multi-statement payloads outright.
- So you can't smuggle a forbidden keyword inside a literal, and you can't chain a second statement.
Layer 3 — Encryption at rest.
Connection strings are encrypted with AES-256-GCM (random IV + auth tag per record). Token comparison uses timingSafeEqual to avoid timing attacks.
Layer 4 — Result limits.
Queries are wrapped in a LIMIT (default 100, hard cap 1000) so a SELECT * on a huge table doesn't blow up the context window or the connection.
What it exposes to the AI
Two MCP tools:
-
get_database_schema— lists tables + columns from information_schema (system schemas excluded). -
execute_read_only_query— runs SQL through the guard + read-only transaction.
The transport
It speaks MCP Streamable HTTP (the modern SSE-based transport that supersedes the deprecated SSEServerTransport), built on the official @modelcontextprotocol/sdk. Native streamable-HTTP clients point at the URL directly; stdio-only clients (like Claude Desktop) use the mcp-remote bridge.
Try it without connecting your own DB
There's a zero-trust sandbox: one click seeds a realistic e-commerce Postgres database (customers, products, orders, …) and hands you a public token you can paste straight into Claude Desktop. No signup, same read-only guard as production.
🔗 Built by me — try BoltSchema here: link
🐦 Questions or feedback? I'm on X: @atilmohamine
Top comments (0)