Canary tokens: cheap tripwire detection for small teams

A canary token is a decoy, such as a fake credential, document or link, placed where nobody legitimate should touch it. When someone does, you get an alert. It is one of the lowest effort detections a small team can run, because a touch is almost always worth investigating.

How they work

The Canarytokens documentation compares them to motion sensors for networks, computers and clouds. They are free to create, need no installed software or background processes, and are designed to look attractive to an attacker. You place one where "nobody should be poking around," and access triggers the alert.

The guide lists many token types, including documents and files (PDF, Word, Excel, network folders), cloud and identity items (AWS API keys, Entra ID login, Kubeconfig), web and network items (DNS, HTTP, cloned websites, QR codes), and data items such as a MySQL dump or a fake email address. At the time of writing it also lists an MCP configuration token and a sensitive command token, which suit environments with AI coding agents.

Why they are cheap detection

Most alerts are noisy because they watch normal behavior and try to spot the abnormal. A tripwire inverts that. There is no normal use of a fake cloud key in a file named for production credentials. So the false positive rate is low and each alert is high value, assuming you place them carefully.

Where to put them

1. A fake credentials file in a repository or on a file server, named plausibly.
2. A decoy cloud key in a developer home directory or CI settings.
3. A decoy kubeconfig on bastion hosts.
4. A sensitive looking document in a shared drive folder.
5. A DNS or HTTP token embedded in an internal wiki page about secrets.
6. A fake database dump where backups sit.

Spread them across places an intruder would search after landing: home directories, shared drives, source trees and build servers.

Operating rules

• Decide who gets the alert and what they do first. An alert nobody reads is decoration.
• Document each token in a private register: location, purpose, owner.
• Avoid accidental triggers. Tell the backup and scanning teams, or an indexer will trip your own tokens. Secret scanners may also flag a decoy credential, which is fine, but make sure someone knows it is intentional.
• Rotate and check. Confirm a token still fires by testing it quarterly.
• Do not put real secrets in the decoy.

What they cannot do

They do not stop an attack. They only tell you someone is poking around. They will not catch an intruder who never opens the decoy, or one who uses a legitimate stolen session. Treat them as one layer next to proper logging and alert rules built from your logs.

Handling a trigger

1. Capture the alert details: time, source address, user agent or resource touched.
2. Check whether it was an internal scan or a known test.
3. If not, treat the host or account where the decoy lived as suspect and pull its logs.
4. Preserve evidence before changing anything.

Quick check

Sources

• Canarytokens guide

Last reviewed: 19 October 2026.