A credential leaks. Weeks later, somebody tries it. That request either works or it fails quietly, and you learn about it later from a breach.
C1 provides credential security that covers a variety of use cases, including protecting you from credential theft via decoys. A decoy is a real, working credential minted by C1 that belongs to no legitimate workload, and you put it where a real secret would sit: a .env
file on a build box, a CI variable, an entry in your secrets manager. What happens when someone uses it? Let's find out.
Before anything happens: the plant# #
You create a decoy in C1 and choose what it should impersonate. The current set covers what actually leaks in agentic environments: a person's client credential, a service principal's, a connector client, a workload federation trust, or an access token. Each one is minted by C1's own authentication stack, which is what makes the whole thing work; a decoy authenticates against endpoints C1 already watches, so any use of it anywhere in the world is observable to you.
C1 shows you the secret exactly once and hands you a SHA-256 fingerprint of the material. The fingerprint and location tie an alarm months later back to one specific .env
file on one specific host.
C1 makes it easy to track this by tagging a decoy when you create it. Those tags aren't decoration, they're copied verbatim onto any finding the decoy produces. This means a routing rule can condition on the same keys you set at plant time. For example, you may tag a decoy location: ci-runner-prod
and can route to the platform team when needed.
This is further protected by limiting access to decoy records, so only super admins can manage these decoys.
The request arrives# #
Someone posts to the token endpoint with the client ID and secret they found. From there:
The first gate is plain cryptographic validation, the same check every credential gets. If the secret doesn't match, no decoy has been used. The request is an ordinary failed authentication and nothing fires. No fuzzy matching, no near-miss heuristic, no scoring.
A decoy fires on successful validation and on nothing else, which means the caller was holding the actual secret. Meaning they had access to the place you put it. They can't guess a decoy and a misconfigured service won't accidentally present one, so you know this finding is real.
On the next step, the credential row is loaded, C1 sees that it carries a decoy marker and two things immediately happen.
What the caller sees: nothing# #
The response is invalid_client
or invalid_grant
, depending on what they used. Either way it's the same standard OAuth error they may get if the key had simply been rotated or if they entered a typo. No indicator to the caller that they were using a decoy.
This is deliberate. While it would be satisfying to return something pointed, an attacker who has scraped a dozen credentials off a compromised host is going to try all of them, and if decoys answered differently from dead keys, that difference would reveal the traps right away. Then the trap becomes a filter that improves the attack.
So the decoy gives up nothing. Their tooling records a dead credential and they move on, which is exactly the behavior you want while you're reading their user agent.
What you see: a critical finding# #
On your side, C1 raises a Decoy credential used
finding at CRITICAL severity, tagged with the decoy that fired and the kind of credential it was impersonating.
Severity here isn't the output of a risk model. It's structural. Every other identity signal is a judgment call about whether something looks wrong; this one is a record that somebody used a credential that exists for no other purpose than to be stolen.
The finding carries the forensic detail you want in the first five minutes: when it happened, the source IP, the user agent string, which endpoint they hit, and the full raw event, so it ports into your SIEM without a translation layer. And it arrives already carrying the tags you set at plant time, so your routing rules can send a hit on a production secrets-manager plant somewhere very different from a hit on a decoy sitting in a sandbox.
The second attempt, and the third# #
Attackers rarely try once. The first hit opens the finding; a second hit while it's still open appends an attempt and updates the evidence rather than opening a duplicate; a hit after you've resolved it reopens the original.
The attempts view deliberately excludes lifecycle noise. Owner changes, snoozes, and comments all live in the audit trail, but they don't belong in the same table as attacker activity, because burying four real attempts among eleven workflow events is how a timeline stops being readable. One finding is one campaign against one plant, top to bottom, with an IP and a user agent on every row.
Why a finding rather than an alert# #
Canary tokens have existed for a long time and they mostly work fine as detection. The problem is how they're managed. Often a deterministic signal landed in a shared mailbox and then depended on somebody's Tuesday.
A finding is a record with an owner, a severity, routing rules, an audit trail, and a condition under which it closes. It lands in the same queue as the rest of your identity risk, and it produces the same audit evidence as an access review. That's the actual difference between a decoy in C1 and a canary token: not how the trap is built, but that tripping it starts a workflow with a name attached to it in the same place where the work gets done.
The decoy that fires without anyone using it# #
There's a second finding type that protects your business. Decoy publicly exposed
fires when a scanner reports one of your planted decoys somewhere public, a paste site or an open repository, and nobody has authenticated with it at all.
The evidence names which scanner saw it first, when, every scanner that has reported it since, the kind of source and its URL, and a fingerprint prefix confirming which plant it was.
Nobody used the credential, so on the surface nothing happened. What actually happened is that the file it was sitting in left your environment, and every real secret that was beside it should now be treated as compromised. The plant told you about an exfiltration you had no other way to see.
The response is also different from what your instincts suggest. You don't revoke a decoy; revoking it converts a working trap into a dead key while leaving the attacker's copy in circulation. You replant it: fresh material, same location.
Anatomy of a decoy# #
A decoy credential is a real, working secret you intentionally "plant" where attackers (or overly-permissive agents) are likely to find it—in a .env
file, CI variable, or secrets manager entry. If someone uses the decoy, it only "fires" on successful cryptographic validation, returns a standard OAuth failure to the attacker, and creates a critical finding for you with the key forensic details.
C1 treats this as a managed workflow, and also alerts if a decoy is publicly exposed even if it hasn't been used, signaling likely exfiltration. Decoys help protect the business, and they're one more tool in your arsenal when managing a fast-changing environment.
Want to see how it works in your own environment? Book a demo. Adopt AI, fearlessly.