Guide · Agent skill
How to use the Deploying Honeytokens and Canarytokens agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
This skill lets an AI agent help you plant decoy items, called honeytokens or canarytokens, that no legitimate user should ever touch. It is built on Thinkst's open-source Canarytokens project and sends an alert by email or webhook when one is accessed. This guide explains what the skill does, how to install it, how to ask for help with natural requests, and what you need before you start.
Quick start
- 1Download and unzip the skill. Download the ZIP from this page and unzip it into ~/.claude/skills/ or a project's .claude/skills/ folder, or upload it under Settings → Capabilities → Skills in the Claude apps.
- 2Confirm your requirements. Check that you have a system you own, plus either a Docker host with a domain and public IP, or access to canarytokens.org. Install Python requests if you will use the helper script.
- 3Ask for a specific decoy. Describe the artifact, its location and the alert channel in plain language, such as a fake AWS key on a build host with email alerts.
- 4Generate the token. The agent creates the token through the Canarytokens service and returns the values you need, including the trip-wire URL or credential file.
- 5Plant it in a monitored location. Place the token where only an intruder would look, such as a hidden wiki link or a credentials file on a host you monitor.
- 6Validate and record. Trigger or test the token to confirm the alert arrives, then keep the inventory with memos and D3FEND/ATT&CK mappings.
What an agent skill is and what this one does
An agent skill is a folder of instructions and optional scripts that an AI agent loads when your request matches the skill's description. This one is for defensive deception: the agent helps you create tokens that have no operational purpose, place them in locations you monitor, and catalogue them.
The tokens include honey credentials, DNS tokens, web-bug URLs, AWS keys, Word or PDF documents, and kubeconfig files. Any later access to a token triggers an alert. Each token gets a descriptive memo so you know where it was planted.
- Generates token types such as HTTP/web-bug URLs, AWS API keys, MS Word/PDF documents, DNS tokens, Slack tokens and kubeconfig files.
- Walks through deploying the open-source Canarytokens service, either self-hosted with Docker or via the public canarytokens.org site.
- Uses a helper script to create tokens and keep a local inventory mapped to MITRE D3FEND and ATT&CK.
Install the skill from the ZIP download
Download the skill ZIP from this page and unzip it. For a personal install, place the folder in ~/.claude/skills/. For a single project, place it in that project's .claude/skills/ folder.
You can also upload the skill in the Claude apps under Settings → Capabilities → Skills.
- Personal: unzip into ~/.claude/skills/
- Project: unzip into .claude/skills/ inside the project
- Claude apps: Settings → Capabilities → Skills, then upload
Check the requirements before you start
Self-hosting needs Docker Engine and Docker Compose v2, a registered domain you control with DNS delegation for DNS tokens, and a public IPv4 address reachable on ports 80/443 and 53/udp. You also need an SMTP relay or Mailgun account and/or a Slack, Teams or webhook URL for alerts. The helper script needs Python 3.8+ with the requests library.
If you do not want to host anything, you can create tokens through the public service at canarytokens.org, which the source describes as account-free for quick use.
- Docker Engine and Docker Compose v2 (self-hosting)
- Registered domain with DNS control for DNS tokens
- Public IPv4 on 80/443 and 53/udp (self-hosting)
- SMTP relay or Mailgun, and/or Slack, Teams or webhook for alerts
- Python 3.8+ with requests: python3 -m pip install requests
- Or canarytokens.org / a self-hosted frontend
python3 -m pip install requestsTrigger the skill with natural requests
You do not need special syntax. Describe the decoy you want and where it will live. The agent should pick the matching workflow. Be specific about the system you own and where alerts should go.
Good requests name the artifact, the location and the alert channel, for example asking for a fake AWS key to sit in a build host's credentials file, or a Word document for a shared drive folder.
- "Plant a decoy AWS key in the credentials file on our Jenkins build host and alert the SOC email."
- "Make a canary Word document for the finance share and tell me how to validate that it fires."
- "Set up a web-bug token for a hidden link in our internal wiki and send alerts to our Slack webhook."
- "Create a fake kubeconfig for the staging cluster and record it in our token inventory with D3FEND mappings."
Example workflow: create an HTTP token
The source shows a POST request to the /generate endpoint that creates an HTTP token which fires on any GET. The response includes a token, auth value, hostname and a url. That URL is the trip-wire, so place it where only an intruder would find it, such as a hidden link in a wiki page.
For AWS keys, the source shows the same endpoint with type aws_keys. Drop the resulting keys into a plausible credentials file on a host you monitor. Any AWS call using them triggers an alert with the source IP and user agent.
- Run the command with a memo that names the location, such as the wiki page or build host.
- Keep the returned token and auth values in your own records so you can check them later.
curl -s https://canarytokens.org/generate \
-F 'type=http' \
-F 'email=soc@example.com' \
-F 'memo=Internal wiki - IT admin passwords page' \
-F 'webhook_url=https://hooks.slack.com/services/T000/B000/XXXX'Safety notes: scripts and network access
This skill runs scripts and uses the network. The helper script runs local Python code and sends requests to external endpoints. Review scripts/agent.py before using it in production, and check which endpoints it contacts.
Deploy tokens only on systems you own or are explicitly authorised to monitor. The source warns that instrumenting systems you do not own may violate computer-misuse or privacy law.
- Read scripts/agent.py before running it, especially in production.
- Use only on infrastructure you own or have written authorisation to monitor.
- Route alert data through approved monitoring channels.
Tips for getting value from it
Use descriptive memos, because they are how you will know where a token was planted when the alert arrives. Test each token after deployment to confirm it fires and that the alert reaches your SOC channel. Keep the inventory current so you can track coverage against MITRE D3FEND and ATT&CK.
- Write memos that name the exact location and system.
- Validate every token after planting it.
- Put tokens where normal users have no reason to go.
- Review the inventory regularly as systems change.
What people use it for
- Planting a fake AWS key in the credentials file of a build host to detect credential reuse.
- Placing a web-bug link in an internal wiki page that only an intruder would open.
- Seeding a canary Word or PDF document in a file share to catch data-theft staging.
- Creating a decoy kubeconfig for a staging cluster and logging it in a coverage inventory.
Frequently asked questions
Is the Deploying Honeytokens and Canarytokens skill free?
The skill is published under the Apache-2.0 licence, and the underlying Canarytokens project is described in the source as Thinkst's open-source project. The source does not state pricing for the public canarytokens.org service, so check that site directly. Self-hosting still needs your own domain, server and alert service.
What do I need to run this skill?
For self-hosting you need Docker Engine and Docker Compose v2, a domain under your control with DNS delegation, a public IPv4 address, and an SMTP relay, Mailgun account, or Slack/Teams/webhook URL for alerts. The helper script needs Python 3.8+ with requests. You can skip hosting by using canarytokens.org.
How do I install the skill?
Download the ZIP from this page and unzip it into ~/.claude/skills/ for personal use or a project's .claude/skills/ folder. You can also upload it in the Claude apps under Settings → Capabilities → Skills.
Can I use this without self-hosting?
Yes. The source says you can use the public service at canarytokens.org for quick use with no hosting. You still need to be authorised to instrument the systems where you place tokens.
What should I do if a token does not send an alert?
Check that the alert channel is set correctly and that the service is running. For self-hosting, the source lists docker compose ps and docker compose logs -f frontend as status and log commands. Confirm DNS and ports are reachable if you are using DNS or HTTP tokens.
How is this different from a normal intrusion detection tool?
Honeytokens have no legitimate use, so any interaction is treated as a high-fidelity signal rather than a statistical anomaly. The source describes near-zero false positives as the main advantage. It complements, rather than replaces, your existing monitoring.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
This skill suits security teams and sysadmins who own their systems and want low-noise alerts on file shares, credential stores or cloud accounts. It is not a turnkey product: self-hosting needs Docker, DNS control, a public IP and an alert service. If you need a managed product with no setup, or you cannot authorise monitoring of the systems involved, pick a different approach.
Download the skill