Skip to content
Custom Connectors

Guide

Why can't Claude access my data?

When Claude says it cannot see a record you know exists, one of four boundaries is in the way. Each has a fix, and each is also doing a job you want done.

Updated July 23, 20266 min read

Claude cannot access your data when one of four boundaries is in the way: no connector exists for that tool, a connector is attached but its scopes are narrow, the connector authenticates as your account and your account cannot see the data, or the data sits behind a firewall or on-prem. Each cause has a specific fix.

Key takeaways

  • Claude has no ambient access to anything; it only reaches data through connectors you attach.
  • The four usual causes: no connector, narrow scopes, your own account's permissions, or a network boundary.
  • The connector acts as you, so it can never see more than your login already can.
  • The same boundaries that block Claude are what make giving it write access safe.

Why can't Claude see my company's data by default?

Because Claude ships with no access to anything. It is a model, not a resident of your systems. Until a connector is attached to your workspace and you authenticate through it, your CRM, help desk, and databases are invisible to it. That is the deliberate starting point, not a malfunction.

This surprises people who assume an AI assistant somehow indexes their tools in the background. It does not. Every piece of business data Claude can touch arrives through a connector: a piece of software that exposes specific actions, like search_contacts or get_invoice, for Claude to call during a conversation.

So when Claude cannot access something, the question is never why is the AI broken. It is which of four boundaries is between Claude and that data, and whether you want to move it.

Is there a connector for the tool at all?

The most common cause is the simplest: no connector exists between Claude and that piece of software. Claude cannot improvise a connection to a system it has no tools for. The fix is to add one, either an official connector if the vendor offers it, or a custom connector built against the tool's API.

Check the connectors attached to your Claude workspace. If the tool is not on the list, nothing else in this post matters yet.

Many popular products have official connectors you can attach in minutes. For the long tail of industry software, internal tools, and databases, there is usually no official option, and that is where a custom connector comes in: it wraps the tool's existing API as MCP tools Claude can call. Our MCP vs API explainer covers how that layering works.

Why can't Claude see everything even when the connector is attached?

Because connectors are scoped. A connector exposes specific tools with specific permissions, not blanket access to the product. If the connector was built or authorized with read-only scopes, or only covers certain objects, Claude can genuinely see contacts but not invoices. The fix is widening the scopes or the tool set, deliberately.

Scopes work at two levels. The OAuth grant you approved when connecting decides what the connector is allowed to request from the software at all. The connector's own tool set decides what Claude can actually do with that grant.

Common symptoms of a scope gap:

  • Claude can read records but says it cannot update them (read scopes without write scopes).
  • Claude can work with one object type but not another (tools were only built for part of the schema).
  • Claude can list items but not open attachments (file scopes were never granted).

The fix is a decision, not a workaround: re-authorize with broader scopes, or have the connector extended with the missing tools. Widening should be a choice someone makes on purpose.

Why does Claude only see what my own account can see?

Because a well-built connector authenticates as you, not as a superuser. When you connect, you log in with your own credentials, and every tool call runs with your account's permissions. If your login cannot open the sales pipeline for another region, Claude cannot either. The fix lives in the software's own permission settings.

This one catches teams off guard because two colleagues can attach the same connector and get different results. That is the system working: each person's Claude sees exactly what that person sees.

If Claude needs data your account lacks, the answer is not a special AI backdoor. It is the same request you would make for yourself: ask an admin to grant your account the access, and Claude inherits it automatically on the next call.

This boundary is the trust story

Per-user authentication means there is no all-seeing service account for an attacker to steal or an employee to abuse. Claude can never leak data to someone the software itself would not show it to.

What if the data lives behind a firewall or on-prem?

Connectors used from claude.ai are reached over the public internet, so they can only call systems that are reachable from where the connector is hosted. A database on your office network or an on-prem ERP is invisible until a network path exists. Fixes include an API gateway, a secure tunnel, or hosting the connector inside your network edge.

This is a network problem, not an AI problem. The standard fixes are the same ones used for any external integration:

  • Expose a narrow, authenticated API gateway in front of the internal system.
  • Use a secure tunnel or VPN-style link between the connector host and the network.
  • Ask whether the data already syncs to a cloud system the connector could read instead.

Where the connector itself runs also matters here; the remote vs local MCP servers post covers that placement question in depth.

Are these limits a bug or a feature?

Both, honestly, depending on the moment. The boundaries frustrate you when they block a real task, and they protect you the rest of the time. Because access is explicit, scoped, per-user, and network-bounded, opening Claude up is a series of small deliberate decisions rather than one dangerous switch.

The pattern across all four causes is the same: nothing opens by accident. A connector must be added, scopes must be granted, your account must have the permission, and a network path must exist.

That is exactly the posture you want before giving an AI write access to production systems. The fix for Claude cannot access my data is never disable the safeguards. It is to walk the four checks in order, find the one that applies, and open precisely that door.

Frequently asked questions

Does Claude store or train on my business data once connected?
A connector does not bulk-export your data anywhere. Claude calls a tool, receives the specific records the tool returns, and uses them inside that conversation. The connector is a live pipe to your software, not a copy of it, and access always runs under the credentials and permissions you granted when connecting.
Can Claude access data from a tool with no API?
Generally no. A connector needs some programmatic surface to call: a REST API, a database, or an export the software provides. If a tool truly has no API, the options are its database layer, a middleware product that fronts it, or waiting for the vendor. Most business software today has at least a partial API to build against.
Why can a colleague's Claude see records mine cannot?
Because the connector authenticates each person individually. Your colleague's tool calls run under their account, yours run under yours, so differences in the underlying software's permissions show up directly in what each Claude can reach. Align the accounts' permissions in the software itself and the two experiences will match.

Tell us what you run. We'll build the connector.

Pick your tool, choose what Claude should do, and get an instant scope and price. No call required.