The motivation behind this project — the problem we hit, why existing options didn't fit, and where we're taking it.
For what it is and how it works, see README.md. For hands-on usage, see HOW_TO.md.
We run a SaaS product backed by many databases — multiple MySQL clusters and MongoDB stores, spread across products and services. Two needs pushed us to build QueryMesh:
We wanted to point Claude at our real SaaS data to generate statistics and answer analytical questions — usage trends, cohort behavior, operational metrics — without an engineer hand-writing and running a query every time.
The obvious ways to do that were all wrong:
- Hand the model broad database credentials. Fast to set up, unacceptable in practice. An LLM with write-capable, unaudited, unscoped access to production is a data-loss and data-leak incident waiting to happen.
- Give it a read replica login and hope. Still unscoped and unaudited — every agent sees every table, and nothing records what was asked or returned.
- Write a bespoke tool per question or per dataset. Safe, but it doesn't scale. Every new question is an engineering task, which defeats the point of using an agent at all.
What we actually needed was a way to say: this agent may read these sources, only read, and every access is recorded. That's a policy-and-audit problem, not a prompt problem — so it belongs in infrastructure, not in the model's instructions.
We're building an LLM-powered natural-language interface into our product — letting users ask questions in plain language and get answers drawn from their data. That turns the controlled-access problem from an internal convenience into a product requirement:
- Each end user's assistant must be scoped to exactly the data that user is allowed to see — and nothing else.
- It must be strictly read-only, enforced by the system rather than trusted to the model.
- Every query must be auditable, both for security review and for debugging what the assistant did.
- Adding a new data source behind the interface can't require a code change and a deploy each time.
The same capability that lets Claude generate our internal statistics is what will sit behind the customer-facing natural-language feature. Building it once, as a standalone service, means both use cases share one audited, scoped, read-only door into the data.
QueryMesh's design falls directly out of the two needs above:
| Principle | Why it exists |
|---|---|
One uniform query tool |
An agent (or a per-user assistant) shouldn't learn a new tool per database. One tool over MySQL + Mongo keeps the model's surface small and the same across every source. |
| Scoped, pre-filtered discovery | An agent can't leak or query what it can't even see. Each key sees only its sources — critical when the "agent" is a customer's assistant that must never glimpse another tenant's data. |
| Read-only, enforced twice | The query guard and a read-only DB credential. We don't want a single guard bug to be the only thing standing between an LLM and a DELETE. |
| Every call audited | We need to answer "what did the assistant read, for whom, when?" — for security, compliance, and debugging. Denials are logged too, so probing shows up. |
| Registry in a database, not code | Adding a source is an INSERT, not a deploy. As the natural-language feature grows to cover more of the product, onboarding a new data source has to be cheap. |
Put together: let an LLM read production data usefully, without ever trusting the LLM to be the thing that keeps that access safe. The safety lives in the architecture — scope filtering, read-only guards, and the audit log — so it holds regardless of what the model is prompted to do or what a user types into the natural-language box.
We deliberately built this as its own service rather than a library or a per-product integration:
- One audited door. Internal analytics with Claude and the customer-facing NL interface hit the same scoped, read-only, audited path. We reason about data access in one place.
- Separation of concerns. QueryMesh owns access policy (who can read what, and the record of it). The products own their data. The registry and audit store live in QueryMesh's own database, separate from every source it fronts.
- It generalizes. Nothing about this is specific to our schema. Any team that wants to give an LLM controlled, read-only, audited access across several databases has the same problem — which is why we're open-sourcing it.
Edumix is the first product to build on QueryMesh, using it for three things:
- Automated periodic system monitoring — scheduled agents that read operational data on a cadence to surface health and anomalies, without standing write access.
- Aggregated statistics dashboards — analytics drawn across Edumix's services and databases through the single audited
querypath. - A conversational data-querying interface — letting users ask questions in natural language, with each assistant scoped to exactly the data that user is allowed to see.
All three run through the same scoped, read-only, fully audited door — which is exactly what QueryMesh was built to provide.
- The natural-language interface is the next major consumer: per-user scoped keys (or OAuth-issued tokens) so each assistant is confined to that user's data.
- Production hardening tracked in the README roadmap: per-key rate limiting, audit-failure metrics, real readiness checks, and an integration suite that proves writes are refused at both the guard and the credential layer.
- Additional secret backends (AWS Secrets Manager, Vault) so source credentials never have to live in env files outside of local dev.