Slack Slash Command RBAC by User Group Prompt
Design authorization for slash commands that gates privileged actions by Slack user-group membership, with audit logging and clear denial UX.
- Target user
- Platform engineers securing privileged ChatOps commands
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has secured privileged ChatOps commands so that `/deploy prod` can only be run by the right people, with a trail to prove who ran what.
I will provide:
- The privileged commands and their risk tiers ([/deploy, /rollback, /db-migrate, /feature-flag])
- How my teams map to authority ([Slack user groups / IdP groups / on-call schedule])
- Where my source of truth for permissions lives
- My audit and compliance requirements
Your job:
1. **Authorization model** — map commands and sub-actions to required roles. Decide the source of truth: Slack user groups (`usergroups.list` / `usergroups.users.list`) versus your IdP/SCIM-synced groups. Explain why Slack user groups alone are weak for high-risk actions (anyone with workspace admin can edit them).
2. **Membership resolution** — resolve the invoking `user_id` to roles at command time, with a short cache and a cache-bust path. Handle the user-not-in-any-group case.
3. **Per-action gating** — gate not just the command but the parameters: `/deploy staging` open, `/deploy prod` restricted; `/feature-flag read` open, `--write` restricted.
4. **Denial UX** — return an ephemeral, non-leaking message ("you need on-call or release-eng to run this") without revealing the full authz config.
5. **Audit trail** — log every attempt (allowed and denied): user, command, args, channel, timestamp, decision, and the role that granted it. Make denials first-class events.
6. **Break-glass** — an escalation path for emergencies with extra logging and notification, never a silent bypass.
Output as: (a) command-to-role matrix, (b) source-of-truth tradeoff, (c) membership-resolution snippet with caching, (d) per-parameter gating logic, (e) denial UX message, (f) audit-log schema, (g) break-glass flow.
Safety: re-resolve membership at execution time, not from the slash-command payload; never trust a client-supplied identity claim, and log every denial.
Why this prompt works
The moment a slash command can do something dangerous, “anyone in the channel can type it” stops being acceptable, and most teams reach for Slack user groups as the gate. This prompt makes the model confront the weakness in that instinct: Slack user groups are editable by any workspace admin, so anchoring /deploy prod to them means your deploy authorization is only as strong as your weakest admin. By forcing an explicit source-of-truth tradeoff against IdP/SCIM-synced groups, it pushes the design toward an authority model that actually holds for high-risk actions.
Per-parameter gating is the distinction that separates real RBAC from a coarse on/off check. The interesting commands aren’t uniformly privileged — /deploy staging should be open while /deploy prod is restricted, and /feature-flag read differs from --write. Requiring the model to gate the arguments, not just the command name, produces authorization that matches how risk actually distributes across ChatOps, instead of an all-or-nothing wall that people route around.
The audit and break-glass sections make this safe to live with. Treating denials as first-class logged events gives security the trail they need, and an explicit, noisy break-glass path means emergencies don’t force people into silent bypasses that erode the whole model. The AI drafts the resolution and logging plumbing; the human owns the command-to-role matrix and reviews the break-glass design — which is exactly where the judgment belongs.