This is not well done. Only the server should be able to tell what the honeypot is. The point is to spawn an entity for one or more clients which will be 100% real for them but would not matter because without cheats it has no impact on them whatsoever. When the world evolves such that an impact becomes more likely then you de-spawn it.
This will only be possible if the server makes an effort to send incomplete entity information (I believe this is common), this way the cheats cannot filter out the honeypots. The cheats will need to become very sophisticated to try and anticipate the logic the server may use in its honeypots, but the honeypot method is able to theoretically approach parity with real behavior while the cheat mitigations cannot do that with their discrimination methods (false positives will degrade cheater performance and may even leak signal as well).
For example you can use a player entity that the client hasn't seen yet (or one that exited entity broadcast/logic range for some time) as a fake player that's camping an invisible corner, then as the player approaches it you de-spawn it. A regular player will never even know it was there.
Another vector to push is netcode optimizations for anti-cheating measures. To send as little information as possible to the client, decouple the audio system from the entity information - this will allow the honeypot methods to provide alternative interpretations for the audio such as a firefights between ghosts only cheaters will react to. This will of course be very complex to implement.
The greatest complexity in the honeypot methods will no doubt be how to ensure no impact on regular players.