QS-WAN and QNova Client · Assistant

WANDA runs on the AI account you already have

WANDA is the assistant built into QS-WAN and the QNova Client. It does not come with a model of its own. You connect the AI account your organisation already uses, the key stays encrypted in your console, and nothing reaches that provider until you have seen the exact fields and said yes.

What it is

Where does my data go, and who has to defend the answer

That is the first question anyone asks about an assistant inside a security product, and it is the right one to ask. The usual answer is a paragraph about a commitment to privacy, which tells you nothing at all about which fields left the building. It matters more here than almost anywhere, because the person weighing this up is usually the one who has to write it down on a record, sign it, and defend it a year later to somebody with a checklist. For them a vague answer is not neutral. It is a reason to leave the feature off forever, which is what most people quietly do.

You bring the AI account

We supply no model. You connect an account your organisation already pays for and already trusts, whether that is a commercial provider or your own internal model. There is a provider and model selector per conversation, so a question about a device policy and a question about a network map do not have to go to the same place.

The key belongs to whoever entered it

It is encrypted before it is stored, and never returned in full afterwards. Not to the interface, not to an export, not to the person who typed it. Validation has four states, so a connection is either working or it tells you which way it failed, and no deployment data is sent while it checks.

Six capability sections, all off by default

Off means off. Somebody has to decide, in writing, what this assistant is allowed to look at, and that decision is the whole point. Before anything goes to your provider you see the fields themselves, with a projection hash, and results produced locally are marked as local.

An assistant that cannot tell you which fields it sends is not really a feature. It is a data transfer with a chat window on the front.

The mechanism

Ask it something before you switch anything on

You get nothing, and that is the design: absent grant, no action. Then turn on the two capabilities the question needs and look at what the confirmation actually shows you, which is the fields themselves rather than a category name.

six capability sections, off by defaultProtection statusoffScanningoffNetworkoffSettingsoffThe deviceoffCollaborationoffSharing confirmationwhy did the last scan on thislaptop not finish?the fields, not a category and a promisedevice idfin-lap-04agent version4.2.1last scan resultcode 3, interruptedprotection statuson, answered locallypolicy scopeFinance, answered locallyprojection hash: not computedYour AI accountno model of ourskey encrypted, neverreturned in fullnothing sent yetWhat crosses the wirea capability identifiertyped argumentsno executable codethe code is in the signed build
switch capabilities on at the leftsix capabilities, none on, nothing has left

Six capability sections on the left, all switched off to begin with: protection status, scanning, network, settings, the device and collaboration. Asking a question with none of them on returns nothing at all, because access is fail-closed: absent grant, no action. Switching on the device and scanning lets the question about a scan be answered, and the panel in the middle then lists the exact fields that would leave, one by one, with a projection hash over them. Two of the fields are marked as answered locally and never leave the network. On the right, the AI account is yours, with the key encrypted and never returned in full, and the only things that cross the wire are a capability identifier and typed arguments. No executable code travels, because the code lives in the signed build.

Why this exists

Four things that go wrong without it

A commitment to privacy is not an answer

It does not name a single field. The person who has to sign for this needs to know what left, not that somebody cares deeply about the question.

The feature ends up switched off forever

When the answer is vague, the safe move is to never turn it on, and then nobody has to say out loud that they did not trust it.

A model in the box is a supplier nobody chose

An assistant that arrives with its own provider adds a name your legal team has not approved, at the exact moment they are least inclined to approve one.

An assistant that can run code is a much bigger question

If what arrives over the wire can execute, then every answer about data becomes an answer about code as well, and the conversation gets much longer.

What you get

One assistant, and the two rooms it has to survive

The security team wants to know what can execute and what can be reached. The person signing wants to know whose provider it is and which fields left.

For the security team

Nothing executable crosses the wire

The server sends a capability identifier and typed arguments. The actual code lives in the signed build, in a fixed table, so a prompt injection that genuinely works gets to call another entry in that same table and nothing else.

It never gets a privilege the person does not have

The assistant acts inside the permissions of whoever is using it, not above them.

Fail-closed, on a grant that is present and current

It acts only on a grant that exists, is active, is not expired and is held against an identity. Absent grant, no action.

For the business

You answer the data question with a name you already approved

The provider is one your organisation already pays for. The trade is that you give up the convenience of a model that arrives in the box.

Data minimisation is built in, not configured

And when an answer gets cut short to keep it small, it says so instead of quietly trimming, which is the version you want before a review rather than during one.

The page of switches is the short answer

Everything starts off, and somebody in your organisation has to choose what the assistant can reach. That person is going to be asked about it.

How it works

Three steps, and the first one is a gate

A gate, before anything runs

