For security teams · 10 minutes

How verdicts work

What the extension reads when a person asks for a check, what comes back, where the analysis runs, and what a verdict cannot tell you. It describes version 1.0.0, the version the browser stores serve.

What starts a check

Nothing in a message or on a page is read for a verdict until a person asks for one. A check starts when they press:

• Analyze Current Email or Analyze Current Page in the toolbar popup. This is one button; its label follows the tab it is on.
• Re-analyze under a result, which reads the message or page again and replaces the result.
• On the four mail hosts listed below, you may also see a PhishTriage button that the extension adds to the open message’s toolbar. It starts the same check.

Each press of these buttons reads the message or page as it is at that moment, so a person who opens another message and presses again gets a check of the new one.

The sidebar also has its own Analyze Current Page button. In some 1.0.0 builds, that button and Try again can send the content of an earlier check in that tab again, instead of reading the message now open. After moving to another message, use the toolbar popup’s button, the in-page PhishTriage button or Re-analyze, which always read it again.

Two things run without a press. On the four mail hosts, the extension’s script loads on every page and watches the page’s layout so it can keep its button in place; it reads no message content until someone presses. And Background protection, if someone turns it on, checks each site they open. File protection, which is also off by default, is covered in Data handling.

What is sent for an email

Mail is read as mail on four hosts only: mail.google.com, outlook.office.com, outlook.office365.com and outlook.live.com. There the extension reads the open message from the page, the same view the person has, and sends:

• Subject.
• Sender: the address and the display name.
• One recipient address. In the person’s own mailbox this is normally their own address.
• Reply-to address: on Gmail, when Gmail shows one. On Outlook on the web it is not read.
• Date.
• Body text of the open message, with quoted earlier messages removed. One message is read, not the whole conversation.
• Links: up to 10 distinct http or https addresses from the open message, including any in the quoted earlier messages whose text is removed. Links to the mail service itself are left out: mail.google.com on Gmail, and outlook.office.com and outlook.live.com on Outlook.
• Attachment names, as the page shows them. Attachments are not opened, and their contents are never read or sent.

Authentication results are not sent. Webmail does not show a message’s headers to the page, so the extension cannot read SPF, DKIM or DMARC results. In their place the request carries a fixed note saying they are not available. Raw headers are not read either.

Each analysis request also carries the install’s pseudonymous ID and, once the install has registered (which it does by itself on first run), its device ID; an evidence upload carries the device’s credential instead (see Data handling). Neither ID is derived from the person or the machine. As with any web request, the server also sees the network address it came from.

What is sent for a web page

On any other page, the extension reads the page in the tab and sends:

• the page title;
• the full address, including path and query string. A session token or a search term in the address goes with it;
• the hostname;
• the page’s text, with scripts and styles removed: up to 10,000 characters in the newest 1.0.0 builds, 5,000 in earlier ones. Text the page hides is included. What someone has typed into a form field is not;
• up to 15 distinct http or https link addresses found on the page;
• in the newest 1.0.0 builds only: text and links from frames inside the page that come from the same origin, within the same 10,000-character and 15-link limits; a count of large frames from other origins that could not be read; and whether the page is a bare wrapper around a frame. If the page has no title, a frame’s title is sent instead.

Webmail on any other host counts as a web page. That includes Outlook at outlook.cloud.microsoft in 1.0.0: see Limits.

Evidence capture

Keep evidence of phishing is on unless someone switches it off in the popup under Settings. With it on, pressing Analyze on a web page also takes a screenshot of the visible tab and a copy of the page’s HTML at that moment. Both are held in the extension’s memory until the verdict arrives. They are sent only if the verdict is PHISHING or SUSPICIOUS; otherwise both are discarded.

Nothing is captured on the four mail hosts. On webmail anywhere else the screenshot is of the inbox, because that is what the tab shows, and the page’s HTML includes the content of the message that was open. How long captures are kept, and who can see them, is in Data handling.

What comes back

The service returns a structured verdict. Its vocabulary is fixed. An answer whose verdict, confidence, risk score, summary or indicators fall outside it is treated as a failed analysis rather than shown; a malformed optional field, such as the brand or the request type, may instead be dropped and the rest shown.

• Verdict: PHISHING, SUSPICIOUS or BENIGN.
• Confidence: HIGH, MEDIUM or LOW.
• A risk score from 0 to 100, and up to eight further scores, each from 0 to 100 and each scored separately. Higher means more suspicious.
• The brand being impersonated, if one is named.
• What the message asks for, if anything: a password, a payment, a 2FA code, personal details, running a file, gift cards, a reply, or clicking a link.
• A short written summary, and sometimes a one-line reason.
• Indicators: each has a type (DOMAIN, URL, SENDER, ATTACHMENT, TECHNIQUE or HEADER), a value, a severity (high, medium or low) and a short note.

