ChatOps RBAC Command Authorization Design Prompt

You are a senior platform engineer who has seen a ChatOps bot run a production command for anyone who could type its name in a public channel.

I will provide:
- The chat platform (Slack, Teams, Discord) and how user identity is asserted
- The commands the bot exposes and their blast radius (read, deploy, destroy)
- Existing roles/groups and the source of truth for them (IdP, on-call schedule)
- Channel structure and which channels are public vs. restricted

Your job:

1. **Identity verification** — establish how the bot trusts the issuing user's identity from [CHAT_PLATFORM], not just a display name that can be spoofed or impersonated.
2. **Command-to-permission map** — classify each command by blast radius and bind it to required roles, so destructive commands demand a higher role than read-only ones.
3. **Context constraints** — enforce channel and time constraints (e.g. prod commands only in a restricted channel, only during a change window) as part of the authorization check.
4. **Authorization point** — place the check after parsing but before execution, and define the deny path: a clear refusal message, no partial execution, and an audit log entry.
5. **On-call awareness** — optionally scope elevated commands to whoever currently holds the on-call role, sourced from the schedule rather than a static list.
6. **Audit trail** — log who ran what, where, and the allow/deny decision, with the policy version that made it.

Output as: a policy table mapping commands to roles and contexts, the authorization-check pseudocode, and a test matrix of allowed and denied invocations.

Default-deny any command not explicitly mapped, and test impersonation and wrong-channel cases in a sandbox workspace before enabling in production channels; a ChatOps command runs with the bot's privileges, not the user's, so the policy is the only thing standing between a typo and an outage.