58 Self-hosted canary corpus

Caveats

• Drive preview, antivirus and link-unfurling can fetch the beacon with no human ever opening the file — baseline the noise before you page on a hit.
• Office and Docs beacons only fire if the renderer fetches remote content — an attacker who downloads and opens offline may never trip one.

Setup steps

1. 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. 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. 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

4. 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.