56 Self-hosted canary corpus

Caveats

• Drive preview, antivirus and link-unfurling can fetch the beacon with no human ever opening the file¹
• Office and Docs beacons only fire if the renderer fetches remote content²

Setup steps

1. Author a small corpus of plausible-but-fake documents (board deck, salary sheet, key material) in Drive, in the places real ones live.

   Content plausible, value zero; never linked from real workflows

2. Embed a beacon: an Apps Script-served image/URL unique per document, so an open/exfil attempt calls out.

   Beacon endpoint

   client-controlled webhook, not a shared SaaS

3. Deploy the Apps Script web app with access = Anyone, executing as the owner, and log timestamp + beacon id + query parameters per hit. To also capture the caller's IP and User-Agent, run the beacon on Cloud Run or the self-hosted webhook from the previous step instead — Apps Script's event object carries neither.

   Deploy > New deployment > Web app; Execute as = me; Who has access = Anyone; logged fields = timestamp, beacon id, query params

   Web Apps ↗ Create and manage deployments ↗ Logging ↗

4. Wire the beacon hit to the same paging path as real alerts and record each doc id in the canary register.

Ongoing maintenance

• automatable: script Quarterly: rotate fired canaries and reseed the corpus as real documents move.
• requires a human Per hit: triage whether the access was staff error or a real intrusion.

How to verify

1. Open one canary document from a clean, non-staff context and confirm the beacon reports with the expected identifiers.