Clarivise Scan — phishing training that happens in the inbox

It is not a filter, and that is the point

Scan blocks nothing. It holds nothing. It moves nothing to a quarantine folder and it makes no decision on anyone’s behalf. A person reading an email decides they are unsure about it, clicks once, and gets an explanation.

That distinction is the entire product thesis, and it runs opposite to how the category usually works.

A filter trains people to stop paying attention. That is not a criticism of filters — it is what a good one is for. If the system reliably removes the bad mail, the rational response is to trust the inbox, and after a while nobody is really looking. Which is fine until the one well-crafted message gets through, arriving in an inbox full of people who have been quietly taught for three years that anything which reaches them is safe.

Every organization needs the filter. What almost none of them have is anything that makes the human better, and that is the gap Scan is built for.

The teachable moment is not in November

Annual awareness training fails for a boring reason: it happens when nobody has a question. Phishing simulations do worse, because getting caught by your own IT department is embarrassing, and embarrassment teaches people to hide mistakes rather than report them.

The moment a person is genuinely motivated to understand how phishing works is the moment they are hovering over a message thinking this feels off but I am not sure why. That is the only moment with real attention in it.

Scan is designed to be available exactly then, and to answer the question they actually have — not “is this bad” but “what should I have noticed?”

What it teaches

The verdict is the least interesting output. The part people keep the sidebar open for is the link panel, and it is deliberately built to be legible rather than authoritative:

• Every link in the message, listed with its real destination domain
• Safelink and URL-defence wrappers decoded back to the underlying target, so the user sees where the click actually lands rather than an opaque redirector
• Domain mismatches called out explicitly — where the visible text implies one host and the destination is another
• Outlook’s own external-sender banner read and folded in as a signal

Almost none of that requires a model. It requires somebody to have carefully handled the fifteen ways a URL can be dressed up as something it is not, and then to show the result rather than act on it.

The reasoning is written in plain language for the same reason: which link pointed somewhere unexpected, why the sender domain looked wrong, what the message was actually asking the reader to do. A red bar with a score of 87 teaches nothing. “This link says it goes to your bank and resolves to a domain registered eleven days ago” is a lesson somebody carries to the next message.

The success metric is declining usage

Most security products want engagement to go up. For a teaching tool, sustained heavy use on obvious cases means people are not learning — they are outsourcing the judgment, and the dependency has just moved.

The intended curve is that a user leans on it heavily in their first weeks, then reaches for it only on genuinely ambiguous mail. Recognising a lookalike domain unaided is the product working.

This is also why it pairs with Clarivise Shield rather than competing with it. Shield marks every message automatically and continuously; Scan is there when a person has a question and wants to understand the answer. Automatic coverage plus deliberate practice.

Key custody was the first engineering constraint

An extension is a file on somebody’s laptop. Anything shipped inside it — including a “hidden” API key — is readable by anyone who installs it, and a leaked model credential is someone else’s bill and someone else’s abuse report.

So the extension never calls the AI provider. It posts message data to an edge function that holds the credential server-side, builds the prompt, and returns parsed JSON. End users configure two things: a proxy URL and a per-tenant token. The proxy URL is validated against an exact expected shape and restricted to the platform’s own hosts, so a user cannot be socially engineered into pointing their extension — and their token, and their email — at an arbitrary server.

Two surfaces, one backend

Scan ships as a Manifest V3 extension for Outlook on the web and as an Office.js task pane add-in for the Outlook clients. Both call the same endpoint, so an explanation is the same explanation wherever someone reads their mail, and there is one place to improve a prompt rather than two.

A local fast-path catches the structurally obvious scam patterns — gift-card fraud being the archetype — before any API call is made, and the server enforces a per-token cooldown so a stuck client cannot run up a bill. Use the model for the judgment that needs judgment; use ordinary code for everything else.

Built to be bought and deployed

Licensing is per organization and operated rather than administered by hand: per-company keys stored hashed, so the issuing system cannot reveal a key after the fact; trials expiring at 15 days and annual keys at 365, enforced server-side; an operator console available as both a local UI and an authenticated HTTPS API; and a self-serve portal where a prospect creates an account and receives a trial key with nobody in the loop.

Deployment is packaged for Intune, Google Admin, Group Policy and self-hosted distribution — the step most vendors skip, and the one that decides whether a tenant admin can push it to five hundred workstations or has to write a wiki page asking people to sideload an extension.

Content-script behaviour is covered by Playwright, because the failure mode of a mail-reading extension is silent: the sidebar renders, no error appears, and it is quietly parsing the wrong DOM node after a Microsoft UI update.