the approach i’m experimenting with is: i build a malloy model of that view (so it’s more graph-like and semantic), then i generate custom mcp tools on top of it. those tools basically act as guardrails - the agent can only call “get_customer_tickets” or “fetch_usage_events” instead of writing arbitrary queries. These tools are embedded into my malloy model so it's not really a sql query its firing on that view, instead it's searching by filtering from my view. finally, i give access to those tools into my agent builder.
this feels cleaner and safer, but i'm new to this and not sure if this is the right pattern. is anyone here tackling this differently? are there any efficient ways to give agents scoped, governed access to internal data without shooting yourself in the foot? what are some more things i should consider here?
AI is fairly apt at writing efficient queries for that matter and I use it a lot for this purpose.
Same. And definitely not with read/write access. But even RO is risky due to the possibility of an unintentional DDOS via a bad query, etc.
> custom mcp tools on top of it. those tools basically act as guardrails - the agent can only call “get_customer_tickets” or “fetch_usage_events” instead of writing arbitrary queries.
This is more or less what I would do, although I would say it's neither here nor there to me whether one uses a view or not. But I'd definitely advocate building dedicated, purpose specific tools, with known queries, and let the agent use those. At least in the near-term.
If it proves too unwieldy to implement all those tools, I might could be convinced to let the agent generate its own queries to use, but I'd insist on a HITL mechanism to have a given query reviwed before it is ever allowed to be executed the first time.