Phishing Check

Hand it an email; it tells you whether the email is genuine or phishing — and why, using the same forensic signals a security analyst would check.

Why this works

Phishing has gotten good enough that you can't judge an email by how it looks. The reliable signals live in the headers, not the wording:

• SPF / DKIM / DMARC — Google already verified these when the message arrived and recorded the result in the Authentication-Results header. A DMARC pass with p=reject means a spoofed sender would have been bounced before it reached you.
• Identity mismatches — a real bank email won't have a Reply-To pointing at a free webmail address, or a DKIM signing domain unrelated to the visible sender.
• Link domains — the displayed text says one thing; the actual URL domain says another.

This workflow extracts those facts and lets the AI weigh them, instead of guessing from tone.

What it does

1. fetch — the Google Workspace tool pulls the full Gmail message as JSON (gmail get <id> --format full). Because it's the full message, the complete raw header set comes along, including Authentication-Results, Return-Path, and Reply-To.
2. assess — Claude reads the headers + body and returns a verdict: GENUINE / SUSPICIOUS / PHISHING with a confidence level, a table of the checks (SPF, DKIM, DMARC, sender vs reply-to, link domains), short reasoning, and a recommended action.
3. notify — the verdict is sent to you on your InTouch channel.

No scripting, no header-parsing code — the GW tool reads, the AI judges.

Setup

1. Credentials

• <<GOOGLE_WORKSPACE_CREDENTIAL>> — a Google Workspace credential with Gmail read access. (Read-only is enough; this workflow never modifies, labels, or deletes mail.)
• <<ANTHROPIC_CREDENTIAL>> — an API key for any supported AI provider (Anthropic, OpenAI, Gemini, Mistral, Ollama or OpenRouter) credential.

2. Placeholders in workflow.iml

• <<MESSAGE_ID>> — the Gmail message id to assess.
• <<NOTIFY_USER>> — who receives the verdict (e.g. intouch).

3. Getting a message id

Run this workflow on demand against a suspect message. To find an id:

gog gmail messages search "from:suspicious-sender newer_than:2d" --max=5 --plain

(the first column is the message id), or grab the id of whatever message you want checked.

Provider flexibility

The assess step uses the anthropic tool, but it's pure reasoning — swap it for openai, gemini, or a local ollama model by changing the tool name and credential. The prompt stays the same. Local models keep the email contents entirely on your network.

What it won't do

• Batch-scan a whole inbox. v1 assesses one message by id — the "I just got this, is it real?" case. A scanning variant (search a label or is:unread, assess each, label the suspicious ones) is a natural follow-up but reintroduces a per-message loop; kept out of v1 on purpose.
• Move, label, or delete mail. It only reads and reports — so read-only Gmail scope is sufficient and the workflow can never touch your mailbox.
• Click or fetch links. It analyzes link domains from the headers/body; it never visits them. The verdict always tells you to navigate to a provider directly rather than click the email's link.
• Catch a perfectly-authenticated email from a compromised legitimate account. If a real account is hijacked, SPF/DKIM/DMARC all pass. The AI still flags suspicious pretext/links, but auth-passing mail from a takeover is the hardest case for any tool.

AI cost

One assessment is a single Claude call: roughly the email's size in prompt tokens (typically 2–8k) plus ~400 response tokens. A few tenths of a cent per check on Claude Sonnet. Run it only on the emails you actually want vetted and the cost is negligible.

AI provider

Any supported AI provider works here. This template ships configured for the anthropic tool; swap that task's tool to anthropic, openai, gemini, mistral, ollama or openrouter to use the provider you already have, and point its credential at your own key. The step is a plain summarise/classify call — nothing in it is vendor specific. See requires.ai in the manifest.