Decoys add strategic asymmetry to your security architecture, strengthening your advantage against the attacker. Plant tripwires across network, identity, data, and AI agent configs for high fidelity alerts.
Defenders—if we do our job right—know our environment better than the attackers. Building deception into the security architecture strengthens the defender’s advantage by turning attackers’ reconnaissance into our intelligence. Decoys raise the attacker’s cost of pursuing their objective faster than they raise ours. Every wrong path they take is a tripwire that signals their presence.
Network, identity, and data offer deception opportunities, including the newer pivot through AI agent configs.
Use decoy services to spot lateral movement.
Network honeypots and decoys catch attackers as they move through your environment. The defender’s knowledge of which services are real makes every interaction a high-fidelity tripwire.
- Decoy services: Stand up a fake file share, web admin panel, or database that no legitimate user should touch. When an attacker pivots inside and scans for valuable services, the honeypot catches their lateral movement.
- Honeypot SSH and RDP servers: Tools such as Cowrie deploy SSH honeypots that respond like a real shell. OpenCanary covers RDP and other protocols that attackers reach for during lateral movement or from the outside.
- Decoy DNS hostnames: Plant unique internal hostnames in your DNS that your legitimate workloads don’t use, such as
legacy-backup-db.internalorold-vpn-admin.corp. Any resolution of those names is a signal that someone is exploring your environment. You can use canarytokens to automate such alerts. - Decoy MCP servers: An attacker who reaches an employee’s machine often pivots to the AI agent’s MCP config to enumerate reachable services. Plant a decoy entry pointing at a honeypot MCP server.
Plant decoy accounts and credentials where attackers might look.
Decoy accounts and credentials can detect attempts to abuse user and administrator privileges.
- Decoy IAM principals with no real privileges: Create user accounts, service accounts, or API keys that exist only to fire when used. Real users have no reason to touch them, so any authentication attempt is worth investigating.
- Decoy credentials in wikis, tickets, and shared docs: Sprinkle plausible-looking credentials in places attackers will look during reconnaissance, such as legacy onboarding docs, deprecated runbooks, and abandoned tickets. The credentials fire an alert when someone uses them.
- Fake credentials in staged config files: Drop a fake
[backup]profile in~/.aws/credentialsor a fake DB password in a.env.bakfile. See planting honeytokens for the full setup.
Place honeytokens into the data attackers want to find.
You can use honeytokens to detect when attackers try to use the data they’ve stolen. See planting honeytokens for the Canarytoken setup.
- Honeytokens in source repos, S3 buckets, and SaaS apps: Plant a canarytoken URL or DNS hostname in a
README, configuration file, or SaaS app, so it fires when the attacker uses it. - Canary documents in shared drives: Use Word, PDF, or MySQL dump tokens disguised as
production-credentials.sqlorbudget-final.docx. The alert fires when the attacker opens the document or imports the file. - Decoy databases and tables alongside real ones: Create a
users_legacytable that no application reads. Any query against it is worth investigating.
Start where deception is free and easy.
Think asymmetrically when deciding how to add deception to your security architecture. Look for elements that raise the attacker’s cost faster than they raise yours. The ideas above are concrete examples of free and straightforward controls. They slow attackers down and misdirect them, giving you time to detect and react.
Start with one tripwire on the surface that matters most, then expand. Even Proteus, the shape-shifting sea god, eventually yielded to his captor Menelaus. But a defense that keeps changing shape still costs the attacker more than one that stands still.
