A security questionnaire arrives from a client’s new compliance officer. Question 31 reads: “List every third party that processes our data, including any AI or machine-learning providers.” The account manager opens the RMM vendor’s sales deck. It says “AI-powered” on most slides and names no provider anywhere. The answer is on a different page entirely, linked from the footer of the vendor’s legal pages, in a table the sales team has probably never read. It is called the sub-processor list, and it is where this question gets answered for every vendor on your shortlist, including us.
In the sub-processor list, not the sales deck. A sub-processor list is the vendor’s own statement of which third parties handle customer data on its behalf, and a model provider is a third party handling customer data. If a vendor’s assistant is built on a hosted model, the model host should appear there, usually alongside the cloud provider and the email service. If it does not appear and the product has an assistant, that is the first question for the call.
Whatever the assistant was shown in order to answer. In this category that means command output, ticket contents and monitoring data, which are the most sensitive things you hold about a client. A ticket body contains what the client told you and what your technician found. Command output contains hostnames, paths, usernames and whatever a process printed. Monitoring data describes the shape of the estate. And tickets accumulate things nobody intended: a password pasted into a note in 2021, a connection string in an attachment. Once an assistant reads a ticket to summarise it, all of that has been sent to wherever the model runs.
It names a specific model host, states how long that host retains what it is sent, and says whether you can run the models yourself. Vague answers are the norm, so here is the difference.
Because an assistant does not have to be built on a rented model. Guardian Plus runs open-weight models on infrastructure we operate, or on your own if you would rather host them. There is no OpenAI account, no Anthropic account and no Azure OpenAI endpoint anywhere in the platform. Your command output, your ticket contents and your monitoring data are never handed to a model vendor. When you ask us the sub-processor question, the answer for AI is none, and we would encourage you to ask everyone else on the shortlist the same thing in the same words.
There is a second reason less of your data reaches a model than you might expect: a recognised request does not reach one at all. Capability matching routes a request the platform already understands straight to a vetted action, with no model call. Only the requests that need planning go to the model, and that model is ours. Why the split matters.
It sees what you see. Every tool it calls re-derives the permissions of whoever asked. It cannot open a record you cannot, because it runs under your permissions rather than a service account.
It never sees write actions. Actions that change things are hidden from the assistant entirely and need a person to confirm.
It is kept away from your secrets. Your most sensitive documents are never fed to a model at all, and credentials injected into sessions are resolved server-side, so neither the assistant nor the technician is shown the plaintext.
It asks before it acts. Three approval modes per conversation, and destructive commands stop for a human even on unattended. The modes and the floor.
A questionnaire that gets a vague answer costs everybody a week. The compliance officer writes back, the account manager asks the vendor, the vendor escalates to someone who knows, and the client’s onboarding or renewal waits. Multiply that by every client with a regulator and every vendor in your stack that has bolted on an assistant this year. The cheapest time to get a plain answer is before you sign, in the vendor’s own words, written down.
These are the second and first of the ten questions we think separate the products in this category, expanded. If a vendor cannot answer one of them crisply, that is itself the answer. All ten, with ours.
We are not SOC 2 certified. There is a workflow that collects SOC 2 control evidence from your Windows and Linux estate, and it is a tool for your audit rather than a certification of ours. A compliance officer who needs a badge on the questionnaire will not get one from us yet; what they will get is the sub-processor answer above, the deployment documentation, a written threat model and the network posture guides, available during evaluation rather than after signature.
The questions a questionnaire asks, in the order it asks them, with our answers, including the ones where ours is a limitation.