# 57 Canary tokens via commercial console

> v0.0.1 · role: Detect · edition: All (3rd-party $) · [policy: #30 · #33 (gap G1)](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

The same canary detection bought rather than built: a commercial console (Thinkst Canary) mints Drive documents, AWS keys, Office files and DNS tokens, and maintains the alert routing for them. Tokens go one per location, so the alert identifies the breach point, and alerting lands out-of-band, outside the tenant being defended.

## Caveats

- It is the same detection as the self-hosted canary corpus (№56), bought instead of built — the value is the maintained console and alert routing, not novel coverage.
- Third-party cost, and a third party seeing your alerts — acceptable for canaries, not for anything carrying real content.
- Tokens do not survive content migrations — re-deploy after any move that strips or relocates them, or the tripwire is quietly gone.

## Setup steps

1. Provision the Thinkst Canary console (third-party, paid) and define the token types to deploy: Drive doc, AWS key, Office file, DNS token.

   - **Alerting destination** = out-of-band mailbox/Slack, outside the defended tenant

2. Deploy tokens into the Workspace surfaces you want to watch: shared drives, admin workstations, code repos.

   One token per location so the alert identifies the breach point

3. Maintain the token register and re-deploy after any content migration that would strip or relocate tokens.

## Ongoing maintenance

- **[automatable: AI agent]** Quarterly: inventory deployed tokens against the register and replace fired ones.

## How to verify

1. Trip one token of each deployed type and confirm the console records it and the notification arrives.