The detection gap prevention can't close
At 2:14pm on a Tuesday, someone logs into your cloud environment with a valid set of credentials. They pass MFA, because they have the token. Your EDR sees nothing worth flagging, because no malware ran and no exploit was fired. Your posture management is green, because nothing is misconfigured. The session comes from a plausible location on a plausible device, and it does the sort of thing an administrator does: lists a few buckets, describes some roles, reads a secret, and impersonates another account. Every request is authorized and actions are logged as normal. To your security systems, this looks exactly like work.
But… It’s not... It is an attacker and they are already past everything you built to keep them out. And you have absolutely no idea.
This is the worst case scenario for any company.
The modern prevention stack is built on an idea of “known knowns,” that if we know what a virus looks like, what an intrusion looks like, what malware looks like, or what unauthorized access looks like we can prevent it. But when an attacker looks, sounds, and behaves like a real employee, your defenses break down. In this case, the credential giving the attacker access was phished, or bought, or lifted from a repository, or minted from a token that leaked into a CI log. Nothing was "breached" in the way your tools are watching for. There was no perimeter to cross, because in the cloud the perimeter is an identity, and the attacker is holding a real one. Your defenses did their jobs.
The attacker simply logged in.
So the question to ask about your own environment is not "are we secure?" and it's not even "can we keep them out?" Both are the wrong type of question, because both assume the fight happens at the door. The useful question is the one almost nobody can answer with confidence: how fast would we know if someone was already inside?
This is the question at the heart of the Assume Breach strategy.
For most organizations, the answer is measured in weeks, and that is the optimistic version. The median time to identify a breach is around 11 days [citation: IBM Cost of a Data Breach], which is a median across incidents that were eventually found at all. In the cases that matter most, the number is far worse. In the Brickstorm espionage campaign, attackers sat undetected in victim environments for a median of 393 days [citation: Brickstorm / Mandiant]. Yeah you read that right… more than a year of quiet access before anyone noticed. And when breaches are discovered, more often than not it is not the victim who discovers them: roughly 57% are reported to the organization by an outside party rather than caught by its own tooling [citation: verify figure].
Sit with that for a moment. An organization can have every preventive control in place, fully funded and correctly configured, and still hand an intruder a year of unobserved access to its most sensitive systems. See, the cybersecurity spend went almost entirely into keeping people out. Almost none of it answers the question of what happens the moment someone gets in anyway? And given enough time and interest, someone always, eventually, gets in.
Prevention has to know what to block. Most detection has to know what to look for: a signature, a known-bad indicator, a rule, a threshold, a baseline of "normal" that the bad thing deviates from. That model works well against attacks you can describe in advance. The attacks that do the most damage are the ones nobody could define beforehand: a zero day exploit, stolen credentials, a hijacked session, or now the advancement of AI assisted attacks. These are the unknown-unknowns: the threats you cannot write a rule for because you do not yet know they exist. You cannot build a signature for an attack you have never seen, and you cannot baseline your way to catching a login that looks identical to a legitimate one. Supply chain attacks are an example of an unknown-unknown: You are inviting software into your environment, and it’s behaving as expected, but the code is malicious. Many defenders struggle detecting this without deception technology in place.
That is the detection gap and closing it needs a detection approach that does not depend on knowing the threat in advance. It needs an approach that works even when you cannot describe what you are looking for.
There is a category of detection built for exactly that problem.
That’s where Deception Technology comes in.
What deception technology actually is (and isn't)
Deception technology is a class of detection that works by planting resources with no legitimate purpose inside your environment and alerting the moment anyone interacts with them. The planted resources look and behave like real assets an attacker would want: a set of credentials, a database, a secret, or a bucket of files to name a few examples. Because no employee, service, or automation has any reason to touch them, an interaction is a clue that someone or something unauthorized is rooting around your environment. Deception builds a place where only an attacker would ever go, and watches to see who arrives.
In the Deception Technology space there are a number of terms that get used interchangeably, we’ll do our best to define them here how we see them.
Untangling the Vocabulary
Four words cause most of the confusion in this space: honeypots, canaries, honeytokens, and decoys. They are not synonyms and the differences map directly to how much they cost you to run.
A honeypot is a full decoy system. Historically this meant an entire fake host, a server stood up to look vulnerable and interesting, instrumented so that every action taken against it is recorded. Honeypots are the oldest form of the idea and the heaviest to run, because a convincing fake system is still a system: it has to be built, maintained, patched enough to stay believable, and watched. Their original purpose leaned as much towards studying attacker behavior as catching intrusions quickly. Honeypots are traditionally associated with on-premises networks as real hardware to be maintained. In a cloud environment, this can be a virtual system, but it’s still a full system to be maintained. Furthering on this is the term Honeynet, which was an environment, like a subnet, that was made to look like an entire section of your network with a bunch of honeypots on them. So an attacker may have felt they got access to the financial team’s environment, and would waste a lot of time rooting around a bunch of honeypots.
A canary is a lightweight resource that does one thing: it alerts when it is touched. The name borrows from the bird in the coal mine and the analogy works well. A canary is a single tripwire. In the cloud a canary might be an S3 bucket that looks like it holds billing exports, an IAM role that looks like it can deploy to production, or a Secrets Manager entry that looks like it unlocks the customer database. It carries no real data and grants no real access. It exists only to be found and fire a signal.
A honeytoken (or sometimes called canary token) is a canary whose form is a piece of information rather than a resource: a planted credential, API key, secret, connection string, or document that alerts when it is used. The distinction from a canary is subtle and the two words are often used interchangeably. The useful way to hold it is that a canary tends to be a resource that alerts when accessed, while a honeytoken tends to be a piece of data that alerts when used somewhere. A fake AWS access key committed to a repository is a honeytoken. The alarm fires the moment someone tries to authenticate with it, wherever they are.
Decoy is the umbrella term. Honeypots, canaries, and honeytokens are all types of decoys: assets placed to be discovered by an attacker and to betray that attacker when they are. When a piece of writing uses "decoy" it is usually gesturing at the whole family rather than any one member.
The practical hierarchy runs from heavy to light. A honeypot is a whole fake system you own and operate. A canary is a single fake resource that alerts on contact. A honeytoken is a piece of fake data that alerts on use. The lighter the decoy, the cheaper it is to place, vary, and keep fresh at scale, which is why cloud deception has moved almost entirely towards canaries and honeytokens and away from the full-system honeypot.
The mechanism that makes deception different
Every other detection tool you run is trying to solve a needle-in-a-haystack problem. It watches an enormous stream of legitimate activity and tries to pick out the rare malicious event inside it. Deception inverts that problem entirely.
You place a resource that has no legitimate reason to be touched. So any interaction with it is malicious by definition. There is nothing to distinguish because there is no legitimate activity to sort through in the first place. That single property cascades into everything that makes deception attractive as a detection model. A canary does not think a touch is probably bad. A touch is bad, because the resource has no legitimate reason to be touched in the first place.
What if an employee ends up touching the resource though, won’t that set off the alarm? Yes… it will. But most employees who are doing legitimate work already have access to the services they need to have access to. Why would an employee be rooting around looking at other resources? In the off chance it really is accidental, it’s worth the false positive if nothing else but to do some training. But… insider threats are also a big problem for companies and an employee rooting around in resources they shouldn’t be, is just as valid of a signal.
This is why deception is so good for the scariest “unknown unknown” problems. It does not need to have seen the attack before, know the malware, recognize the technique, or hold a rule that describes what the attacker is doing. It only needs the attacker to reach for something that looks worth taking. That makes it the one approach that works really well.
How that compares with the rest of the detection stack
The rest of your detection stack, the SIEM, the EDR, the CSPM, works the opposite way and these tools are genuinely necessary and deception does not replace them. However, deception is much cheaper to triage because it has an inherently low false positive rate, so it doesn’t add a lot of operational overhead.
Signature and baseline detection hunt for the one bad event among a billion legitimate ones. A SIEM correlates logs to spot the pattern that looks like an attack. An EDR watches process and file behavior on endpoints for known-bad or anomalous activity. A CSPM compares your cloud configuration against a model of what is safe. All three, being probabilistic, are making an informed guess that a given event, out of an ocean of normal events, is the malicious one, and they either match it against a signature of something seen before or measure it against a baseline of what normal looks like. Both approaches are powerful and both carry the same two costs: they need prior knowledge of what they are looking for, and because normal activity is noisy and varied, they generate false positives that have to be tuned, triaged, and lived with. It is the nature of trying to find a rare bad thing inside a mountain of good things.
However, these tools are still valuable because they can give you really early detection and methods of prevention, when attackers using known exploits or vulnerabilities. This is a great thing! Remember, deception technology relies on the concept of Assume Breach, and it’s your last line of defense when everything else doesn’t pick up the intruder.
Deception carries none of the cost of detection technology. It plants a tripwire only an attacker would ever hit, so a hit is deterministic rather than probabilistic. There is no ocean of legitimate activity to filter and no baseline to maintain, which is why a well-built canary sits at close to a zero false-positive rate. What it gives up in exchange is coverage of everything the attacker does not touch. Deception does not see the whole environment the way a SIEM does. It only sees the specific places you chose to bait. The two models are complementary by design: signature and baseline detection give you broad, continuous visibility at the cost of noise, and deception gives you a small number of near-certain signals at the cost of breadth. A mature program runs both.
Dimension
Signature / baseline detection
Deception
Needs prior knowledge of the threat?
Yes: a signature to match or a baseline to deviate from
No: it keys on attacker behavior, not a description of the attack
Detection logic
Probabilistic: is this rare event the malicious one?
Deterministic: this resource has no legitimate reason to be touched
False-positive profile
Inherent and ongoing: normal activity is noisy
Near-zero: there is no legitimate activity to confuse it with
Tuning burden
Continuous: rules and baselines need constant maintenance
Minimal: no baseline to learn, no signature to update
What a hit means
This might be an attack; investigate to confirm
Someone is somewhere they should not be; near-certain intrusion
Catches unknown-unknowns?
Poorly: it can only find what it has been taught to look for
Yes: novel attacks trip the wire the same as familiar ones
Coverage
Broad: the whole environment it can see
Focused: the specific assets you chose to bait
What deception does not do
Trust in everything above depends on a quick reality check: deception detects, it doesn't prevent, and we won't pretend otherwise. A canary does not stop an attacker from getting in, does not patch the vulnerability they used, and does not block the action they take. By the time a decoy fires, someone is already inside your environment and moving. It is the fastest, most reliable way to learn that a wall has already been crossed.
With that said, our team has been experimenting with ways to leverage canaries as mechanisms to slow down AI-assisted attacks, which are now part of Tracebit’s enterprise deception solution. You can read more about Context Bombs here: https://agentic.tracebit.com/context-bombs/
Prevention will eventually fail. A determined attacker with valid credentials will get in. The question worth answering is how fast you would know. Deception is the best answer to that question, because it sits behind your prevention controls rather than alongside them that it catches what they miss. Run your firewalls, your identity controls, your patching, your posture management… don’t give any of that up. Then assume they will not be enough, and place the tripwires that tell you the moment they were not. Prevention and deception are not competitors. One keeps attackers out for as long as it can, and the other tells you the instant that stops being true.
None of this is new, but the shape of it has changed a great deal over the years: From the first instrumented honeypots to the lightweight cloud canaries most teams reach for now. That evolution, and why the cloud broke the model that came before it, is where we turn next.
The ultimate question we’ll leave you with as you continue exploring is what is the cost to you and your business if someone secures a foothold in your environment and you’re unaware of it.
