Plant something worth stealing.

A canary token is a marker with a defined trigger. Depending on the type, that trigger might be a request to a URL or an attempted API call using a planted credential.¹ Reading the surrounding file is a different event. So is receiving the archive that contains it.

The name “tripwire” makes the idea sound simpler than the design decision really is. The operator has to choose where in the sequence the wire sits.

Start with the sentence#

Before choosing the token, write the sentence its alert should support. “Someone stole the backup” is too loose. “An API request was attempted using the marker placed inside this archive” names an event that can be checked against a record.

That sentence determines the instrument. If the question concerns attempts to open an archive, a key inside it is too far downstream. If the question concerns attempted use of something found inside, the key has a job.

Return to the fictional CSV importer from Part 1. Its backup has several observation points:

These are separate records. Keep them separate even when a dashboard makes it easy to collapse them into one label.

Give it an ordinary place#

Bait needs a reason to be where it is. A backup for the importer belongs beside material used to operate that service. An archive full of unrelated credentials asks the visitor to accept a much larger story.

Choose one useful item and support it properly. If the archive claims to contain configuration, its filenames and contents should agree with that claim. Use synthetic material and a purpose-built marker whose behavior and permissions have been checked. Real customer data and working production credentials have no place in the exercise.

An attractive item also changes the question. A credential labeled as an administrator’s key invites different actions from one described as a narrow import-service credential. If the label changes between revisions, record that too. The name is part of what the visitor was offered.

Placement advice is familiar. The neglected work is keeping track of where each copy went. A marker reused in a directory listing, a web response and an archive can report an event without resolving which placement led to it.

An alert has a history#

Suppose the importer’s archive produces a token alert. The first task is to recover its placement record and check the trigger. Then look for the preceding exchange in which the archive was offered and requested.

Keep operator tests distinguishable from unsolicited activity. A functional test can produce a valid alert that has nothing to do with a visitor. So can authorized tooling that reaches the marker. “The token fired” is a starting point for reading the record, not a complete explanation of it.

There is a useful asymmetry here. A distinct marker can tie an alert to a particular planted object. It cannot, by itself, establish that the same person requested, inspected and used that object. Copying and forwarding break that shortcut.

That limitation does not make the alert weak. It makes the useful claim precise: this marked material was involved in this observed action.

Read the silence at the right point#

An empty inbox says the trigger was not observed. Work backward before deciding the lure was ignored. Was the archive offered? Was it requested? Did the decoy deliver it? Has the alert path been tested, including any delivery delay documented for that token?

If the file was never offered, changing the token will not fix the experiment. If the archive was delivered and the marker stayed quiet, retain that distinction. The next revision needs to address the question at that boundary, rather than make the bait louder everywhere.

The importer now has a specific offer and separate records of what happened to it. The operator can describe an attempted action without making the token tell a story it cannot support. Part 3 turns to the reading queue: which exchanges get attention, and what disappears when the rest are filtered out.