The first time an administrator opens WANDA in the console, a disclosure gate explains what it is and what it would do. Nothing runs before that. Then you connect the AI account, and the key is encrypted before it is stored and never returned in full afterwards. Validation has four states, so you learn which way a connection failed rather than just that it did, and no deployment data is sent while it checks.

Six switches, and the decision is written down

Six capability sections, all off. Somebody has to decide what the assistant is allowed to look at. Then, before anything goes to your provider, the confirmation shows the fields themselves with a projection hash over them, and marks the results that were produced locally so you can tell at a glance what never left your network.

On the desktop, it answers about that machine

Most of your people are never going to open a console. In the QNova Client they get WANDA as one of the widgets on their desktop, and it works without the tunnel being up. It covers six areas of their own machine: protection status, scanning, network, settings, the device itself and collaboration. Think about why a scan is still running, not show me the fleet.

Before you start

You need an AI account of your own. If your organisation has none, there is nothing to connect, and we are not going to sell you one.

In detail

What travels, and what the assistant is allowed to do with it

Injection

Why a working prompt injection is a small problem here

There is a design decision underneath the desktop widget that a security team will care about, so here it is. Nothing executable crosses the wire. The server sends a capability identifier and typed arguments. The actual code lives in the signed build, in a fixed table.

So a prompt injection that works, genuinely works, gets to call another entry in that same table and nothing else. It also never gets a privilege the person using the client does not already have. That is a much smaller blast radius than an assistant which can be talked into running something new.

Grants

Fail-closed, and what that costs you

WANDA acts only on a grant that is present, active, not expired, and held against an identity. Absent grant, no action. That is why asking a question with every capability off returns nothing rather than returning less.

Data minimisation is built in rather than configured, and when an answer gets cut short to keep it small, it says so instead of quietly trimming. The cost of all this is real: the assistant is less useful on the first day than one that arrives switched on, and that is the trade we made on purpose.

Where this earns its place

Four mornings this changes

Your legal team already approved one provider

That is the one it uses. There is no second supplier to get through a review, because we do not bring a model.

Somebody asks which fields leave the building

You show them the confirmation screen. It lists the fields, not the categories, and it marks what was answered locally.

A question about a policy and one about the map

They can go to different providers, because the selector is per conversation rather than per installation.

A person wants to know why their scan is still running

They ask the widget on their own desktop, and it answers about their own machine, with the tunnel up or not.

Works better with

What it is usually asked about

Most of what the assistant is asked about in the console lives here: alerts, hosts, CVEs and the order in which to fix things.

The questions about what a device is allowed to do, and the signed envelope the answers come from.

The other half of what gets asked: which segments reach which, drawn from the configuration rather than from a picture.

Where the fleet questions are actually answered, gateway by gateway, when the assistant is not the right tool.

What this does not do

The limits, because they are what make the rest believable

It does not bring a model

If your organisation has no AI account, there is nothing to connect, and we are not going to sell you one. That is the trade: you give up the convenience of a model that arrives in the box, and you get to answer the data question with a name your own legal team already approved.

The provider connection is at integration stage

We would rather say that than publish a list of supported providers before every name on it has been tested. Ask us where it stands for the provider you use, and you will get the real answer.

It is not monitoring

Nobody here watches your network, and the assistant does not watch it either. It answers when it is asked, with what you have allowed it to see.

It does not make the decisions for you

Everything starts off. Somebody in your organisation has to choose what the assistant can reach, and that person is going to be asked about it. We built the page of switches so the answer is short.

Questions people ask

The ones that come up first

What is WANDA?

The assistant built into QS-WAN and the QNova Client. It brings no model of its own: you connect the AI account your organisation already uses, the key stays encrypted in your console, and nothing reaches that provider until you have seen the exact fields and said yes.

Where does our data go?

To the AI account you connected, and only the fields you confirmed. Before anything is sent you see the fields themselves with a projection hash over them, and results that were produced locally are marked as local, so you can tell at a glance what never left your network.

Can we use our own internal model?

Yes. The selector is per conversation and takes a commercial provider or an internal one, so a question about a device policy and a question about a network map do not have to go to the same place.

Who can see the API key?

Nobody, after it is entered. It is encrypted before it is stored and never returned in full afterwards, not to the interface, not to an export, and not to the person who typed it.

What happens if somebody manages a prompt injection?

Nothing executable crosses the wire. The server sends a capability identifier and typed arguments, and the code lives in the signed build in a fixed table, so an injection that genuinely works gets to call another entry in that same table and nothing else. It also never gets a privilege the person does not already have.

Is anything switched on when we install it?

No. Six capability sections, all off, and a disclosure gate the first time an administrator opens it. Access is fail-closed: absent grant, no action.

Bring the account you are unsure about.

We connect it, switch the capabilities on one at a time, and you watch the field-level confirmation do its job with your own data in front of you. It is free, it lasts as long as you want, and there is nothing to sign.

Scroll to Top