Canary credentials and decoy files: detecting that someone read what they should not

Goal

Get a reliable signal when something reads or uses secrets it has no business touching, including an agent following injected instructions.

Prerequisites

A way to issue decoy credentials or URLs that alert on use (a canary-token service or your own issuer with alerting), and an alert channel someone watches.

Steps

1. Choose decoy types. MITRE D3FEND describes decoy files as a deception technique; token services such as Canarytokens generate artefacts that alert when used: cloud access keys, URLs, DNS names, documents that call home when opened.
2. Place them where a curious process would look: ~/.aws/credentials with an extra profile, a .env file in a project directory, a "backup" config next to the real one, a password-manager export in a documents folder.
3. Make sure no legitimate process touches them: exclude the paths from backups and indexers that would open them, or you train yourself to ignore alerts.
4. On the host, add file-read auditing for decoy files (for example Linux audit rules on the path) to catch reads that never lead to use.
5. Write the response in advance: what an alert means, who looks, which session or container was active, which credentials to rotate.
6. For agents: plant a decoy in the agent's workspace and include it in red-team runs; a triggered canary during an injection test is concrete evidence the agent read and exfiltrated it.
7. Test each canary once after placement and record that it alerts.

Expected result

Unauthorised reading or use produces an alert with time and context, usually earlier than other signals.

Limits and test basis

Canaries detect only access to the decoy; an intruder who goes straight for real secrets is not caught. Maintenance tools, backups and your own scripts can trigger them, and every false alarm lowers attention. A token-based canary sends metadata to the token service; choose a provider or self-host accordingly.