Slack alerts for every Doppler secret change

Build an agent workflow that reviews every Doppler secret change and posts the right alert in Slack, escalating high-risk changes to Linear.

Trigger: a webhook from Doppler on the config.secrets.update event. Set up the workflow so a single Doppler webhook URL feeds it, configured in Doppler at the workplace level to fire on secret updates. The incoming payload contains the project, config, workplace, and a diff with added, removed, and updated arrays of secret names. Doppler never includes secret values in the webhook payload, and the agent must never attempt to fetch or print a value.

On each webhook fire the agent should:

1. Parse the project, config, and diff from the payload. Treat the diff as three lists of secret names: added, removed, updated.

2. Call Doppler's List Config Logs for the same project and config, pulling the most recent entry. Use it to learn who made the change and how it was made (dashboard, CLI, service account, or API token). If the most recent log entry does not clearly correspond to this change, note that the actor is unknown rather than guessing.

3. Classify the change as routine or high-risk. Default rules: production configs (commonly named prd, prod, production, or anything explicitly marked as a production environment) are high-risk on any change. Introducing a secret whose name suggests admin, root, signing, private key, service account credentials, or master credentials is high-risk. Removing a secret whose name suggests audit, security, or signing material is high-risk. A bulk delete of more than five secrets in one change is high-risk. Anything else, including typical dev or staging tweaks and routine rotations, is routine.

4. Always post a Slack message to the configured security or platform channel using Slack Bot's Send a Message. The message should include: the project and config, the actor (name or service account, plus the source like dashboard or CLI), counts of secrets added, removed, and updated, the actual secret names in each bucket, the risk classification, and a one-sentence rationale for the classification. Use Slack markdown for readability. Never include secret values. If a list of names is long, cap it at the first 20 and note the remainder count.

5. If the change is high-risk, also create a Linear issue via Linear's Create Issue in the security team's workspace. Title: short summary like "High-risk Doppler change in <project>/<config>". Description: full details (actor, source, added/removed/updated names, classification rationale, timestamp) and a link to the Doppler config in the dashboard at https://dashboard.doppler.com/workplace/<workplace>/projects/<project>/configs/<config>. Set priority to High. Include a label or tag for security if one exists, otherwise mention security in the body so it can be routed. For routine changes do not open a Linear issue.

Strict rules for the agent: never call any Doppler endpoint that returns secret values (no List Secrets, no Get Secret). Only use List Config Logs for context and the webhook payload's diff for the names. Never include a secret value in any Slack message, Linear issue, log line, or thought. If the payload is malformed or missing required fields, post a single Slack message saying a malformed Doppler webhook was received and stop.

Integrations to use: Doppler (List Config Logs), Slack Bot (Send a Message), Linear (Create Issue).