How to give a Claude Code agent access to Slack and Google Drive safely
Give Claude Code one MCP server for each app, with the narrowest scopes the task needs, and let its permission rules decide the rest. Put reads under allow, the one write you need under ask, and anything destructive under deny, then run it read-only first. Keep tokens in the server’s environment, never in a prompt.
Three layers of control
A Claude Code agent reaches Slack and Drive through MCP servers, one per app. Each server brings tools, and each tool either reads or writes. You limit what it can do in three places, and it’s worth using all three:
| Layer | What it limits | Where you set it |
|---|---|---|
| Scopes | What the server can do at all | The OAuth sign-in, or the token you create |
| Permission rules | Which tools run, ask first, or are blocked | allow, ask and deny in Claude Code’s settings |
| Your first runs | What actually happens | Watching each call before you widen anything |
Slack
Slack runs its own hosted MCP server at https://mcp.slack.com/mcp, and names Claude Code among the clients that can use it (Slack). You sign in with OAuth, and workspace admins “can approve and manage all MCP client integrations”.
Slack also lists the scope each tool needs. Reading a public channel needs channels:history, and sending a message needs chat:write. Claude Code can pin the scopes it asks for with oauth.scopes in the server’s config. Its docs use Slack as the example (Claude Code). Leave out every :write scope at first, and the token can read but not post.
Google Drive
Check who publishes a Drive server before you install it, and which Google scope it asks for. Google’s scope list shows the trade-off (Google):
| Scope | What it allows |
|---|---|
drive.file | Files the app creates, or that you open or share with it |
drive.readonly | “View and download all your Drive files” |
drive | “View and manage all your Drive files” |
Read-only and narrow aren’t the same thing. drive.readonly can’t change anything, but it sees every file. drive.file sees far less, but it can write. Google’s own advice is to “choose the most narrowly focused scope possible”.
Whichever servers you pick, check they’re maintained. The MCP project’s own early Slack and Drive servers now sit in a repository of “Reference MCP servers that are no longer maintained” (GitHub).
Set the rules in Claude Code
Claude Code has three kinds of rule: allow runs a tool without asking, ask prompts you first, and deny blocks it (Claude Code). The order matters: “Rules are evaluated in order: deny, then ask, then allow.” And “an allow rule can’t carve an exception out of a deny rule.”
MCP rules use the server name as configured in Claude Code. mcp__slack matches every tool from a server you named slack, and mcp__slack__<tool> matches one. For a first week:
| Rule | Put here | For this task |
|---|---|---|
| deny | Tools the task must never call | Deleting, sharing or uploading |
| ask | The one write it needs | Posting the message |
| allow | Reads you’ve watched it make | Reading the channel, searching the folder |
Name tools one by one. A deny on mcp__slack would also block the reads you allowed, because deny wins.
Rules live in .claude/settings.local.json for you in one project, .claude/settings.json to share with a team, or ~/.claude/settings.json for every project (Claude Code). They bind, too: “Permission rules are enforced by Claude Code, not by the model.” Instructions in CLAUDE.md “shape what Claude tries to do, but they don’t change what Claude Code allows”.
A skill’s allowed-tools isn’t a fence
If you package the task as a skill, its allowed-tools line looks like a limit. It isn’t. The docs say it “grants permission for the listed tools during the turn that invokes the skill”. It also “does not restrict which tools are available” (Claude Code). The grant clears when you send your next message. Lasting limits belong in the deny and ask rules above.
Keep credentials out of prompts
- Never paste a token into the chat or CLAUDE.md. Anything there is text the model reads.
- Hand it to the server instead.
claude mcp add --env KEY=valueputs it in the server’s environment, and.mcp.jsoncan read${VAR}from yours (Claude Code). - Keep personal servers at local scope, which the docs suggest for “servers with credentials you don’t want in version control”.
- Block the key file. A deny rule such as
Read(./.env)stops Claude Code reading it (Claude Code).
Test it read-only first
- Connect with read scopes only, or with a token that can’t write.
- Allow the reads and deny the writes, then run the task a few times.
- Watch every tool call, and check the results by hand.
- Add the write scope, and move that one tool to ask, so each post asks you first. For a pinned OAuth server, that means signing in again from
/mcp(Claude Code). - Keep deletions denied, even once you trust it.
Where Ditto AI fits
Ditto AI does much of this from one recording of you doing the task. It finds a tool for each step and checks each one with one real, read-only call. Permissions come from a fixed table rather than the model, and anything it can’t classify counts as a write. Installed into Claude Code, the policy becomes an allowlist in Claude Code’s mcp__<server>__<tool> names (what Ditto installs).
Two differences from doing it by hand:
- Slack is reached through a local MCP server, with a credential you supply.
- Google Drive goes through your own sign-in in Ditto’s browser, until Google verifies Ditto’s app.
When you start the skill from Claude Code yourself, your own permission rules still apply. So the deny and ask rules above are worth setting either way.
Honest limits
- A server can ask for more than your task needs. Read the consent screen before you accept, and pin scopes where the client allows it.
- Tool names differ between servers. Look them up in each server’s docs before you write rules.
- Content can carry instructions. Claude Code’s docs warn that servers fetching outside content “can expose you to prompt injection risk”, so keep posts under ask (Claude Code).
- Ditto’s permissions are set per tool, not per action. A tool it doesn’t recognise gets write access: safe, but wider than necessary.
To see how a recording becomes a checked agent with its own policy, read How Ditto AI works.