Proof
Don't take our word for it. Here's how we test.
A decoy has one job: nobody should ever touch it, so when something does, you hear about it, and when nothing does, it stays quiet. We test exactly that, on every release, and publish the numbers.
- 100% detection
- 58/58decoy services raised an alert when touched
- quiet window
- 0false alarms while nobody touched the decoys
- scan detection
- 9/9decoy types recognised a port scan
- bait test
- Caughta stolen fake secret, reused, raised a “bait used” alert
Last run 2026-10-18. Every release of the sensor runs the same test.
How the test works
Touch every decoy, and expect every one to speak up.
Nobody legitimate has a reason to connect to a decoy, so any connection is the signal. That makes a decoy testable in a way most security tools are not: you don’t have to stage an attack, you only have to knock on the door.
- 01
Run the real sensor
The same Kandaro sensor image customers run, in an isolated test container with nothing exposed to the outside. One run per decoy profile.
- 02
Wait in silence first
Before anything touches it, we watch the decoy for a quiet window. A decoy that raises an alert when nobody is there would be a false alarm, so this must be zero.
- 03
Touch every decoy service
A quick burst of connections across all ports (what a scan looks like), then one ordinary client request per service: a web page, a database greeting, an AI-agent tool list. No exploits.
- 04
Check the alert
Every touch must raise an event for the right service, at a sensible severity, within seconds. The run fails if coverage drops, a scan is missed or a false alarm appears.
Results
Every decoy type, every service.
Each row is one decoy profile. Services are the network services that decoy offers, such as SSH, a web admin page, SMB or an MCP tool server.
| Decoy type | Services detected | Port scan | False alarms |
|---|---|---|---|
| Linux server | 8 of 8 | Detected | 0 |
| Windows file server | 7 of 7 | Detected | 0 |
| NAS / storage | 8 of 8 | Detected | 0 |
| Network printer | 8 of 8 | Detected | 0 |
| Switch / router | 5 of 5 | Detected | 0 |
| IP camera | 5 of 5 | Detected | 0 |
| AI agent server | 8 of 8 | Detected | 0 |
| Integration platform | 6 of 6 | Detected | 0 |
| n8n automation | 3 of 3 | Detected | 0 |
| All 9 types | 58 of 58 | 9 of 9 | 0 |
Severity follows what the visitor does: a bare connection is low; asking for a web page or asking an AI tool server what tools it has is medium; sending a database command is high. In this test, a scan across a decoy's services was reported as one high-severity event.
Through the whole platform
From a touch on a decoy to an explained incident.
The same probes, but now the sensor is enrolled with the real platform and its events go all the way through: stored, grouped into an incident, explained.
- speed
- 2.3 sfrom touch to stored event (median; 95% within 3.9 s)
- incidents
- 9/9decoy types opened an incident within seconds
- explanations
- 9/9explanations named the right facts, a clear next step, in plain English
- bait
- 15/15uses of planted bait recognised as “bait used”; wrong passwords were not
Honest note on the speed: this runs inside one test machine, so there is no real network in between. On your network, add the time it takes to reach our servers. Bait here is a fake login, a fake .env file and a fake Active Directory account, all created through the same code customers use, then tried at a decoy. The explanations in this test are the built-in fallback ones, not the live AI.
Rules, not guesses
The AI explains. It never decides how serious something is.
Two promises a detection product has to keep: the alarm level can’t be talked up or down, and real alarms aren’t buried under noise.
Severity comes from fixed rules
What the visitor did decides the severity: a connection, a login attempt, a command, a used piece of bait. The AI only writes the plain-English explanation. Our tests check that an AI answer claiming “critical” can’t raise an alert, and that text planted in an event can’t lower one.
Explanations are checked against 44 hand-written test cases (synthetic, written by us): the right facts, no invented hosts or IP addresses, no made-up claims, a clear next step. The fallback explanations, used if the AI is unavailable, pass 44 of 44. We haven’t published results for the live AI model yet.
How we keep false alarms at zero
A decoy has no normal users, so most noise is your own tools: vulnerability scanners, backup and monitoring agents. You can mark those sources as known good. Use of bait is never silenced that way: a stolen password used from your backup server is still an intrusion.
Every false alarm a customer reports gets a root cause and a fix, so the same noise doesn’t come back.
What this does not show yet
Honest limits.
A test is only useful if you know what it leaves out. This is what we have not proven yet, and what we are doing about it.
One detector is tested in code only
The network-poisoning detector fires when someone answers a fake name lookup. Testing it live would mean forging such answers, so it is covered by the sensor’s own automated tests instead.
Passwords you plant through the console are tested separately
Secrets hidden in the decoys’ own fake data are tested end to end: reusing them raised a “bait used” alert naming where they came from. Passwords and files you plant yourself are recognised by the platform, which needs its own end-to-end test.
This is our own test
It shows the decoys react to being touched, which is what a decoy has to do. It is not an attack on a real network. An independent red team will run a blind test, and we will publish what they find.
Want to see it for yourself? The deployment guide shows how to run a decoy and knock on it from any machine on your network.
See your first explained finding today.
Start a 14-day trial of Kandaro Deception. Your first decoy is running in about a minute.
Card required · cancel before day 14 and pay nothing