Internal · AI Bot Security Pattern
You run one Claude account. Off it you run one or more Slack bots, each built to work with a specific department. Here is how we keep each bot inside its lane, using Pam (our CST bot) as the worked example.
One Claude account can run several Slack bots, each serving a different department. By default, every one of those bots can read everything on the account: the whole filesystem, the second brain, the memory files, and the other bots' data.
That default is fine for a personal assistant. It is not fine for a bot that works with a team. If a department bot can read 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.
Feedback on: The problem
Pam is our CST bot. She drafts customer-service replies for the support team in Slack. Her whole job is customer help, so she should reach only our customer-service knowledge and the two brand websites, and nothing about employees or anything personal. Out of the box she had none of that isolation: full shell access and a shared, wide-open settings file let her read the second brain, the memory, and even credentials. We fenced her in. The next two sections show the result and the proof.
Feedback on: Worked example
| 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 |
| 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 |
Feedback on: Access table
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 to read her own policy file.
The fence sits below the bot's instructions, at the permission layer. 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.
Feedback on: How we proved it
Each scoped bot carries two of its own files. They do different jobs, and keeping them separate is the whole trick: one says what the bot should do, the other says what it is allowed to touch.
Because the permission fence blocks the bot from your account's global CLAUDE.md and memory in the first place, the bot does not inherit your account-wide instructions at all. It runs on its own CLAUDE.md instead. Instructions and permissions reinforce each other.
Feedback on: Two files per bot
If you run more than one bot off a single Claude account, give each bot its own fence. Six steps:
~/ path notation (see gotchas).Feedback on: The reusable pattern
~/ 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.Feedback on: Gotchas (and anything overall)