sticking with applied active defense (previous post), this one is about hostname beacons.
first, active defense is the practice of placing traps that force an attacker or automated agent to reveal itself or interrupt its own workflow rather than relying only on prevention or passive detection.
a hostname beacon is a unique resolvable name planted so that any DNS lookup (or subsequent connection) against it produces an alert. the technique is old and reliable. Thinkst DNS Canarytokens have used it for years because DNS is often allowed even when HTTP is blocked [1]. the twist for adversarial agents is that commercial products usually restrict out-of-scope fetches using enforcement guardrails while many adversarial or lightly instrumented agents do not.
💡 defenders can play to the model’s instruction-following bias and present the hostname as something the agent needs in order to complete its task.
I would consider two useful commitment levels. pure resolve of a reserved hostname is enough for a high-confidence signal: any lookup of the canary name fires. higher-commitment versions require an actual connection or tool call. for example, the Thinkst MCP configuration Canarytoken generates a decoy mcp.json that can alert on client connection or only when an offered tool is called. the same file is commonly looked for by Cursor (.cursor/mcp.json), Claude Code (.claude/mcp.json), VS Code (.mcp.json or legacy .vscode/mcp.json), and Copilot CLI (.copilot/mcp-config.json), making it a natural placement in local environments that agents already search [2] [3].
a great earlier demonstration is the NVIDIA model canary: a DNS hostname is injected into a serialized (pickle) model artifact so that simply loading the model triggers the beacon while preserving original functionality [4]. the same idea extends to any local artifact an agent is likely to open or parse, such as config files, skill descriptions, kubeconfigs, documentation, or canary directories.
optional extra context can be encoded into the DNS labels (base32 with length limits) so the alert carries a placement or session identifier. the extra context is useful but not required for the basic signal [1].
some short plantable forms for local environments:
| |
or a higher-commitment MCP-style decoy entry (simplified):
| |
when an agent follows the instruction or loads the configuration, the resulting DNS query (and optionally the connection or tool call) becomes the detection event. the practical result is a change in attacker economics and a clear signal that an agent is operating against the environment.