Decoy identities

Monitored decoy identities, minted for every email address you protect and seeded where stolen credentials get traded. Nobody else has them, so the first contact is proof — and it names the address the leak came from.

THE PROBLEM

Stolen credentials stay silent. Decoys make them talk.

When one of your addresses is harvested, nothing happens at first. It gets traded, pasted into a dump, and sits in a list until somebody decides to use it. You find out at that point — months later, from a phishing attempt or a password reset you did not ask for — with no idea when it leaked.

A decoy identity turns each address you protect into its own alarm. It carries a person's name and a live monitored inbox, but it belongs to nobody, it was handed to nobody, and it exists nowhere else on earth. 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 the address it was minted for has been harvested — with full headers, sender infrastructure, and a sealed timestamp.

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

Any message to the decoy fires instantly: sender, IP, ASN, full headers, and message body — 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 Supabase session JWT>

# → {
#     "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 a Supabase session JWT, not an API key — and that token belongs to the web app, kept 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?

Each decoy is a real monitored inbox with a person's name on it, so it reads like an ordinary entry in a credential dump. 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?

If a colleague emails a decoy by mistake, you'll see it immediately in the capture — internal senders are easy to distinguish from an unknown proxy exit node. Mark it a false positive; the sealed record stays intact either way.