Decoy credentials that look real and grant next to nothing, placed where intruders and their agents go looking. The first use tells you where they are and when they were there, with the source address whenever the platform records one.
Threat actors now hand the tedious part to agents: sweep a foothold for credentials, try each one, map what it opens. A git token is the prize, because source access is where the next moves come from — vulnerabilities to exploit, secrets to harvest, and a copy of the codebase to hold for extortion.
An agent does not weigh whether a token looks suspicious. It finds a credential, it uses it, it moves on. That reflex is exactly what a decoy is built to catch: a token that exists only to be picked up, in an environment where nothing legitimate ever would.
They enumerate. Every file, variable and log that might hold a secret gets read, so a decoy in any of them gets read too.
They validate. A found token is tried against the platform to see what it opens. That single call is the alert.
They are fast. Minutes from foothold to harvest, which is why the signal has to come from the first touch, not from a pattern learned over weeks.
Once a credential is in hand, everything an intruder does looks like ordinary work. Repos get read, code gets cloned, releases get published. No rule fires, because no rule was broken.
The build pipeline is where those credentials live, and it is where this year's supply-chain compromises went. A decoy credential placed there is the one thing in that environment only an attacker would ever touch.
A workflow let untrusted pull-request code run with credentials in reach. The alert that told them came from a canary token.
Malicious releases pushed straight to PyPI after a security scanner inside the CI pipeline was compromised.
Malicious releases published from the project's own trusted workflow, via a cache-poisoning chain in GitHub Actions. No password was stolen.
Create a decoy secret from the console. It has the shape and prefix of a real credential and access to nothing.
Put it where someone would go looking — a config file, a CI variable, an internal runbook, a stale branch. You record the placement in your own words; that is what the alert will name.
The first time it is used, your team gets an email naming the placement and the time, with the source address whenever the platform records one. The canary's page keeps every use after that.
A token only works if it sits where someone would go looking. These are the places attackers and their agents search first; your team decides which ones are in scope. GitLab project tokens today; GitHub is in development, with more token types to follow.
A decoy credential has no legitimate use in your estate. If it fires, someone found it. There is no tuning phase and no baseline to learn.
A token is a string. No agents on endpoints, no sensor fleet to maintain, no change window to negotiate with platform teams.
The alert names a placement in your own words and a time. That reads the same to the engineer who triages it and to the board that asks what was touched and for how long.
A CI variable nothing legitimate reads. The pipeline runs exactly as before; the first job, script or person that does read it has told you where they are.
We will sit with your detection team, pick the placements together, and be on the call when the first alert lands. If nothing fires, you have lost a week and learned where your blind spots are not.