[IBJunior]

Problem

run_sql ran agent-written SQL as the app's own database user, inside a READ ONLY transaction. That blocked writes but not reads, so SELECT auth_tokens, env, headers FROM mcp_server worked. That table holds plaintext MCP OAuth tokens, stdio env vars and HTTP headers. The checkpoint tables (every conversation), config and thread were readable too. MCP tools auto-approve, so text injected into an MCP tool result could get the agent to read those secrets and send them out through another tool, with no approval card along the way.

Fix

Postgres now decides what run_sql can read; there is no table filter in code.

• Migration 0006_analytics_readonly_role.sql (hand-written, idempotent): creates a cameron_analytics role (NOLOGIN) with USAGE on public and SELECT on transaction and category only, then grants the app user membership in it.
• runReadOnlyQuery runs SET LOCAL ROLE cameron_analytics inside the existing transaction. READ ONLY, statement_timeout, the rollback and the row cap are unchanged.
• Closing the set_config escape. SET ROLE changes only the current role, and set_config('role', 'none', true) is SET ROLE as a function call, which the guard's SET keyword check misses. Paired with query_to_xml('select … from mcp_server', …), a single SELECT read mcp_server on the dev database. The migration therefore revokes EXECUTE on set_config from PUBLIC and grants it back to the app user. It ends with a check that raises if the role can still call set_config or read mcp_server, because a REVOKE run by a non-owner only warns. Migrations must run as a superuser; all three compose stacks already do.
• Agent-facing error: a permission denial (42501) comes back as { error: "That table isn't available to run_sql…", availableTables, detail }. Other DB errors keep the existing Query failed: shape. The tool description is unchanged.

Tests

• pnpm test (459) and tsc --noEmit pass.
• New unit tests cover the denial mapping and confirm that other errors aren't treated as denials.
• A drift test reads drizzle/*.sql and checks that the role's grants match the tables describe_finance_schema documents, with nothing beyond SELECT and no whole-schema grants.
• Live on the dev DB (mydb_dev, 5544), through the real runSql:
  • A finance aggregate gives the same result as before.
  • mcp_server, checkpoints, config, thread, the drizzle schema and the set_config escape are all refused.
  • Re-running the migration SQL succeeds.
• The eval sandbox (5545) migrates cleanly and has the expected grants.
• Production was not touched. Its migrate image copies drizzle/ and runs as the superuser, so it picks this up on the next --profile full up.

Docs

The run_sql, raw-SQL boundary and config bullets in AGENTS.md, plus a "What run_sql can read" subsection in docs/ARCHITECTURE.md.

🤖 Generated with Claude Code