Deception Technology: Canaries from Past to Present

From honeypots to cloud canaries: a short history

Deception as a category has been quietly reinventing itself as company environments reinvent themselves, always in the same direction: lighter, cheaper to run, and closer to where the defender actually lives. Following that line explains why the cloud version has to look the way it does.

The honeypot era

The first packaged honeypot software, Fred Cohen's Deception Toolkit, shipped in 1997, which puts the honeypot at roughly thirty years old. The practice is older than the software itself. In 1986 Clifford Stoll, a systems administrator at Lawrence Berkeley Laboratory, chased a 75-cent accounting discrepancy into a live intrusion and ended up planting fake files to keep the intruder online long enough to trace him. In January 1991 Bill Cheswick, an engineer at AT&T Bell Labs, spent a month watching an attacker he named Berferd inside a deliberately constructed fake environment, and wrote it up for USENIX the following year. By 1999 Lance Spitzner's Honeynet Project had turned all of this into an organized research discipline with published methodology. Both roots are practitioners solving a problem in front of them. The original idea was elegant and ambitious: stand up a whole fake system, a machine that emulates real hosts and real services convincingly enough that an attacker interacts with it, and then watch everything they do.

A well-built honeypot was a laboratory of sorts. It let defenders and researchers study live intrusions, capture novel malware, and learn attacker tradecraft in detail, all inside a system that had no legitimate users and therefore no legitimate reason to be touched. The benefit was the richness in forensic details, being able to capture every single move, read, keystroke, and file transfer. That idea of having a “thing” that nobody should legitimately access is the seed of everything that follows, the same mechanism the whole discipline still runs on: a resource nobody should be interacting with, so any interaction is meaningful by definition.

Honeypots were, and are, genuinely powerful. But a full decoy system is heavy. Somebody has to build the fake host, make its services behave convincingly, keep it isolated so it cannot be turned into a launch pad against the rest of the estate, and monitor it closely enough to extract the value. That is real, specialised, ongoing work, and it kept high-interaction honeypots mostly in the hands of researchers and a few very well-resourced security teams. So while the insight was proven, the operational cost was the barrier.

The canary and the canary credential

The next move was subtraction. If the whole value of the decoy is the alert that fires when something touches it, you do not need a fake system at all. You need one planted thing that alerts the instant it is touched.

The data version came first. The term honeytoken was coined by Augusto Paes de Barros on the honeypots mailing list on 21 February 2003, and Lance Spitzner wrote it up as "Honeytokens: The Other Honeypot" later that year. A honeytoken is not a host. It is a piece of planted fake data like a credential, a file, a database record, or an API key that sits quietly inside a real system and reports the moment anyone uses it. Twelve years later the same idea reached most practitioners under a different name, when Thinkst shipped its Canary product and launched canarytokens.org in 2015. Canary is the name most defenders learned it by, but the mechanism it describes had been running under another name for over a decade.

Note: what the industry referred to as a honeytoken in 2003 is what we call a canary token in this guide and in our product.

This changed the economics completely. A canary carries almost none of the operational weight of a high-interaction honeypot. There is no fake operating system to maintain, no services to keep convincing, no isolation problem of the same magnitude. You lose the deep forensic laboratory of the full decoy system, but you keep the thing that matters most for detection: a high-fidelity signal with a near-zero false-positive rate. The first canary became easy to stand up. Keeping it believable is the harder long-term work.

The on-prem and appliance era

The canary and honeytoken model reached most practitioners through the on-premises, network-and-appliance world. A box you rack on your network, or a token you place by hand where a credential might plausibly leak, was a real leap forward. Ask security engineers who ran one and you will hear genuine affection, because the products worked and they made a powerful idea approachable for the first time. It was excellent work, and it remains excellent within the world it was designed for.

What happened next is the most useful thing in this section. A commercial deception wave built up through the second half of the 2010s and by 2022 all of it had been absorbed. Attivo Networks was acquired by SentinelOne in May 2022 for $617 million, largely for its Active Directory work. Illusive was acquired by Proofpoint in December 2022 and repositioned as identity threat detection. TrapX was acquired by Commvault in February 2022 and folded into a backup product. By the end of that year every major standalone deception platform sat inside a larger vendor.

The delivery model was built for a world of racks, network segments, and hand placement.

Why the cloud broke the old model

Cloud did not make deception obsolete, far from it. It made the mechanism more relevant than ever, because identity-and-API-driven intrusion is exactly the unknown-unknown that deception is built to catch [link: Section 1, the detection gap]. What the cloud broke was the delivery model, the assumption that a decoy is a physical or hand-placed thing in a stable network. Four properties of modern cloud environments each break that assumption on their own.

