Frequently asked questions

The sensor has no real shell and no real data; every password an attacker tries is refused. It only makes outbound connections to Kandaro, accepts configuration as validated data (never code), and runs in a locked-down container with per-IP connection caps, timeouts and bounded memory.

No. It sits idle until something talks to it. Tarpits are capped per connection and per source, and UDP is never tarpitted, so a sensor can’t be turned into an amplifier.

Add its IP addresses (IPv4 or IPv6, CIDRs allowed) to the ignore list, or mark them as known scanners so their events are recorded as expected instead of alerting.

Events are spooled to disk (up to 50 MB) and delivered in order, exactly once, when the connection returns. The Console shows the sensor as offline after missed heartbeats.

You can, but we advise against it: internet-wide scanners will produce thousands of events. Decoys are most valuable inside your network, where every touch matters.

Not by default. We store a masked value and a keyed hash so you can see reuse across events. Storing captured passwords (encrypted) is an opt-in setting, useful if you want to check whether real credentials have leaked.

Sensors never update their own code. When the Console shows an update, verify the new image signature, change the version tag and recreate the container. The data volume keeps the sensor’s identity and credentials.

By default, a model running on Kandaro’s own EU infrastructure. Cloud AI providers can be enabled per organisation, with explicit consent. If the AI is unavailable, you get a template summary rather than nothing.