I'm building a production AI for Well, a finance product that lets founders ask questions in plain English and get trustworthy answers. Here's the moment that decides your architecture.
"What were my weekly spending trends over the last 12 months?"
There are two default ways teams answer this.
First, the "function" path. The AI can call narrowly defined server functions you write. You start with getWeeklySpend(). Then someone asks "every two weeks," "by month," "by category," "excluding contractors," "only EU entities," "compare to last year." You add getBiweeklySpend(), getMonthlySpendByCategory(), getSpendExcluding(), and a dozen more. It's safe and understandable. It's also a treadmill. Flexible questions outpace your function list.
Second, the "let it compose" path. You give the AI a unified view of your data and let it compose database queries. You ask the AI to add a filter like where account_id = ? to every query it generates. This is flexible and fast—until the AI forgets the filter. With hundreds of queries and machine-generated SQL, that "one in twenty" miss becomes a privacy incident.
The choice that avoids both traps: enforce the account boundary at a security gateway, not by asking the AI to remember. Every request includes the user's account ID (the company boundary). The gateway automatically adds the account filter to every query. The AI can't forget; the gateway won't let it.
In our Well deployment the gateway product is Hasura, but the pattern is what matters. Hasura sits between your application and your database. When the AI generates a query, Hasura translates it to SQL and automatically injects the account filter. This also lets you control what the AI sees—expose only certain tables, hide sensitive columns, enforce read-only access. The AI gets a clean schema to reason about, and you get security enforced at the gateway layer.
What that looked like in production (Well): 50+ tables in the schema, built to scale to thousands of accounts. Every query automatically scoped by the gateway. Full flexibility for "weekly vs biweekly," "by category," "exclude contractors," "last quarter vs last year"—without writing new functions. 5–8 days to production gateway. Zero cross-account leaks—the gateway makes it architecturally impossible.
When not to use this: single-account tools or throwaway prototypes. Start simple. Add the gateway once you have multiple accounts or real risk.
The bottom line: hardcoded functions don't flex. Asking the AI to filter eventually fails. Enforce the account boundary at a security gateway and add firm limits (timeouts, row caps, read-only). You'll keep the flexibility product needs and the security the law demands.
→ 15-minute isolation audit. I'll map where your AI-generated queries can fail and show exactly how gateway enforcement would fit your stack.
Contact: valentinmanes@outlook.fr | LinkedIn | jiliac.com