Klinik Dr Fang — Front-Desk Pattern Assistant
A clinic front-desk AI that finds patterns but structurally can't leak data or write its own SQL
Most "connect AI to your database" demos would hand over every patient record if you phrased the prompt cleverly enough. I built one for a clinic that structurally can't — and that's the whole point.
Klinik Dr Fang (a fictional single-doctor GP clinic) wanted plain-language answers about its own records: "any cluster of similar cases lately?", "who hasn't been in for over a year?" Wiring an LLM straight to the database would answer those questions. It would also be one prompt-injection away from dumping the entire patient table.
So the agent never touches the database. It sits behind a governed tool layer — the MCP Toolbox for Databases pattern — with exactly 10 pre-written, parameterized queries. There is deliberately no "run any SQL" tool. The agent picks the right approved tool and explains the result; it cannot author a query, change a WHERE clause, or reach a column a tool doesn't return.
The guardrail is four layers deep:
- The toolset is the agent's entire universe — no
execute_sqlexists - The SQL is fixed; only values bind, never concatenated
- Tools are scoped per role — the front desk sees only its own set
- The database connection is read-only, so writes are physically impossible
Ask it to delete the no-shows or export every record, and it refuses — not by policy, but because the capability doesn't exist. Ask it for a pattern, and it finds a real one: in the demo it flags a cluster of 7 similar presentations from the last two weeks, an early outbreak signal nobody searched for.
For any business with sensitive data, the real question isn't "can AI read my database?" It's "what exactly is it allowed to do?" — and that should be designed, not hoped for. The demo runs entirely in your browser on synthetic data (sql.js + WebAssembly) — no sign-up, no key — and the same governed-tool architecture scales up to Cloud SQL or AlloyDB without changing the safety story.