Limit an agent to one Slack channel

You want a deploy bot or an on-call agent to post and read in #deploys, and nowhere else. Restricting by tool name alone isn't enough: slack_send_message and slack_read_channel work on any channel the connected user can reach, not just the one you have in mind. In SecureAuth Agent Authority, an argument-level condition checks which channel each call targets. When you finish, the agent can use #deploys and nothing else, provided you removed the default Allow all rule.

What you'll needCopy Anchor Link

• The Slack resource added to your gateway (Add Slack)
• The channel ID of the target channel, not just its name. In Slack, open the channel, click its name at the top to open channel details, and scroll to the bottom of the About tab, or right-click the channel and choose Copy link. The ID is the last segment of that URL (it starts with C).
• Admin access to Agent Access

StepsCopy Anchor Link

1. Navigate to Agent Access and click Add Rule.

2. Name it "Limit agent to #deploys."

3. Set the effect pill to Allow.

4. Set the MCP scope pill to Slack, and optionally the Agent pill to the specific agent you're limiting, if Slack is shared with agents that need broader access.

5. Add the tool patterns for the channel-scoped tools you want to permit: slack_read_channel, slack_read_thread, slack_send_message. Leave out slack_search_public and slack_search_public_and_private: search isn't scoped to one channel, so including it would return messages from other channels.

6. Click + condition and add this CEL expression:

   Copy Text

   request.args.channel_id == "C_DEPLOYS"

   Replace C_DEPLOYS with the real channel ID you copied above.

7. Set the status to Active and click Create.

You don't need a second rule. Every one of these tools takes a channel_id, so when the condition is false (a different channel), the rule simply doesn't match, and the call falls through to the default deny. If your organization still has the default Allow all rule, disable or delete it first. Otherwise, calls that match no other rule fall through to it and succeed, and this rule restricts nothing.

Removing Allow all is org-wide: every agent and resource whose access relied on that fall-through is denied the moment it's gone, including any other agent that needs broader Slack access than this rule grants. Add the allow rules those workloads need first, then remove it.

Verify it worksCopy Anchor Link

Reconnect the agent first. The gateway compiles each agent's policy snapshot once, when the agent connects, so a session that was already open when you created the rule keeps running under the old snapshot. Posts to other channels would still succeed and you'd think the rule failed.

1. Ask the agent to read or post in #deploys. It should succeed.
2. Ask it to post in a different channel, or to search across the workspace. Both should fail.
3. Open Agent Trail (Audit log) and confirm both outcomes: the #deploys call executed, and the other attempts show gateway.tool.error with error_type: blocked_by_policy. Those rows name no rule: a fall-through deny isn't attributed to a policy, because none matched. A row names a rule only when one actually matched the call, as an explicit Deny rule would.

Next stepsCopy Anchor Link

• Argument-level conditions – the full menu of payload-level guardrails, including coverage chips and autocomplete.
• Tags – limit several agents to their own channels without a rule per pair, by tagging the agents and matching on the tag.
• Block GitHub merges and file writes – another worked policy, this time ordering a deny above an allow.