The service asks for the summary in plain English, so the written parts are normally in English, whatever language the message is in.

The three headlines

The sidebar turns the verdict into one of three headlines:

• PHISHING becomes Don’t trust this, in red. The line under it reads “Almost certainly a phishing attempt.”
• SUSPICIOUS becomes Be careful, in orange, with “Some warning signs — handle with care.”
• BENIGN becomes Looks safe, in green, with “No threats detected.”

When the analysis gives a one-line reason, it replaces that line. If a brand or a request was named, the next line reads “Impersonating …”, “asking for …”, or both. Below that, a tag gives the verdict and confidence as returned, for example “PHISHING · HIGH CONFIDENCE”.

Confidence does not change the headline. A BENIGN verdict with LOW confidence still reads Looks safe, so the tag is worth reading.

Scores, top signals and indicators

Below the summary, the sidebar draws a bar for each score it received, in this order: Risk, Phishing, Social Eng., Urgency, Auth, Impersonation, Links, Obfuscation, Attachment. A score that was not returned is left out, not drawn as zero. Bars turn orange at 40 and red at 70. Risk is the overall score.

Top signals, near the top of the result, repeats up to three of the other eight scores: those at 40 or above, highest first. It never includes Risk, and it is absent when no score reaches 40.

Technical indicators lists the indicators, each marked by severity. It is absent when there are none.

The sidebar sets these section and score labels in capitals. The scores and indicators also appear in the portal when someone allowed to see the scan opens it; under Summary the portal shows the one-line reason when there is one, otherwise the summary.

Where the analysis runs

This section follows the privacy policy, version 1.10: its sections “Where analysis happens” and “Third-party processors”. If anything here differs, the policy is the authority.

The extension sends each request to api.phishtriage.com. Cloudflare carries traffic between the browser and PhishTriage’s server; it handles data in transit only and stores no records. The service then offers the content to models in a fixed order, and the first usable answer becomes the verdict:

1. A model PhishTriage hosts itself, on a machine it runs on its own network. It is asked first.
2. A third-party model service, Ollama Cloud. The policy names it before use. As of the policy’s effective date it is configured in no deployment PhishTriage runs, so it is not in the path.
3. Anthropic’s Claude API. The last resort, used when the tiers ahead of it do not produce a usable answer. Anthropic acts as a processor under its API terms, which say API inputs are not used to train models.

A tier hands the content on to the next one when it is unreachable, too slow, returns an error or a rate limit, or produces output that cannot be read or does not have the required shape. If the last tier fails, the scan ends without a verdict and the sidebar shows an error.

For some emails that a tier ahead of Anthropic calls phishing or suspicious, that same tier is asked a second time, with the same content and a short added instruction. That second request goes to no other tier, and never to Anthropic. The policy sets out when it is made.

The policy makes no promise that content stays on machines PhishTriage runs. Content reaches Anthropic whenever the first tier fails, and the policy records a week in August 2026 when that happened to every scan.

Each stored scan records which tier answered. Nothing in the extension or the portal shows it; an access request to privacy@phishtriage.com returns it.

Records are kept in a PostgreSQL database on hardware PhishTriage owns and operates, in Estonia. That statement is about the database host only. The policy does not say where the model server is.

The policy names three more, none of which receives scan content today. Google provides sign-in for the portal, and every portal page loads Google’s sign-in library and fonts. Stripe handles payments and receives nothing unless someone starts a checkout. Elastic Cloud held the records created before the August 2026 move to PostgreSQL; PhishTriage deleted that project on 2 October 2026, and what Elastic keeps of a deleted project, such as its own backups, is governed by Elastic’s terms and its data processing agreement with PhishTriage. The policy lists no analytics, advertising, telemetry or error-reporting services.

An organisation that runs its own backend (available with Enterprise) sends scans to its own server instead. The routing above is then that organisation’s to describe.

Background protection: how a site is checked

Background protection is off by default. When someone switches it on in the popup under Settings, the browser asks for two more permissions: to read browsing history, and to read and change data on all websites. The wording is the browser’s own. If they decline, the switch goes back off.

With it on:

