Slack as the Front-End for Approve/Deny Decisions

Approval in Slack is convenient and risky. The interactive message format, the auth context, and the audit trail that makes it defensible.

Block Kit message format

The Block Kit message has four required slots. Header: the proposed action and the affected resource. Section: the agent’s reasoning, one paragraph not a wall of text. Actions: two buttons, Approve and Deny, each firing a webhook on click. Optional fields: confidence, blast radius, reversibility help the approver decide.

• Header. Proposed action and affected resource; the “what” up front.
• Reasoning section. One paragraph from the agent; not a wall of text.
• Approve/Deny buttons. Each fires a webhook on click; the action surface.
• Optional decision fields. Confidence, blast radius, reversibility; supports the approver’s decision.

Auth context

The auth model maps the Slack click back to a service-side identity that the agent already trusts. The approver’s Slack identity is mapped to a service-side identity (the mapping is maintained, the agent does not trust the Slack click alone); the approver must have permissions for the action and the agent service checks before applying; multi-approver actions require two distinct identities.

• Slack-to-service identity mapping. The agent doesn’t trust the Slack click alone; the mapping is the trust anchor.
• Permission check before apply. Click without permission is logged but does not act.
• Multi-approver requires distinct identities. First click changes message to “awaiting second approval”.
• Per-action permission policy. Documented per action class; supports correct authorisation.

Audit trail

The audit trail captures every click. Logged with who clicked, when, on what proposal, with what decision; the audit log is queryable so “who approved the database failover last Tuesday?” is a one-line lookup; retention matches the audit-log policy (1 year hot, 3 years archived).

• Per-click log entry. Who, when, what proposal, what decision; the full audit row.
• Queryable log. “Who approved the failover Tuesday?” is a one-line lookup.
• Standard retention. 1 year hot, 3 years archived; matches the audit-log policy.
• Per-incident replay. The log supports incident reconstruction; the approval chain is reviewable.

Risks

Three risks deserve mitigation. Slack outage means approvals cannot reach the team (have a fallback like email or PagerDuty for high-urgency proposals); click hijacking where someone steals an approver’s session (tied to Slack’s own auth, ensure SSO plus 2FA); approval fatigue where too many proposals erode care (throttle proposals so only high-stakes go to Slack).

• Slack outage. Approvals cannot reach the team; have email or PagerDuty fallback for high-urgency.
• Click hijacking. Stolen Slack session; tied to Slack auth, ensure SSO plus 2FA.
• Approval fatigue. Too many proposals erode care; throttle so only high-stakes go to Slack.
• Per-risk mitigation policy. Each risk has a documented response; supports continued operation.

UX details that matter

Three UX details make the difference. Auto-expire after 30 minutes (stale proposals are not approved, they fail); show the time remaining (“15 minutes left to approve” forces decisions); update the message on action (“Approved by Alice at 14:32. Action in flight”) so the team sees the state without scrolling.

• Auto-expire 30 minutes. Stale proposals fail; the time bound is the safety mechanism.
• Show time remaining. “15 minutes left to approve”; forces decisions, prevents drift.
• Update message on action. “Approved by Alice at 14:32”; team sees state without scrolling.
• Per-proposal lifecycle. The message updates through stages; supports clear awareness.