Show and tell: Hardening Private Text-to-SQL & MCP Tool Backends — Read-Only Guardrails & Stdio Isolation for Local Models

[A7mdMe]

Background: Operating Text-to-SQL & MCP Tools with Local Models

In private enterprise deployments of PrivateGPT, organizations frequently connect local LLMs (Llama 3, Mistral, Qwen) to internal databases and tools via the Model Context Protocol (MCP).

When running Text-to-SQL workflows on local models, two specific operational concerns arise:

1. Higher SQL Hallucination Variance in Local Weights:
   Local open-weights models, while powerful for data sovereignty, have a higher variance in structured output generation than frontier cloud APIs. When synthesizing queries for complex schemas, local models can inadvertently output mutating SQL commands (DROP TABLE, ALTER, UPDATE, or stacked semicolon statements).

2. Stdio Stream Framing Integrity for Subprocess Tools:
   When launching custom TypeScript MCP tools as local subprocesses, arbitrary console.log() statements write to stdout. Because MCP stdio communication relies entirely on clean JSON-RPC 2.0 frames on stdout, unhandled logging corrupts protocol message boundaries and crashes host client parsers.

---

Layered Defense: Application-Level Query Inspection + Read-Only Database Roles

To enable safe Text-to-SQL exploration for local models without risking schema corruption, the open-source MCP Production Kit implements an application-level token & regex inspection pipeline:

1. Comment Stripping: Removes -- and /* */ SQL comments commonly used to mask stacked injection payloads.
2. String Literal Masking: Replaces quoted strings so domain values (e.g. status = 'DROP_PENDING') don't trigger false alarms.
3. Multi-Statement Rejection: Semicolon splitting blocks stacked queries from executing sequentially.
4. Statement Whitelist & Mutation Blacklist: Strictly enforces that queries must begin with SELECT or WITH, and validates against 16 mutation keywords (DROP, DELETE, TRUNCATE, ALTER, UPDATE, INSERT, CREATE, REPLACE, etc.).

import { validateReadOnlyQuery } from './postgres_connector.ts';

// Intercepting an agent hallucination attempting a stacked statement
const query = "SELECT id, name FROM accounts; DROP TABLE ledger;--";
const result = validateReadOnlyQuery(query);

if (!result.safe) {
  // Returns actionable error to host loop instead of corrupting database:
  console.error("Blocked:", result.reason);
  // => "Multiple SQL statements detected. Only a single query may be executed per request."
}

(Note: This application-level guardrail uses token & regex sanitization, not a full SQL AST compiler, and is engineered to work in tandem with database-level read-only permissions like GRANT SELECT).

---

Dual-Stream Stdio Logging

Redirects all diagnostic, audit, and operational logging strictly to process.stderr, keeping process.stdout dedicated exclusively to JSON-RPC 2.0 protocol communication:

export class StdioTransportLogger {
  static info(message: string, meta?: Record<string, unknown>): void {
    process.stderr.write(JSON.stringify({ level: 'info', message, ...meta }) + '\n');
  }

  static error(message: string, error?: unknown): void {
    process.stderr.write(JSON.stringify({ level: 'error', message, err: String(error) }) + '\n');
  }
}

---

Architecture Comparison: Open-Source Core vs. Pro Pack ($19 USD)

Component	Open-Source Core	Pro Pack ($19 Add-on)	DIY Custom Build
Dual-Stream Stdio Logging	Built-in	Built-in	Prone to stdout corruption
SSRF-Guarded HTTP Fetch	Built-in (blocks private CIDRs)	Built-in	Exposes internal IPs / IMDS
Read-Only PostgreSQL Tool	Manual implementation	Pre-tested standalone module	Requires ~4-5 hrs engineering
Cloudflare Workers (SSE)	Manual setup	Pre-configured edge template	Requires ~4-6 hrs debugging
Non-Root Dockerfile	Standard	Multi-stage with USER node	Usually runs as root
Access	GitHub Repo	Whop Files App	Manual setup (~10-15 hrs)

---

Maintainer Disclosure & Community Discussion

Disclosure: I am the maintainer of MCP Production Kit and author of the commercial Pro Pack add-on on Whop.

We'd love feedback from the PrivateGPT community:

1. When running Text-to-SQL with local weights (Llama 3, Mistral, Qwen), what query validation patterns have been most reliable for your teams?
2. Do you host database tools alongside the inference runtime or in isolated network enclaves?
3. What error reporting formats in tool results best help local models self-correct hallucinated syntax?