Weekly RudderStack governance audit in Slack

Build me an agent workflow that runs a weekly governance audit of all my RudderStack transformations and posts a risk-ranked digest to Slack.

Trigger: cron, every Monday at 9:00am America/New_York.

Integrations: rudderstack and slackbot. Use the slackbot integration (not the user slack one) so the digest is posted by a bot identity and survives team changes.

What the agent should do on each run:

1. Call List Transformations on RudderStack to get every published transformation in the workspace. The response already includes the destinations connected to each transformation; keep that list, it is the blast radius signal.

2. For each transformation, call Get Transformation to pull the latest published code, and List Transformation Versions to see the revision history so it can compute how long the transformation has been untouched (use the most recent revision's createdAt).

3. Evaluate each transformation against four concrete checks:

(a) PII exposure. Does the code read any of email, phone, ip, raw user_id, traits.*, or context.ip and pass them downstream without hashing, masking, redacting, or stripping? If yes, flag which field and where.

(b) Error handling. Does the code wrap risky operations (JSON.parse, network calls, property access on possibly-undefined nested objects) in try/catch or guards, or does it let exceptions bubble up and drop the event silently? Flag missing handling around specific risky lines.

(c) Staleness. Is the most recent revision 90 or more days old? If yes, include the age in days.

(d) Destination blast radius. How many destinations is this transformation connected to (count the destinations array from the List Transformations response)? Higher count = higher impact if the transformation misbehaves.

4. Rank transformations by concrete findings, not an invented severity score. A transformation that leaks PII into many destinations outranks one with only a stale revision. Order: PII findings first (more destinations breaks ties), then missing error handling on high-fan-out transformations, then staleness.

5. Post a single Slack message via Send a Message on the slackbot integration to the configured channel (default #data-governance, make it a setup field). Format the message with Slack mrkdwn (single asterisks for bold, not double). Shape it as a ranked list, worst offenders on top. For each transformation include: the transformation name, the specific issue in one short sentence, the connected-destination count, and a one-line suggested fix (e.g. "hash email with sha256 before forwarding", "wrap JSON.parse in try/catch and return event unchanged on failure", "review and re-publish; last revision 142 days old"). Keep the message under 40 lines; if there are more findings, truncate and add a final line like "+12 more findings, expand the audit window to see them."

Important: this workflow is read-only. Do not call Update Transformation, Create Transformation, or Delete Transformation. No code in RudderStack is ever modified by this workflow.

Setup fields the user should configure once: the Slack channel to post to, the staleness threshold in days (default 90), and an optional list of additional field paths to treat as PII beyond the defaults.