Claude Connectors for the Accounting Stack: What They Are and How to Govern Them

What a connector actually is

A connector gives Claude a governed line into a specific tool: a document store, a calendar, a ledger system, a practice-management platform. Instead of a staffer exporting a report, pasting it into a chat, and re-keying the answer back, Claude reads from and writes to the system directly — with the connector defining exactly what it can touch. Anthropic maintains a public connectors directory of tools that work with Claude out of the box, and the connectors page shows the breadth of what is already supported. For systems with no off-the-shelf connector — a legacy document manager, a niche practice tool — custom connectors can be built against the same open standard.

That standard is the Model Context Protocol (MCP), an open protocol introduced by Anthropic and now stewarded under the Linux Foundation, documented at modelcontextprotocol.io. Every Claude connector speaks it. That is good news for a firm: you are standardizing on the protocol the industry standardized on, not on one vendor's proprietary plug-in format.

What connectors change in a practice

With connectors in place, the workflows that eat staff hours compress. Categorization and reconciliation support runs against the client's own ledger connector instead of a stale export. Engagement letters, scheduling, and intake drafting pull from the calendar and templates the firm already maintains. Source-document questions get answered from the document store itself, with the answer citing the file it came from. Month-end close checklists run the same way every time because Claude is reading the live system, not a copy someone remembered to refresh. None of this requires new systems — connectors are precisely the mechanism for keeping the systems you have and removing the swivel-chair work between them.

What the protocol just admitted — and why a firm should care

On August 22, 2026, MCP's core maintainers published their 2026 roadmap (with a companion post on the MCP blog), and named “Agent Identity and Enterprise-Ready Security” a top priority. Their problem statement is unusually plain for a standards document: today's authorization “assumes a person with a browser at consent time,” while many connected servers still “lean on pasted API keys and long-lived refresh tokens.” The roadmap commits to stronger mechanisms this cycle — proof-of-possession credentials and properly scoped, delegated identity — so a connection is harder to forge and a connector can carry narrower authority than the account that created it.

Read that as a buyer, not a technologist: the people who maintain the protocol your connectors run on just told you, in writing, which connector setups are behind the curve — the ones held together by a static key pasted in once and never rotated. That is not a reason to avoid connectors. It is the reason connector governance is a real discipline: which systems are connected at all, under whose credentials, with what scope, reviewed by whom.

The control that matters: allowlists per engagement

In a CPA firm the unit of confidentiality is the engagement, so the unit of connector governance has to be the engagement too. The working rule is simple to state: a Claude workspace scoped to one client engagement gets exactly the connectors that engagement needs — that client's ledger, that engagement's document folder — and nothing else. The audit team's independence-sensitive work runs under a profile that cannot reach the advisory side's tools. Section 7216 consent, where it is required, is obtained before a connector ever exposes return information to the workspace, not discovered afterward.

• Connect by engagement, not by firm. A firm-wide “connect everything” switch is how one client's data ends up in another client's context. Per-engagement allowlists are how it doesn't.
• Prefer scoped, revocable credentials. Where a system offers OAuth with narrow scopes, use it; where it only offers a static key, treat that connector as higher-risk, rotate the key, and log its use. This is exactly the gap the MCP roadmap is working to close.
• Write the allowlist down. The list of connected systems per engagement belongs in the same place as the rest of your security program — the WISP your firm is already required to maintain.

Where Skoor fits

Connector governance is a standing part of every Skoor implementation: we wire the connectors your practice needs, scope them per engagement, document the allowlists in your WISP, and leave the firm with a governance rubric that says who may connect what. The full offer is at Claude for CPA firms.