You're scanning your inbox. A red banner appears at the top of a message: "This email is from an external sender. Exercise caution." You see it. Your eyes register it. You click through and reply exactly as you would have anyway. So does almost everyone else who saw it today.
That generic warning didn't fail because the user is reckless. It failed because it didn't tell them anything they could actually use.
What decades of warning research has shown
The single most replicated finding in usable-security research is bleak: generic warnings get ignored. The well-known "Alice in Warningland" study by researchers at UC Berkeley and Google found that users clicked through SSL certificate warnings around 70% of the time, and through other browser security warnings at similar rates. NIST's work on usable security has reached the same conclusion repeatedly: vague alerts produce banner blindness. The brain learns very quickly that the warning carries no actionable information, and starts filtering it out — exactly the way it filters out the safety cards in the seat-back pocket on a flight.
What changes the picture isn't louder warnings or scarier colours. It's explanation.
Key insightA warning that says "this is unsafe" asks the user to trust the system. A warning that says "this is unsafe because…" gives the user something to verify, learn from, and remember.
Why specific, contextual warnings actually work
Behavioural science has a name for this. The Elaboration Likelihood Model (Petty & Cacioppo, 1986) describes two paths a person can take when processing a message: a central route, where they actually reason about the content, and a peripheral route, where they react to surface cues — colour, shape, urgency — and move on.
Generic warnings only ever get processed peripherally. There's nothing to reason about. A user sees red, registers "warning", and either dismisses or complies based on whatever they were already going to do.
Contextual warnings — the kind that explain what specifically triggered them — force central-route processing. The user can't dismiss the message without first understanding it. And the moment they understand it, two things happen at once: they make a better decision in this moment, and they get incrementally better at spotting the same pattern next time.
What this looks like in practice
| Generic warning | Contextual warning |
|---|---|
| "This email is suspicious." | "This sender's domain is one character different from your finance team's: fí[email protected] vs [email protected]." |
| "This site is unsafe." | "This site looks like your bank's login page, but the URL is secure-yourbank-login.co, not yourbank.com." |
| "Be cautious of external senders." | "This sender is new to your inbox, is asking you to wire funds, and references a project name that doesn't appear in any internal system." |
| Red banner across the message | A short, plain-language note pointing to the specific feature that triggered concern |
The first column trains the user to ignore the warning. The second column trains the user to defend their organisation.
Why this matters even more now
AI has made attacks contextually perfect. The lure that arrives in your inbox today references your real project, mimics your real CFO's writing style, and lands at exactly the right moment. The defence has to operate at the same level of specificity — a warning that says "be cautious" is bringing a slogan to a knife fight.
Key insightIf the attack is precise about why you should trust it, the warning has to be precise about why you shouldn't.
How we're thinking about this at Mungo Labs
We're building human risk management around contextual, explainable warnings — not generic alerts. When something risky enters a user's flow, the prompt they see explains the specific signal that flagged it, in plain language, in three seconds or less. Not a popup that overwhelms. Not a red banner that gets dismissed reflexively. A short, useful piece of information delivered at the moment a decision is being made — designed to engage thought, not bypass it.
For SMBs without a dedicated security team, this matters even more. You don't have someone standing behind every employee whispering "wait, look at the domain." The warning itself has to do that job — and it has to do it well enough that the user trusts it the next time, and the time after that.
Where to start
Whether you use Mungo Labs or not, the most impactful audit you can run this quarter is on the warnings your tools currently surface. Pick a real warning your employees see this week. Read it as if you were a busy person mid-task. Ask: does this tell me anything I can act on? If the answer is no — and most often it is no — that warning is teaching your workforce to ignore it. Replacing one generic warning with one specific one is a higher-leverage change than another year of training.
If this way of thinking about human risk resonates with you, we'd love to compare notes on what we're building.
Schedule a Discovery Call →