Infrastructure is ephemeral. Hosts live for minutes. Containers and functions come and go by the thousand. A decoy that assumes a stable, long-lived machine has nothing to attach to in an estate that recycles itself constantly.

The attack surface is identity and APIs, not network segments. Attackers do not cross a perimeter; they arrive holding a valid credential and move through IAM roles, access keys, and API calls. The interesting decoys are now identities and API-reachable resources, not boxes on a wire.

Environments are defined and redeployed in code. Infrastructure-as-code means the estate is described in Terraform or CloudFormation and can be torn down and rebuilt nightly. A hand-placed decoy that is not in that code is gone the next time the environment redeploys, or it lingers as the one artifact nobody's template accounts for, which is its own kind of tell.

Scale is multi-account and multi-cloud. Not one network but hundreds of accounts, often across more than one provider. Hand placement does not work at that scale. You cannot manually seed and maintain believable decoys across four hundred accounts and keep them consistent.

A hardware appliance and a hand-placed decoy simply do not map onto an environment that redeploys itself nightly across hundreds of accounts.

The result

So the history lands somewhere specific. The mechanism is sound and, if anything, more valuable in the cloud than it ever was on the network. What has to change is how deception is built and delivered. Deception in the cloud has to be cloud-native: API-driven, deployed as infrastructure-as-code, continuously evolving, and most recently digitally camouflaged using AI to keep pace with an environment that never holds still. A decoy is only believable relative to what surrounds it, so its naming, its contents, and its metadata have to match the account it sits in, and that account changes every week. This constantly moving environment means the decoy has to be regenerated rather than written once. A decoy that cannot be deployed through the same pipelines as everything else, cannot scale across every account automatically, and cannot stay fresh as the environment shifts is a decoy that is missing, stale, or obvious within a couple of months, and often far sooner.

Why deception matters more now than ever

So far we've shown that deception detects what other controls cannot: the unknown unknowns. The threat environment has since moved in a direction that plays directly to those strengths. Attacks are getting faster: CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed run at 27 seconds, and records an 89% year-on-year rise in AI-enabled attacks. More importantly, attacks are getting harder to define in advance.

Two shifts have rapidly changed the criticality for deception technology. The first is AI-assisted attacks and the second is compromise through the software supply chain. The latter has been around for a number of years, but the former is making it an even more severe problem.

AI-assisted attacks: the reaction window is closing

Most detection strategies today assume there is a human orchestrating an attack, assisted by some automation but working at human speed. Someone lands a foothold, looks around, thinks, tries a few things, and with some luck escalates their privilege. That cadence is what gives a defender room to notice something, correlate it, and respond before it matters. Unfortunately, that assumption is becoming unsafe.

Now, we want to be careful about jumping on the fear-mongering bandwagon but we do know that AI-assisted attacks are drastically cutting down the speed with which someone is able to gain access to privileged accounts and eventually exfiltrate data. We’ve been testing this ourselves if you’d like to see the research so far: https://agentic.tracebit.com/

In April 2026 the UK's AI Safety Institute evaluated Claude Mythos Preview against a 32-step attack range running from reconnaissance to full corporate network takeover. The model completed the chain end to end in 3 of 10 attempts and averaged 22 of the 32 steps, working with a 100-million-token budget per attempt against a human baseline of roughly 20 hours. The range had no live defenders and no EDR, so read it as a capability measurement rather than a rehearsal of your environment. For the number that actually bears on a defender's reaction window, our own testing showed that across 951 runs, agents reached admin privilege escalation in an average of 14 minutes. Read that against your mean time to detect, then against your mean time to respond. For most organizations the intrusion is finished before the first alert has been triaged. When a kill chain fits inside the gap between two shifts, a detection model whose value depends on a human noticing an anomalous pattern in time has a problem that no amount of tuning fixes. The attacker is in and out with your data before you even knew what happened.

Speed is only half of the equation. Our more useful observation is what agents do with that speed and time. A human pentester works one thread at a time: spin up a scanner, read the results, choose an exploit, run it, then decide what to do next. An agent can run fifty of those threads at once and still make a judgement call at the end of each one. That is orchestration at machine speed rather than through sheer brute force. AISI has disclosed a case where an agent attempted to compromise an open-source repository by submitting malware in a pull request, with separate agents backing it up in the review thread. That is a very real social-engineering play. So now we have to look at the breadth an attacker can afford. The HuggingFace intrusion produced roughly 17,000 events over four days. An agent working at that volume covers ground a careful human intruder would skip, because it can afford to look at all of it.

