Review what each Claude connector can see before you switch it on for a team

Example result.

Purpose: Find project documents for a small pilot group.
Proposed scope: Read and search only.
Writes: Block file changes and messaging; leave Teams writes off.
Approvers: Claude Owner and Microsoft Entra Global Administrator.
Open questions: Retention period under our policy; compatibility with our network sign-in policy.
Decision: Hold the pilot until both questions have written answers.

Two words are worth separating first. Enabling a connector makes it available to your organisation. Authenticating is each person signing in to the underlying service. Anthropic says enabling “doesn’t automatically grant anyone access”. That’s reassuring, and it’s also why “we’ve only enabled it, nobody’s using it yet” isn’t a durable statement.

1. Read the connector’s own page, not the summary you were sent

Open the connector’s page in the Connectors Directory at claude.ai/connectors. It lists use cases, read and write capabilities, and availability. For pre-built connectors, Anthropic also publishes setup and security documentation; the Microsoft 365 guide lists every tool by name and says which write tools are off by default. That’s the level of detail your note needs.

Check the access model too. Claude inherits each person’s permissions from the connected service: if someone can’t open a file in the source system, Claude can’t reach it for them either. The exception is a custom connector using a shared credential, which reaches whatever that credential can access.

Why this works: the read list is the part people quote. The write list, the defaults and the admin gates are what change the decision.

What you should see: the connector’s directory page and its security guide open, with the write tools and defaults visible.

2. Ask Claude to turn the documentation into a draft note

Open a chat, attach or paste the documentation and send:

From the connector documentation below only, produce a one-page access note with these sections:

1. Read capabilities: what this connector can search or retrieve.
2. Write capabilities: anything it can create, send, change or delete.
3. Who authenticates: whether each person signs in, an admin consents for the organisation, or a shared credential is used.
4. Admin gates: anything an owner or a source-system administrator must enable or consent to first.
5. Defaults: which capabilities are off until someone turns them on.
6. Not stated: anything in my questions that the documentation does not answer.

Quote the exact capability or tool name for each line. Do not infer a capability that is not named. If the documentation says something is in beta, off by default, admin-gated or limited, say so on that line.

My questions: [questions]

[documentation]

[questions] is your list, such as “Can it send messages as me? Can it delete anything? What’s kept in a chat afterwards? Who can see that later?”; [documentation] is the pasted pages.

Why this works: exact tool names expose a paraphrase that widens the scope. A tool called sharepoint_delete_item is harder to misread than “file support”. The Not stated section shows what you’ll have to ask about.

What you should see: six sections with quoted tool names, and a Not stated list. Read that list first.

3. Turn the note into tool permissions

The useful output isn’t a verdict on the connector. It’s three lists: what goes to Always allow, what to Needs approval and what to Blocked.

Claude has two admin places for this. Organization settings › Connectors is where the Owner adds the connector to the team. Customize › Connectors is where the Owner sets what it may do: select the connector and open Tool permissions, grouped into read-only tools and write or delete tools, and choose an option for each group or tool. It applies organisation-wide and members can’t override it.

Anthropic’s own examples are a good shape to copy: allow Claude to search email but not send it; allow it to read files but not edit them. Restricting actions in Claude only ever narrows what’s possible; it never grants more than the source system allows. It also doesn’t control where data goes: connected services process data on their own infrastructure, possibly outside the US, and Claude’s US-only inference setting doesn’t change that.

Why this works: three lists turn a reading exercise into settings an owner can apply and check.

What you should see: every write tool from your note placed in one of the three lists.

4. Enable it and record who approved what

When the Owner is ready, the path is Organization settings › Connectors › Browse connectors, then select the connector and Add to your team. Members then authenticate individually.

There’s also Enterprise-managed auth, in beta on Team and Enterprise plans: you authorise a connector once for the organisation and members inherit access on first login. Treat it as a separate decision, because it changes who is consenting to what.

Why this works: the note, the permissions and the approvals belong together; six months later, someone will ask why Teams messaging is off.

What you should see: the connector added, tool permissions matching your three lists, and the note saved with the approvers’ names and the date.

Check the result

• Every capability in the note quotes a tool or capability name from the documentation.
• Every write tool appears in one of the three permission lists.
• Each admin gate names a person who will approve it.
• The Not stated questions have been sent to someone, not answered from memory.

The usual failure: the draft fills a gap with something plausible. A capability is listed that the documentation never names, or a Not stated question gets a confident answer (“existing sign-in policies apply as normal”). Spot it by searching the documentation for each line’s quoted term.

Remove [claim] unless you can quote the line in the documentation that states it. If it is not stated, move it to "Not stated".

[claim] is the line you couldn’t find in the source.

Fictional example. An operations manager is asked to enable the Microsoft 365 connector so the team can stop forwarding SharePoint documents into chats. She drafts the note from Anthropic’s Microsoft 365 connector security guide.

Her first draft said, under Who authenticates: “Each person signs in with their work account. Existing Conditional Access policies apply as normal.”

• The failure. The second sentence wasn’t in her source. The repair prompt couldn’t quote it, and the guide says the opposite: location and network restrictions aren’t supported, because the server-side requests appear to come from Anthropic’s IP range wherever the member is. Her firm limits sign-ins to the corporate network. That’s a reason to pause for the security team, not to weaken the policy to make the pilot work.
• The bigger gate. Everyone needs a Microsoft 365 account tied to a Microsoft Entra tenant (personal Microsoft accounts can’t be used), and an Entra Global Administrator must give one-time consent for the tenant. So the note has a second named approver.
• The write list. Read tools cover SharePoint and OneDrive search, Outlook email and calendar search, Teams chat search and reading a resource. Write tools, where enabled, include sending and forwarding email, managing drafts, inbox rules and out-of-office, creating and deleting calendar events, uploading and deleting files, and sending Teams messages. Teams write tools are off by default and must each be turned on; the connector-wide “all tools” permission doesn’t enable them. Sends can’t be set to Always allow, so a person confirms each one.

Emails Claude sends carry a header identifying them as agent-initiated, but file, calendar and Teams writes aren’t tagged; Graph calls appear in the Microsoft 365 audit log. Tool-call results in stored chats are kept, so her last open question is how long under her organisation’s policy. The finished note is the example result at the top of this page: complete, while the connection stays unapproved.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Sources

• Claude Help Center: Use connectors to extend Claude’s capabilities
• Claude Help Center: Microsoft 365 connector security guide
• Claude Help Center: How Claude suggests connected apps
• Claude: Connectors Directory