Slack controls for AI agents

The control gap

A communication agent can turn an internal draft into an external statement or expose a private channel through an invitation.

Slack risk depends on workspace, channel type, external sharing, membership, audience size, mentions, files, and whether the action reads, drafts, posts, invites, or changes administration. An internal working-channel draft and an `@channel` announcement in a shared external channel should not inherit the same decision simply because both use `chat.postMessage`.

Keep message drafting automatic, then authorize the final destination, rendered content digest, attachments, and reach before posting. Re-run the decision when the agent edits any reviewed field. Preserve the provider timestamp and channel ID with the receipt so later edits or deletions can be related to the original action without copying private conversation content into the policy log.

What good looks like

Routine Slack work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify read_channel and draft_message separately from post_message and invite_user.
• Scope policy to workspace, channel, user instead of granting one undifferentiated Slack capability.
• Require channel-owner approval for external posts, private-channel invitations, and high-reach announcements.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a Slack action before execution.
2. Endram matches the agent, delegated user, action, and target workspace.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

Slack high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: slack-high-impact
match:
  tool: slack
  action: ["post_message", "invite_user"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted read_channel and invite_user operations.
• The exact workspace and user targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which Slack actions must never run without a human?
• Can policy restrict individual workspace or channel or user?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?