Plain-English security review of Tailscale access changes

Whenever someone edits my Tailscale access rules, I want a plain-English review of what changed and whether it made us less safe. Trigger this workflow on the Tailscale webhook event policyUpdate, which fires when the tailnet policy file is updated.

When the event arrives, fetch the current rules using the Tailscale Get policy file operation. The policy file is HuJSON, which is JSON with comments and trailing commas, so send an Accept: application/json header on that request to work in plain JSON. Then pull the recent entries from List configuration audit logs to establish who made the edit, when it landed, and what the previous state looked like. This workflow is strictly read-only: never call Set policy file. Get policy file also returns an ETag, but that is only used for optimistic concurrency on writes, so ignore it here.

Write a short, readable summary of the change. Cover which groups or tags gained access to which destinations, which rules were removed, and which SSH rules or auto-approver rules were touched. Write it for someone who does not read access rule syntax fluently: describe who can now reach what on the network, rather than quoting raw configuration.

Flag anything that widens access dangerously. In particular, catch a new wildcard source or destination, a rule that opens a production tag to everyone, and a newly added auto-approved exit node. If the change looks risky, say so clearly at the very top of the message and name the person who made it, taken from the matching audit log entry.

Post the summary to our Slack security channel using the Slack Bot Send a Message operation. Then record the same summary as a page in our Notion access change log database using Create a Page, so there is a reviewable history for audits. On the Notion page, capture who made the change, when it happened, and whether it was flagged as risky.