Connector safety, permissions, and governance

The moment you connect Google Drive to Claude, you are handing a language model a key to real documents, real customer names, and real revenue numbers. That is the whole point, and that is exactly why this lesson exists. Connectors turn Claude from a clever text engine into something that reaches into your actual systems, so the question is no longer "can it help" but "what did I just authorize, and who can see what happens next."

What a connector actually grants

A connector is a bridge between Claude and an external service (Gmail, Google Drive, Notion, GitHub, Slack, and a growing marketplace of others). Under the hood, most connectors speak the Model Context Protocol (MCP), the open standard Anthropic introduced for letting AI apps call tools and read resources from outside systems. You already know MCPMCPAn open standard that lets AI assistants connect to your company's tools and data in a consistent, governed way, instead of one custom integration at a time.View full definition → at a concept level; here we care about what it authorizes.

When you add a connector, you complete an OAuth flow. OAuth is the "Sign in with Google" pattern you have seen everywhere: you log in on the provider's own page, and the provider hands Claude a scoped tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → instead of your password. The critical word is scope. A scope is a specific, named permission like "read your files" or "send email on your behalf."

Two connectors named "Google Drive" can request very different scopes. One might ask only for `drive.readonly`. Another might ask for full read-write access. Read the consent screen. It is not legal boilerplate; it is the actual list of things Claude can now do with your account.

{
  "connector": "google-drive",
  "scopes": [
    "https://www.googleapis.com/auth/drive.readonly",
    "https://www.googleapis.com/auth/drive.metadata.readonly"
  ],
  "access": "read-only",
  "can_write": false
}

If the consent screen requests write or delete and you only need Claude to summarize documents, that is a mismatch worth pausing on. Grant the narrowest scope that does the job.

Read, search, and act are three different risk levels

Connector permissions collapse into three behaviors, and they are not equally dangerous.

Read lets Claude pull content into the context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition →. The risk here is exposure: sensitive data flows into a prompt, and from there into Claude's response, an Artifact, or a Project shared with teammates.

Search lets Claude query across your data to find relevant items. Slightly higher risk, because Claude decides what is relevant and may surface documents you forgot were there.

Act lets Claude change the outside world: send a Slack message, create a GitHub issue, modify a calendar event, send an email. This is the category that deserves real caution, because a hallucinated detail or a misread instruction now has consequences outside the chat.

A useful habit: when a connector can act, assume Claude will eventually do the wrong thing once, and ask whether that single mistake is recoverable. Sending a draft email to the wrong person is recoverable. Bulk-deleting a Drive folder is not.

Personal account versus work account

This is the distinction most people get wrong, and it has nothing to do with which email you typed in.

When you connect a personal account, the connector usually authorizes against *your individual* permissions. The blast radius is whatever you personally can see. That is often fine for your own Gmail or your own Notion.

When you connect a work account, two things change. First, your organization's admin may govern whether connectors are even allowed, which ones, and for whom. On Claude Team and Enterprise plans, admins manage connector availability and can restrict the marketplace. Second, the connector inherits *your work permissions*, which may be far broader than you realize: shared drives, internal wikis, customer records. Claude now has a window into all of it through your token.

The trap is connecting a work data source inside a personal Claude account, or pulling work data into a Project you later share externally. Data that was governed by your company's access controls is now governed by your chat hygiene. Keep work connectors inside the work-managed Claude organization, where admin policy and logging apply.

If you administer a workspace, the Claude connectors documentation and the admin settings are where you set these guardrailsguardrailsRules and controls that keep an AI system inside safe, legal and on-brand boundaries, blocking outputs and actions that cross the line.View full definition →. Review them before you roll connectors out to a team.

What gets logged, and what does not

Governance is impossible without an audit trail, so know what is recorded.

On managed plans, Anthropic provides admin-level visibility into connector usage and activity, and Enterprise plans add more detailed audit logging and controls. What is generally captured: which connectors are enabled, who connected them, and connector activity at the account level. This is your accountability layer when someone asks "who gave Claude access to the finance drive."

