How do I treat Slack messages, tickets and logs that an MCP server returns as untrusted, and add write access safely?

What should I check, step by step?

1. List who can write into each source: a public Slack channel, a shared Slack Connect channel, a support queue that takes email from customers, public GitHub issues and any log that records user input are all written by people outside your team. Treat that content as data from a stranger.

2. Start read-only: run the GitHub MCP server with --read-only (write tools are skipped even if you name them with --tools) and only the --toolsets you need, and request only read scopes for other servers.
3. Request the narrowest read scopes the task needs. Slack's MCP server maps tools to user-token scopes: searching public channels needs search:read.public, while search:read.private, search:read.im and search:read.mpim also open private channels and direct messages. Leave those out unless the task needs them.
4. Filter where the server can: the GitHub MCP server's --lockdown-mode withholds public-repository content from authors without push access. GitHub says it is a best-effort filter, not an authorization boundary, so keep the other controls too.
5. Add one write permission at a time, starting with the most reversible, and run it with confirmation on for a while before the next. For Slack, that could be reactions:write, then drafts reviewed by a person, then chat:write; canvases:write, channels:write and files:write each get their own step.
6. Make every write ask first: in Claude Code, put write tools in an ask rule (for example mcp__slack__* in ask, specific read tools in allow). Rules are evaluated deny, then ask, then allow, so a broad ask or deny wins over a narrower allow.
7. Break the trifecta per session: a session that reads public tickets shouldn't also hold a tool that posts to the internet or reads private channels. Split it into a read-and-summarize step and a separate act step that a person approves.
8. Show the full arguments of any write before it runs, and flag writes the user didn't ask for, especially a message to a channel or person outside the task.

Why an honest MCP server can still inject

The server isn't the attacker here. A Slack or ticketing server faithfully returns what people wrote, and if one of those messages says to forward the thread somewhere or close every open ticket, the model sees it in the same context as your instructions.

• OWASP's LLM01:2025 lists, among its mitigations, least-privilege access for the model, human approval for high-risk actions, and separating and clearly marking untrusted content. Marking content helps; the first two are what stop a successful injection from causing harm.
• This is a different problem from a malicious server poisoning its own tool descriptions (see the Log-To-Leak page). Here the descriptions can be perfect and the danger still arrives in the results.

What each control does and doesn't cover

Read-only mode stops the server from writing, but reading is the leak in many attacks: an agent that reads private data and has any other tool that can send data out can still leak it.

• Scopes are enforced by the service (Slack, GitHub), so they hold even if the model is fooled. Prompts and system instructions aren't enforced by anything.
• Confirmation prompts work only if people read them. Show the destination and the full text, and keep auto-approve for tools that only read.
• The MCP specification says clients must treat tool annotations such as readOnlyHint as untrusted unless they come from trusted servers, so check the scopes and modes yourself rather than the hints.