Browser-anchored Trust and Building a Useful SaaS Chat Tool
AI security will take more than prompt instructions and crossed fingers. Pat presents his case for a model that actually works.
The Need for a SaaS Chat Tool that is Useful
SaaS firms across the world have been frantically racing to jam AI chat tools into their products with the, often unfulfilled, promise that it will transform their product (as long as you can afford the $29.99 / month premium).
As a side project, I've been building a SaaS product called Luminate, which is a fully featured hair salon management platform (my wife runs a hair salon so I'm reasonably well-versed in what makes businesses like this tick).
Initially, I definitely did not want an AI chat tool within the product, mainly because I wasn't convinced that it would ever be useful. My experience of these add-ons has been largely negative. They are often expensive, mostly useless, and often respond with an apology that it cannot complete the task I asked of it:
Me: "Tell me what I have going on today please"
Agent: "I'm sorry I can't answer that question right now, but here's a link to an article about booking staff leave"
Me: "Go away."
However, the spectre of launching a multi-tenant SaaS product and not being able to support it has been looming over me, and honestly I don't think the product will be successful without a strong layer of AI-based support.
As such, I have been mulling over what needs to happen in order to make a SaaS chat tool actually useful. Ultimately, it comes down to giving the agent access to the same data as the end user in a robust manner.
The Problem With How Most AI Assistants Access Data
Imagine you run a hair salon and you use software to manage your bookings, customers, and staff. You want an AI chatbot that can answer questions about your business. Simple enough.
Now imagine you're one of thousands of businesses using that same software. Your data sits alongside everyone else's. The AI needs to answer your questions using your data. And you need to guarantee that the agent won't accidentally slip someone else's data into your response.
The way most companies solve this is lazy and dangerous. They give the AI a master key; a single set of credentials that can access everything. Then they add a carefully crafted note to the AI's system prompt: "Only look at data for this particular business."
Think about that for a moment. You're relying on the AI to follow instructions. The same AI that occasionally makes things up, that can be tricked by cleverly worded prompts, that sometimes just gets confused. You're trusting it to be the security boundary between your data and everyone else's. You are pinning the integrity of your system on hope.
What We Did Instead
The principle I started with was simple: the AI assistant should never be more powerful than the person using it.
If you're a staff member who can only see your own appointments, the AI should only see your appointments. If you're a manager with access to notification logs, the AI gets that too. If an admin downgrades your role whilst you're mid-conversation, the AI's access should change immediately, not at some future token refresh, but on the very next thing it does.
And critically, none of this should depend on the AI behaving correctly. The constraints need to be structural, baked into the architecture, so that even if the AI is completely compromised, it still can't access anything the user can't.
How It Works
The way in which this works is quite technical, however I have tried to summarise here in a simple manner.
When you open the chat widget, your browser (which is already logged in and knows exactly who you are) asks the server to create a short-lived pass. This pass says "this is User 17 at Business 42, and they were authenticated 30 seconds ago." It's cryptographically signed so it can't be tampered with, and it expires after 10 minutes.
The AI uses this pass to make requests. But here's the key part: every single request goes through a validation layer that checks a number of things before letting it through. Is the pass genuine? Has it expired? Has the user logged out since it was issued? Does the user still exist? Do they still have access to this business? And, this is the important one, what are they actually allowed to do right now?
That last check looks the user's permissions up fresh from the database for every request. If your role changed 30 seconds ago, the AI knows about it on its very next action.
The AI itself has no credentials whatsoever. It can't see the security layer, can't influence it, can't bypass it. It just calls tools and gets results back; results that have already been filtered, permission-checked, and scrubbed of sensitive data like full phone numbers and email addresses.
Why This Matters
With a master key, a single security exploit could expose every customer's data across every business on the platform. With our approach, the absolute worst case is that an attacker sees the data the user could already see: read-only, with personal information masked, for a maximum of 10 minutes.
That's the difference between a front-page data breach and a non-event.
The Boring Truth About AI Security
If I'm honest, there's nothing revolutionary about any individual technique we used. Short-lived tokens, permission checks, read-only APIs; these are all well-established patterns. The contribution isn't any single clever trick. It's the specific way we've composed these proven techniques to solve a problem that most teams are currently solving with prompt instructions and crossed fingers.
The boring truth is that building a secure AI assistant isn't really an AI problem at all. It's an authentication and authorisation problem. The AI is just a new kind of client making requests, and like any client, it should only get access to what the user behind it is allowed to see.
Going Deeper
I've written a detailed technical paper covering the full architecture: the token mechanism, the multi-layer validation middleware, how we prevent every category of privilege escalation, how the model extends to external autonomous agents, and an honest discussion of the limitations and future work.
If you're building an AI assistant into a multi-tenant application or you're evaluating one that someone else built, I'd encourage you to read it. The question worth asking isn't "does the AI have good instructions?" It's "what happens when the AI ignores them?"