That breadth is precisely what a canary is built to catch. The whole mechanism rests on there being no legitimate reason to touch the decoy, which makes any touch worth acting on by definition and leaves close to nothing to triage. An attacker covering ground at that scale will, by construction, hit the decoys along with the real assets. In our own testing, canaries alerted before the attacker's first critical action in 95.9% of 951 runs, a median of eight minutes ahead of it. The property that makes agentic attacks fast and thorough is the same property that walks them onto the tripwire.

Then there is a finding we did not expect. In testing AI-driven attackers, simply signalling to the agent that deception might be present dropped the full-compromise rate from 20% to 3%. The environment was the same in both cases, we just changed the warning: telling the agent that some of what it could see might be bait. Faced with that uncertainty the attacker's own logic turns against it. Every attractive resource becomes a potential trap, and an agent optimising for success has to treat the whole estate as suspect. That is a measurable drop in attacker effectiveness before detection enters the picture at all. The catch-22 is that defenders do not get to brief the attacker's agent directly, and if you could, you would also be telling it to go looking. As models improve they will get better at recognizing those patterns in a given environment. Our team has been working on that specific problem, and we’ve introduced some new research here on how to use technology to not only detect but slow down (and potentially even halt) AI-assisted attacks. It also takes us back to one of the first design rules for deception: your canaries have to be believable in the context of the environment they sit in. The full method and results behind the numbers above are at agentic.tracebit.com.

There is another way in which deception technology can be incredibly helpful as response windows are shortening: Because deception alerts are so high fidelity, automated response processes can act on them with more certainty and with less triage effort, enabling organizations to reduce the time they need to contain an attack.

Supply-chain attacks: trusted software doing untrusted things

The second shift, supply-chain compromise, has been building for years, and the measurement has caught up with it. Verizon's 2026 DBIR puts third-party involvement at 48% of breaches, up from 30% the year before. Your prevention and detection stack is largely built to distrust the unknown: the unsigned binary, the unrecognised process, or the connection to somewhere it has never seen. Similar to how an attacker can carry valid credentials, a supply-chain compromise shows up as something trusted in your environment. It comes in through software signed and verified from a vendor you have every reason to rely on, through an update channel you deliberately built to be trusted. SUNBURST shipped inside a signed SolarWinds Orion update in 2020. The 3CX desktop app in 2023 was a signed, legitimately distributed build. Nothing at delivery time gave anyone's controls a reason to flag either, because by every check available, both were legitimate. What eventually surfaced 3CX was behavioral detection on what the signed binary did after it was installed, which is the whole point: the only thing left to detect on is what the trusted component does. This is the textbook unknown-unknown, the threat that looks exactly like something you approved.

Deception does not care that the component is trusted. A canary planted inside the blast radius of that trusted component fires the moment the component starts doing things it has no business doing: reading a decoy secret, assuming a decoy role, enumerating a store it never touched in its legitimate life. We go into this properly, including how to reason about blast radius and placement, in the dedicated supply chain attacks pillar.

The common thread

AI-assisted attacks and supply-chain compromises look nothing alike. One is loud, fast, and mechanical while the other is patient and wears a legitimate face. What they share is the thing that matters: both are unknown-unknowns. Neither can be reliably caught by a control that needs to know the threat in advance, because the whole danger is that you do not, and cannot, know it in advance. Deception is the one detection model that does not need to know the threat in advance. It asks a single question that a signature-based world cannot: did someone just touch something they had no reason to touch.

Open source is where the two shifts meet. There is far more unaudited open-source code than anyone has ever read, and that has been true for a long time. What has changed is the cost of reading it. AI-assisted vulnerability discovery is documented: it is part of what AISI measured, and Anthropic's GTG-1002 report describes an intrusion campaign against roughly 30 targets in which 80–90% of the intrusion activity was carried out by AI agents rather than people.

The compromises that have actually landed through this route were still built by hand. The xz-utils backdoor (CVE-2024-3094) took a patient, maintainer-level social-engineering campaign, and it was caught in March 2024 because one engineer chased down a 500ms delay in SSH logins. The Shai-Hulud worm spread through npm in September 2025. The Salesloft Drift compromise reached customer data in August 2025 through a trusted integration. None of them needed a model to find the flaw, but the model does change the economics of looking for exploits. Projecting forward: the cheaper this gets, the more of that unread code gets examined by someone who did not write it.

What remains is the practical work of doing it well, and that is where the rest of this guide turns: designing coverage that fits your environment, building it, and being honest about what that genuinely takes.