Honey token

What it is

A honey token is a fake credential designed to be discovered and used by an attacker, not by your application. It looks like a real secret (same format, same shape, same character set), but no system actually accepts it for anything. The only thing it does is fire an alert the moment someone tries to use it. Often the alert is paired with automated containment that revokes related credentials, freezes the affected scope, or wakes up an on-call human.

The idea inverts the usual security posture. Most controls try to prevent attackers from getting in. Honey tokens assume someone already got in and want to know about it as fast as possible. The economics are excellent: a single fake string in a config file costs effectively nothing, and an attacker rummaging through a dump or a compromised laptop is overwhelmingly likely to try it before they find anything genuinely valuable.

Where the name comes from

The term descends from "honeypot", the family of decoy systems researchers use to study attacker behavior (popularized by Lance Spitzner and the Honeynet Project in the early 2000s). A honey token applies the same idea at credential scale: instead of a whole fake server, a single fake secret that does nothing except scream when touched.

The aliases "canary token" and "canary secret" come from a separate metaphor: the canary in a coal mine that fails first so the miners get warning. Same idea, applied to credentials. Thinkst's Canarytokens service, launched in 2015, popularized "canary" as the dominant industry term, though "honey token" remains common in academic and InfoSec literature.

Common shapes

• Fake API keys. A string matching the format of a real service token (AKIA..., sk_live_..., xoxb-...) committed somewhere an attacker would look: environment files, internal wikis, build artifacts.
• Fake AWS credentials. AccessKeyId + SecretAccessKey pairs that look real but resolve to a tracking endpoint instead of AWS. Dropped into config files, Lambda environment variables, or terraform state.
• Tracking documents. Word, PDF, or Excel files with unique IDs that phone home when opened. Useful as bait in shared file stores.
• DNS callbacks. A unique subdomain that resolves to your tracking infrastructure. Any DNS lookup tells you the file or image containing it was opened.
• Fake database connection strings. A connection string that points to a logger instead of a database. Attackers attempting to connect get logged before they get an error.

The shape doesn't matter as much as the placement. A honey token in a file an attacker won't find is useless. A honey token next to your real credentials, in a path an attacker is likely to grep, is what generates signal.

What you actually get from one

The signal a tripped honey token produces is unusually rich for a security alert:

• Confirmation that you've been breached. Tripped honey tokens are nearly all true positives. Nobody legitimately tries to use a credential that doesn't exist.
• Where. The IP the access attempt came from. If the token was scoped to a specific file or laptop, that narrows the leak point.
• When. Timestamped to the second.
• What they're doing. A read attempt vs. a write attempt vs. a privilege escalation attempt tells you which playbook the attacker is running.

A well-placed honey token can detect a breach hours or days before security tooling notices anything, because tooling watches what an attacker does to live systems while a honey token reports what an attacker tries even when nothing live was touched.

How SikkerKey handles it

In SikkerKey these are called canary secrets. A canary secret is a normal secret in your vault flagged as a canary; it sits next to your real secrets, in the same projects, granted to the same machines. When an attacker or a misconfigured app reads it, two things happen in the same transaction before the response goes out:

1. The attacker still receives the canary value. Stealth is preserved. They don't know it was a canary; they think they've successfully exfiltrated a real credential.
2. The project freezes. Every subsequent request against that project returns HTTP 423 Locked until you unfreeze it from the dashboard. No more secrets leave the vault from that scope.

You can opt into lateral containment. If the offending machine has access to other projects in your vault, the canary can freeze those projects too, so an attacker who already pivoted to additional grants is contained at the moment of the trip. Cross-vault projects are never touched.

Audit entries record exactly which canary was tripped, which machine did it, from which IP, and which projects froze. SikkerKey's alert dispatcher fans the event out via email and webhooks at CRITICAL severity, so wiring it into Slack, PagerDuty, or your incident tooling is one webhook URL away. The trip count and last-trip timestamp live on the canary itself, so you can see which canaries have ever fired and which ones might be sitting in the wrong place.