• Each time a page finishes loading in a tab, the extension sends that page’s hostname (for example www.shop.example) to api.phishtriage.com, with the install’s pseudonymous ID and device ID. It sends no path, no query string and nothing from the page. Frames inside a page are not checked separately.
• Browser pages, extension pages and about: pages are skipped.
• The service checks the hostname against PhishTriage’s threat intelligence. This is a lookup, not an analysis of the page.
• If the site is flagged, the extension draws a full-page warning over it and puts a “!” badge on its toolbar icon. The page has already loaded: the warning sits on top of it and does not block navigation. Go back to safety leaves the page. Under Details, I understand the risks — continue to site removes the warning. In some 1.0.0 builds the warning’s ACTION line reads “Navigation blocked”; the page has loaded all the same.
• If the check does not complete — no connection, no timely reply, or the service refuses the request — the page loads with no warning and nothing tells the person. Background protection fails open, so treat it as an extra layer, not a gate.
• Each check is stored as a visit record, up to a set number per device in an hour; a check beyond that is still answered, but no record is written for it. A visit record is given its deletion date when it is written: 365 days later by default, or after the period of 7 to 365 days then in force for the account it is written under, which a team’s owner or the signed-in person can choose (see Data handling). A record written before 4 October 2026 keeps the 90 days it was given. The server’s log also records each recorded check’s hostname (or full address, with Send full URLs), with a hashed network address, and nothing in PhishTriage deletes that log automatically. A check beyond the cap still leaves a log line, but one with no hashed address and no hostname. On request to privacy@phishtriage.com, a device’s lines are cleared by hand; see Data handling.

Send full URLs

Send full URLs, under Advanced in the popup’s settings, is off by default and needs the same permissions. With it on, the full address of every page load, path and query string included, is sent and checked. If Background protection is on as well, the hostname is also sent, as a second check.

Cache domains for 1 hour

Cache domains for 1 hour, also under Advanced, is off by default. With it on, the extension remembers each hostname it has sent and does not send it again for an hour. A site is then checked at most once an hour, however many of its pages are opened, and a return visit within that hour gets no new check. So a site the hostname check flagged on the earlier visit gets no warning from that check on a return visit within the hour. The list is kept in the extension’s storage on that device. The cache applies to hostname checks only, not to full addresses.

Showing the warning safely

The extension recognises https://phishtriage.com/dangerous-example on the device itself. With Background protection or Send full URLs on, opening it always shows the full-page warning, so you can show colleagues what to expect without a real threat. The visit is still reported like any other.

Feedback presses

Under each result, the Your feedback section offers Looks safe to me and Looks dangerous. One press is accepted per result; the buttons are then replaced by “Thanks — saved on this device.”

In 1.0.0, a press stays on that device. The extension stores the verdict, which button was pressed, the time and the address of the page or message in its own storage, keeping the last 100 presses, and sends nothing. So a press does not change the verdict, does not reach PhishTriage and does not appear in the portal. Removing the extension removes the list; Sign out and Leave team do not. The privacy policy describes newer versions, in which a press is also sent.

If you think a verdict is wrong, tell us at support@phishtriage.com.

Limits

What it cannot see

• Desktop mail apps, such as Outlook for Windows or Mac, Apple Mail or Thunderbird. The extension works only on mail opened in a browser tab.
• Phones and tablets. No mobile app is available, and the extension runs in desktop Chrome, Edge, Brave and Firefox only. Safari is not supported.
• Outlook at outlook.cloud.microsoft in 1.0.0. That address is not read as mail and gets no in-page button. The popup offers Analyze Current Page, which checks the whole Outlook page as an ordinary web page: its text and links, within the limits above, rather than the message fields listed under “What is sent for an email”. Evidence capture applies as on any web page. The three other Outlook addresses are read as mail.
• Other webmail, for example Yahoo, Proton or an organisation’s own Outlook Web Access on its own domain. It is checked as a web page in the same way.
• Headers and authentication results, as described above.
• Attachment contents. Only names are sent.
• Browser pages and extension stores. The browser does not let an extension read them, so they cannot be analysed.

A verdict is an aid to judgement

A verdict is a model’s assessment of the content listed above. It is not a guarantee in either direction. Looks safe does not prove that a message is safe, and SUSPICIOUS is where legitimate messages most often land by mistake. Treat a verdict as one input. Keep your own reporting route, and ask people to use it, whatever the verdict says, when something asks for a password, a payment or a code.

The rate limit

Analyses are limited per hour, counted per network address. Colleagues behind one office internet connection share the allowance. When it runs out, the sidebar says “Too many scans right now. Give it a moment and try again.” The allowance frees up within the hour.

Other errors

• “That message is too large to scan.” Very long messages can be refused.
• “That took too long and was stopped. Try again.”
• “Couldn’t reach the service. Check your connection and try again.”
• “The triage service didn’t respond properly. This is usually temporary.” This appears when the service returns a server error, including when no model produced a usable answer.

In each case no verdict is shown; Try again runs the check again.