What is *not* a substitute for the source system's own logs: when Claude reads a Google Doc through a connector, that access may also appear in Google's audit logs as activity by *your* account, because the OAuth token acts as you. So a connector action can show up in two places: your Claude organization's view and the upstream provider's view. Security teams should mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → both.

Separately, remember the model side. By default, Anthropic's commercial and APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → terms state that your business data is not used to train models. The connector flowing data in does not change that default, but it does mean sensitive content now lives in conversation history and possibly in shared Projects. Retention of *that* is governed by your plan's data settings, not by the connector.

The marketplace and custom connectors

The connector marketplace lowers the barrier to adding tools, which is great and also a supply-chain question. A third-party remote MCP server you connect is code running on someone else's infrastructure, receiving the data you send it and returning whatever it wants. Treat a new connector like installing a browser extension: prefer official and verified publishers, check who operates the server, and avoid pasting credentials into connectors you cannot vet.

If your team builds a custom connector (an internal MCP server), that is often the *safer* path for sensitive systems, because you control the scopes, the hosting, and the logging. The specification and SDKs live at modelcontextprotocol.io, and Anthropic's reference servers are open at github.com/anthropics. Building your own lets you expose only the three tools a workflow needs instead of an entire API surface.

A simple rule for what to connect

Skip the long policy document. Use one question before every connector:

"If a stranger had this exact access for an hour, what is the worst they could do, and could I undo it?"

That single sentence forces you to think about scope (what access), blast radius (how much data), and reversibility (act versus read) at once. Apply it like this:

• Connect freely: read-only access to data you own, low sensitivity, where Claude summarizing or searching saves real time. Your personal Notion notes. A public GitHub repo. Read-only Drive for a folder of drafts.

• Connect with intent: work data sources, but only inside an admin-managed Claude organization, with the narrowest scope, and never inside a Project you might share externally. Your team's internal wiki, read-only.

• Do not connect (or gate hard): write or delete access to systems of record, anything touching customer PII or regulated data, financial systems, and production infrastructure, unless your org has explicitly approved it and a human confirms every action. Production database write access through a connector is almost never worth the convenience.

The asymmetry matters. Reading the wrong document is a privacy issue you can contain. Letting Claude *act* against a system of record is an operational issue you may not be able to reverse.

Keeping a human in the loop for actions

When you do enable connectors that can act, design the workflow so Claude proposes and a human disposes. In practice that means asking Claude to draft the Slack message or the GitHub issue and show it to you before sending, rather than wiring up fully autonomous execution. For genuinely autonomous agents built on the Claude Agent SDK, you control this at the code level with tool permission settings and confirmation steps, which is a deeper topic than connectors on Claude.ai but follows the same principle: dangerous tools require explicit approval.

A quick mental model for any connector you add:

connector: github
scope: repo-readonly        # narrowest that works
account: work-managed-org   # not personal
shared_in_projects: false   # avoid external leakage
can_act: false              # read only; no issue/PR writes
review: human-confirms-actions

If you cannot fill in those lines confidently, you are not ready to connect that source yet.

Revoking access cleanly

Permissions you grant are permissions you must be able to revoke. Disconnecting a connector inside Claude removes it from your app, but the cleanest revocation also happens at the provider. Go to the source service's security settings (for example, your Google Account's "Third-party apps with account access") and revoke the token there too. This guarantees the OAuth grant is dead even if something is cached. Make periodic connector review a habit: every quarter, look at what is connected and remove anything you are no longer using. Dormant access is the most common quiet risk.

Key Takeaways

• Scopes are the real boundary. Read the OAuth consent screen and grant the narrowest permission that does the job. Prefer read-only unless a workflow genuinely needs to act.
• Personal and work accounts are not interchangeable. Keep work data sources inside an admin-managed Claude organization where policy and logging apply, and never pull governed data into a Project you might share externally.
• Act is the dangerous category. For any connector that can send, write, or delete, keep a human confirming each action and ask whether a single mistake is reversible.
• Use the one-line test: "If a stranger had this access for an hour, what is the worst they could do, and could I undo it?" Let the answer decide.
• Revoke at the source and review quarterly. Disconnecting in Claude is not enough; kill the token in the provider's security settings and prune connectors you no longer use.