What Is a Canary Token? A Tripwire That Costs Nothing and Only Fires When You Are Already Wrong

Most security tools try to answer a hard question: is this activity malicious? They inspect, they score, they guess, and they produce false positives.

A canary token answers an easy question instead: did anyone touch the thing that nobody should ever touch?

That is the whole idea, and the reason it works is that the answer is never ambiguous.

What it actually is

A canary token is an ordinary looking object placed somewhere it has no reason to be used, wired so that any access to it notifies you.

• A document named 2026-salaries.xlsx in a share, containing nothing, that calls home when opened.
• An AWS key pair that grants no permissions, sitting in a config file, that alerts when someone tries to authenticate with it.
• A URL that appears in a comment, a robots.txt, or an old backup, that logs every request.
• A DNS name that resolves only when something looks it up.

None of these has a legitimate consumer. The signal is not “suspicious behaviour”, it is “an event that should have a zero rate”.

Why the false positive rate is the point

An intrusion detection system watching real traffic must distinguish normal from abnormal, and normal is enormous, varied and constantly changing. That is why alert fatigue exists: a rule tuned tight enough to catch attacks catches your colleagues too.

A canary token has no normal. Its expected event count is zero, forever. One hit is one hundred percent of its history, which is why a canary alert is worth waking up for and a generic alert usually is not.

The trade off is honest and worth stating: a canary detects nothing until an attacker interacts with it. It is not coverage, it is a tripwire. An intruder who takes what they came for and never opens the wrong file walks past it.

Where to place them, in order of usefulness

In the file share nobody browses. A document with a name an attacker doing reconnaissance cannot resist. This is the classic placement and it catches the exact behaviour of someone who has landed and is looking around.

In a config file, as a credential. A key that looks real, grants nothing, and alerts on use. It catches credential harvesting, which is what happens between the initial access and the part you actually care about.

In a backup. Backups get exfiltrated whole and opened later, sometimes months later, often on a machine that is not yours. A token in a backup tells you the backup left.

In your own codebase. A token in a private repository fires if the repository ends up somewhere it should not.

On a workstation, in the browser profile or the documents folder. This is the one that catches an infostealer, and it is the placement most people skip.

The two ways people ruin them

Making them attractive to legitimate users. A file called passwords.txt on a shared drive will eventually be opened by a curious colleague, and the alert that follows teaches you to ignore the next one. The placement has to be somewhere with no legitimate traffic, not somewhere with tempting content.

Not deciding in advance what happens when it fires. A canary that alerts to an inbox nobody reads is a canary that fires into silence. Before you place one, write down who is called and what the first three actions are. A tripwire with no response plan is decoration.

There is a third, smaller trap: token services report the IP address and user agent of whoever triggered them, and that is genuinely useful, but it is not proof of identity. An attacker behind a VPN gives you the VPN’s address. Treat the alert as “something happened”, not as attribution.

Setting one up

Public services generate them for free, and self hosted options exist if you would rather the beacon report to infrastructure you control. Either way the mechanics are the same: generate, place, name it in a note so future you knows where it is, and test it once so you know the alert path works end to end.

Test it. The most common failure is a token that was never verified and does not fire, which is indistinguishable from a token that was never triggered. That is the same class of defect as any silent control: a green light that means nothing.

Where it fits

A canary token does not replace anything. It sits alongside your existing detection and answers a different question, and it costs a few minutes rather than a licence.

The reasoning about what you are defending and against whom is in what is a threat model. If a canary does fire, the investigation route is in how to check if a Linux server is compromised, and the persistence mechanisms worth auditing at that point are in Linux audit log commands.