Decoy identities

Monitored decoy identities, three for every email address you protect, seeded into fake credential dumps on the paste sites where stolen ones get traded. They belong to nobody, so the first contact proves someone harvested one and acted on it.

THE PROBLEM

Stolen credentials stay silent. Decoys make them talk.

Stolen credentials are traded and worked out of sight. A dump gets pasted somewhere, scraped and fed into tools and phishing runs, and the people whose addresses are in it hear nothing until it reaches them: a phishing attempt or a password reset they did not ask for, months later, with no idea where it started.

A decoy identity goes into the same kind of dump on purpose. It is an address with a monitored inbox behind it, but it belongs to nobody, it was handed to nobody, and it appears nowhere except in the fake dumps CanaryVaults seeded it into. That is the strength, not the disguise: a real contact has a dozen innocent reasons to email you, and a decoy has none. Any contact at all is proof that someone harvested one of those dumps and acted on what they found. The alert names the platform the mail was after, when CanaryVaults recognises it, and the server that delivered it. The record is sealed in the evidence log. It cannot tell you whether your own address is sitting in a dump somewhere else.

Protect an email address

Add a protected email and CanaryVaults mints three decoy identities for it, one per tier, each with a monitored inbox behind it.

They get seeded for you

CanaryVaults publishes them to the paste sites where stolen credentials are traded, on a delay after minting. You do not place anything yourself.

Get the alert with evidence

An email to a decoy fires an alert with the platform it targeted, when CanaryVaults recognises one, and the mail server that delivered it, with that server's network and location. The record is hash-sealed into the evidence log.

WHAT YOU GET

Everything reports into the same console.

GET https://api.canaryvaults.com/api/canaries
Authorization: Bearer <the web app's own session token>

# → {
#     "canaries": [
#       {
#         "id": "8f1c…",
#         "canary_id": "mfx8k2p-a91ceb04",
#         "tier": 1,
#         "type": "SOCIAL_MEDIA",
#         "email": "james.miller.4f2a91.a91c@canaryvaults.com",
#         "status": "ACTIVE",
#         "created_at": "2026-08-21T09:14:02Z"
#       }
#     ],
#     "count": 1
#   }

Listing your decoys authenticates with the web app's own session token, not an API key. That token lives in memory behind an HttpOnly cookie, so the block above is the shape the console receives rather than a call you can paste. A workspace key from Settings → API keys opens the other five surfaces; it does not open this route. There is no endpoint that creates a decoy either: decoys are minted with the protected email.

Do decoys look real?

Not to a careful reader, and they do not have to. Each decoy goes into a fake combo list as one email and password line among dozens, at an address on a CanaryVaults domain. No real person owns it and it was never handed to anyone, so nothing legitimate has a reason to contact it. One message is enough.

What about accidental contact?

It is hard to reach a decoy by accident. The address is long and unique and was never handed to anyone, so it is in nobody's contacts and no typo lands on it. Anyone other than you who writes to it found it in one of the dumps.