Sandbox 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. The fix is an argument-level condition that checks which channel the call actually targets.

What you'll need

• 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 Access Policies

Steps

1. Navigate to Access Policies and click Add Rule.

2. Name it "Sandbox 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 sandboxing, 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 defeat the sandbox.

6. Click + condition and add this CEL expression:

   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 the sandbox holds nothing in.

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 works

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 steps

• Argument-level conditions — the full menu of payload-level guardrails, including coverage chips and autocomplete.
• Tags — sandbox several agents to several channels without a rule per pair, by tagging the agents and matching on the tag.
• Block an agent from deleting GitHub branches — another worked policy, this time ordering a deny above an allow.