Last updated: October 17, 2026
Connectors, most built on the Model Context Protocol (MCP), let an AI assistant read and act inside your email, files, CRM or accounting system. Reading is low risk. Writing, deleting and paying are not. Before enabling any connector, list its tools, mark the dangerous ones, keep approvals on, and test with a low-permission account.
Where things stand
An MCP server is a small program that exposes “tools” to an AI assistant: search this inbox, create this invoice, delete this file. Claude, ChatGPT and most desktop AI apps can now connect to them. The official MCP Registry, built in the open by MCP contributors, does not say it vets servers for security. One count in August 2026 found 24,240 distinct servers listed there.
The risk is in what the tools can do. A poster on r/ClaudeAI on October 16, 2026 reported scanning 8,007 MCP servers and finding that 34% had at least one write tool, 6% a delete tool and 8% a payment tool. Those are the poster’s figures and we could not check the method, but the direction matches what vendors publish. A separate August review of hosted servers found Square exposing 23 write scopes out of 49, while Notion, Asana and Wix use a single all-or-nothing scope.
OWASP’s guidance for LLM applications names this problem “Excessive Agency”: too many tools, too many permissions, and too little human approval. Its fixes are plain. Give the assistant only the tools it needs, use read-only access where possible, act as the specific user rather than a shared admin, and require approval for high-impact actions.
The vendors have added controls. In Claude, Team and Enterprise owners can set each connector’s tools, or whole categories such as write/delete, to Always allow, Needs approval, or Blocked, and users cannot override them. Anthropic says most of its first-party Google, Microsoft and Slack connectors are read-only, and requires directory tools to declare whether they are read-only or destructive. In ChatGPT, full MCP with write actions is a beta for Business and Enterprise; new actions are disabled by default on Enterprise, and OpenAI warns that untrusted servers raise prompt-injection risk.
Permission leaks are the quieter risk. A connector set up with one shared credential can reach everything that credential can, regardless of who is asking. Per-user sign-in (OAuth) keeps the assistant inside each person’s own access.
The 10-minute checklist
| Check | Why | How |
|---|---|---|
| 1. List every tool | You cannot judge what you have not seen | Open the connector’s settings or docs and write down each tool name. |
| 2. Mark write, delete and payment tools | These are where mistakes and prompt injection do damage | Tag each tool R, W, D or $. Anything not clearly read-only counts as W. |
| 3. Block what you do not need | OWASP: fewer tools, smaller blast radius | Set unneeded W, D and $ tools to Blocked at the org level. |
| 4. Keep approvals on | A human sees each change before it happens | Set remaining W tools to Needs approval. Never set D or $ to Always allow. |
| 5. Prefer the vendor’s own server | Community servers may hold long-lived secrets and change without notice | Find the server in the vendor’s docs, on the vendor’s domain. If you must use a community one, prefer a public repository you can read. |
| 6. Use per-user sign-in | A shared credential leaks one person’s access to everyone | Choose OAuth per user. Avoid connectors that need one admin API key. |
| 7. Test with a low-permission user | Proves the assistant respects your existing permissions | Sign in as a junior staff account and ask for a file or matter they should not see. |
| 8. Ask for read-only credentials | Many tasks only need search and summarize | Pick read-only scopes on the OAuth screen when offered. |
| 9. Write it down | You will forget what you enabled | One line per connector: who approved, what tools, date. Review every six months. |
What a small office should do now
Start with read-only connectors to the systems your staff already search all day, usually email, calendar and files. That is where most of the time savings are, and the risk is low.
Hold off on anything that can send, delete or pay until you have run the checklist and kept approvals on. For accounting, billing and payroll, keep write tools blocked unless a specific task needs them, then remove the access when the task is done.
Do not install community MCP servers on machines that hold client, patient or financial data. And do not bother with connectors at all if the job is a weekly report that a scheduled script or the vendor’s own export could produce. Fewer moving parts is safer.
What we’re watching
- Whether the MCP Registry adds security review or verified-publisher badges.
- ChatGPT’s full MCP support leaving beta, and what default approvals it ships with.
- Vendors that still publish no scope list, including Stripe and PayPal per the August review.
- Independent replication of the October 16 scan of 8,007 servers.
Sources
- Official MCP Registry, checked October 2026
- jwatte.com: MCP servers in the official registry, and small-business advice, August 2026 (updated October 2026)
- r/ClaudeAI post reporting a scan of 8,007 MCP servers, October 16, 2026 (poster’s figures)
- OWASP GenAI: LLM06:2025 Excessive Agency, checked October 2026
- Anthropic Help: Use connectors to extend Claude’s capabilities, October 2026
- Anthropic: Connectors FAQ, October 2026
- OpenAI Help: Developer mode and full MCP connectors in ChatGPT, October 2026
Changelog
- 2026-10-17 — Page created.