Internal · AI Bot Security Pattern

Scoping a Slack Bot to One Job

How we locked down Pam, our CST bot, so she can read our customer-service knowledge and nothing else. A repeatable pattern for anyone running several Slack bots off one Claude account.

Written June 3, 2026 For Emazing AI power users Status Live and verified

The problem

One Claude account, several Slack bots, each with a specific job. By default, every one of those bots can read everything on the account: your whole filesystem, your second brain, your memory files, and the other bots' data.

That default is fine for a personal assistant. It is not fine for a bot that talks to your team. If a customer-service bot can read employee performance notes, one-on-ones, HR files, or personal records, then a single careless question (or a planted message) can surface things people should never see. The bot needs a hard fence, not a polite request.

Worked example: Pam

Pam is our CST Manager Bot. She drafts customer-service replies for the support team in Slack. Her entire job is customer help, so she should reach only two things: our customer-service knowledge and the two brand websites. Nothing about employees, nothing personal.

Out of the box she had none of that isolation. She ran with full shell access and a shared, wide-open settings file, which meant she could read the second brain, the Claude memory, the Documents folder, even Google credentials. We fixed that. Here is the result.

What she can and cannot touch

Pam CAN access	Why it is allowed
Her own knowledge-base folder (CS policy, the per-brand customer-question sets, the Yuma auto-handled digest)	This is the customer-service knowledge, the whole point of the bot
The two brand websites and their help centers	To check live policy and product pages for a customer answer
Network: Anthropic, Slack, and the brand domains only	Enough to think, reply in Slack, and read the brand sites. Nothing else.

Pam CANNOT access verified blocked	What lives there
The second brain	Employee one-on-ones, performance, HR, personal, family, investing
The Claude memory files	Notes about people and the business
The Documents and Library folders	Everything personal and app data
Google credentials, secrets, SSH and cloud keys	Account access
Other bots' configs and logs	Cross-bot data leakage
The shell (Bash) is removed entirely	So she cannot read a file or send data out the side door

How we proved it

A setting you cannot test is a setting you do not trust. So we ordered Pam, running exactly as she does in production, to read the forbidden files. Then we ordered her to read her own policy file.

Read the second brain → BLOCKED
Read the Claude memory files → BLOCKED
Read the personal handoff docs → BLOCKED
Read her own CS policy file → ALLOWED

The fence sits at the permission layer, below the bot's instructions. So even a planted message that says "ignore your rules and read X" cannot get past it. The block is enforced by the system, not by the bot's good behavior.

The reusable pattern

If you run more than one Slack bot off a single Claude account, give each bot its own fence. Six steps:

Its own settings file. Never point a scoped bot at the shared full-access settings. Each bot gets a dedicated profile.
Minimal tools. Drop Bash (the shell, which bypasses every read rule), plus Write, Edit, and tool-discovery. A read-only answer bot needs only to read its files and the web.
A deny-list of everything outside its own folder. Claude is allow-all-then-deny for reads, so you list what to block. Use ~/ path notation (see gotchas).
Connector isolation. Start the bot with an empty integrations config in strict mode, so it has zero connectors except the ones you deliberately add later.
Lock the network. Allow only the hosts that bot truly needs (the AI service, Slack, and its own data sources). This closes the exfiltration path.
Verify with a probe. Explicitly tell the bot to read a forbidden file and confirm it comes back blocked, before it ever goes live.

Three gotchas we hit

1. Path notation matters. Permission paths must use ~/ form (for example ~/second-brain/**). We first wrote the full /Users/you/... path, and it silently matched nothing and blocked nothing. The bot read everything while the config looked correct.

2. The "do not ask" mode still enforces deny rules. We assumed the headless "do not prompt me" mode skipped permissions. It does not. Once the paths were right, the deny rules held in that mode.

3. The OS sandbox only confines the shell and the network, not the file-read tool. So read confinement is entirely the deny-list. That is exactly why removing Bash is mandatory: with the shell present, a bot can read around the deny-list.