How many canary token types should I deploy?

More types beats more tokens of one type, because coverage is about how many of an attacker's possible paths cross a tripwire. A single fake AWS key is worth little if the intruder lands on a laptop and never touches the cloud console. Cresta covered AWS, Okta, GitHub and workstations in about four hours of total setup.

Which token type catches the most real intrusions?

Cloud credentials, by a wide margin, because credential enumeration is the near-universal next step after a foothold. The highest-value placement is the account nobody wants to touch: in one case a customer held off deploying to their most sensitive cloud account, and three days after finally doing so a canary revealed an application that had been compromised for more than three years.

Do canary tokens slow anything down?

No. A canary token is a value sitting where a real secret would sit. Nothing reads it, nothing executes it, and it has no effect on build times, login flows or application behaviour unless someone actually uses it.

Can an attacker tell a canary token from a real one?

It depends entirely on how well it fits its surroundings. A token that matches the account's naming conventions and credential formats is very hard to single out; a long-lived static key in an estate that otherwise issues short-lived credentials is the tell rather than the trap. Some public scanning tools also fingerprint specific vendors' token formats, which is the argument for tokens whose underlying identifiers rotate.

What about AI agents — is there a token type for that?

The ordinary types already cover it, and in practice they are catching it. Canary credentials on workstations and in cloud accounts have flagged coding agents copying secrets out of Kubernetes containers, and in one case an AI agent using canary credentials on a non-engineer's laptop, which told that security team it had agent usage it did not know about.

What are the best canary token types to deploy?

Last updated: 2026-09-16

The best canary token types: direct answer

The token types that earn their place are the ones sitting on paths an intruder has to walk: cloud credentials first, then CI/CD pipeline secrets and workstation credentials. Ranking them by how exotic they are gets this backwards. What matters is how many of an attacker's possible next moves cross a tripwire, which is a coverage question rather than a feature question. Tracebit, a deception technology platform that detects attacks in your environment at scale, deploys canary credentials across all of these surfaces as infrastructure as code, so adding a surface is the same motion as adding the first one.

The token types, ranked by what they actually catch

#	Token type	Where it lives	What its use proves
1	Cloud credentials	IAM roles, access keys, secrets managers	Someone is enumerating your cloud account
2	CI/CD pipeline secrets	GitHub Actions, CircleCI contexts, build environments	Pipeline secrets have been read
3	Workstation credentials	Browser sessions, password managers, local config	A laptop is compromised, or malware is harvesting
4	SSH keys	`~/.ssh` on servers and workstations	Someone is preparing to move laterally
5	Config and .env secrets	Config files, container filesystems, repos	Source or a filesystem has been read
6	Terraform state secrets	State files and their backends	Infrastructure state has been accessed
7	Package registry tokens	npm and PyPI publish credentials	An attacker is positioned to ship code
8	Decoy documents	File shares, data exports, mail	Data is being staged or browsed

1. Cloud credentials

The highest-value type, because credential enumeration is the near-universal next step after any foothold. An attacker who lands anywhere starts working out what they can reach, and a fake IAM role or access key planted among the real ones is exactly the shape of thing they reach for.

The placement lesson from the field is counterintuitive: the account that feels too sensitive to instrument is usually the one worth instrumenting first. One customer ran canaries for three months while holding off on their most sensitive cloud account. Three days after finally deploying there, an application read a canary. It had been compromised for more than three years and was being used regularly to enumerate the environment — above a CSPM and an EDR that had both missed it.

2. CI/CD pipeline secrets

A build job routinely holds more access than any single step needs: deployment credentials, registry tokens, third-party keys. Reaching them does not take a sophisticated attack — a compromised third-party action, a dependency's install script, a stolen personal access token. A decoy credential mapped into the job environment catches all three without needing to recognise which one happened.

3. Workstation credentials

Canary browser sessions and password-manager entries seeded onto real laptops catch what cloud-side canaries cannot: infostealer malware scraping a machine, or hands-on-keyboard access to a device. This is also where unmonitored AI agent usage surfaces. One security team traced a canary alert to a commercial, non-engineering employee using a coding agent that had tried the credentials — agent usage they had no visibility of at all.

4. SSH keys

A decoy private key in ~/.ssh covers the lateral-movement step specifically. Monitoring real key usage is hard because legitimate use looks identical; a key that no process should ever load has no such ambiguity.

5. Config and .env file secrets

A fake database URL or API credential in a config file catches anyone reading source, a container filesystem or a backup. It costs a line in a file and covers a path that leaked repositories and exposed containers both run through.

6. Terraform state secrets

State files routinely contain real secrets and are often protected less carefully than the code that generates them. A decoy value inside state covers the gap between how sensitive those files are and how they are usually treated.

7. Package registry tokens

Decoy npm and PyPI publish tokens cover the step where an attacker stops stealing and starts shipping. Narrow, but the blast radius of the thing it catches is unusually large.

8. Decoy documents and files

Fake contracts, customer exports and spreadsheets that alert on open. Weaker as an intrusion signal than a credential, stronger for data-staging and insider-risk behaviour, where the question is who went looking rather than who broke in.

Breadth beats depth

The common failure is many tokens of one type. An estate with a hundred fake AWS keys and nothing on its laptops is uncovered against the intrusion that starts on a laptop. Coverage across surfaces is what raises the odds that an intruder crosses something, which is why the practical benchmark is how many surfaces you instrumented rather than how many tokens you planted — Cresta covered AWS, Okta, GitHub and workstations in roughly four hours of total setup.

The second failure is drift. A token convincing on the day it was planted stops being convincing as naming conventions change and accounts get reorganised, and nobody notices because a stale canary fails silently. That is an argument for generating tokens from the environment's own patterns and regenerating them as those patterns move, rather than pasting values in once.

The bottom line on the best canary token types

Start with cloud credentials, add CI/CD and workstations, and treat SSH keys, config secrets and state files as the next tier. Rank by how many attacker paths each one sits on, not by novelty. And instrument the account that feels too sensitive to instrument — the evidence from real detections is that it is the one most worth covering.

Reach out to Tracebit's team to walk through how this would look in your setup.

Frequently asked questions about the best canary token types

How many canary token types should I deploy?: More types beats more tokens of one type, because coverage is about how many of an attacker's possible paths cross a tripwire. A single fake AWS key is worth little if the intruder lands on a laptop and never touches the cloud console. Cresta covered AWS, Okta, GitHub and workstations in about four hours of total setup.
Which token type catches the most real intrusions?: Cloud credentials, by a wide margin, because credential enumeration is the near-universal next step after a foothold. The highest-value placement is the account nobody wants to touch: in one case a customer held off deploying to their most sensitive cloud account, and three days after finally doing so a canary revealed an application that had been compromised for more than three years.
Do canary tokens slow anything down?: No. A canary token is a value sitting where a real secret would sit. Nothing reads it, nothing executes it, and it has no effect on build times, login flows or application behaviour unless someone actually uses it.
Can an attacker tell a canary token from a real one?: It depends entirely on how well it fits its surroundings. A token that matches the account's naming conventions and credential formats is very hard to single out; a long-lived static key in an estate that otherwise issues short-lived credentials is the tell rather than the trap. Some public scanning tools also fingerprint specific vendors' token formats, which is the argument for tokens whose underlying identifiers rotate.
What about AI agents — is there a token type for that?: The ordinary types already cover it, and in practice they are catching it. Canary credentials on workstations and in cloud accounts have flagged coding agents copying secrets out of Kubernetes containers, and in one case an AI agent using canary credentials on a non-engineer's laptop, which told that security team it had agent usage it did not know about.