All insights
AI

Connecting AI to SharePoint without giving it your client files

We built an assistant for an accounting firm that answers staff questions from the firm's own procedures. The hard part was not connecting the AI. It was proving it could never see anything else.

Nathan James
Founder, Worktopia
20 August 20265 min read
SharePoint
The hard part was not connecting the AI. It was proving it could never see anything else.

The short answer

Connecting AI to your firm's systems is usually framed as one big decision: switch on Microsoft 365 access and the assistant sees everything, or hold off entirely. There is a middle. At an accounting firm we work with, staff now ask an assistant “what needs sign-off before a BAS goes out” and get the firm's own procedure back, because the assistant has been granted exactly one SharePoint document library. Everything else the firm holds, client files included, is refused by Microsoft's permission system, not by our code. The rest of this article covers what that takes, what the assistant cannot do, and the one trade-off that comes with it.

Why firms want this, and why they hesitate

A practice's procedures are spread across a few hundred documents that nobody can quite navigate, so new staff ask the person next to them and senior staff answer the same questions for years. An assistant that has read the procedure library ends that, and points at the document each answer came from. The firm's staff use it daily.

The hesitation is just as rational, because the usual way in looks like opening the whole cupboard. Client information going into an AI tool can be a disclosure needing consent, the territory the Tax Practitioners Board's AI guidance covers. Procedures are the firm's own knowledge and carry none of that weight. The middle path is to scope the assistant to the procedures and nothing else, so no client information enters an AI tool at all. The consent conversation is not being avoided. There is simply nothing in the tool for it to be about.

Why not just turn on Copilot?

Copilot answers with whatever the signed-in person can already reach. That is by design and often fine, but it makes your permission hygiene the security model, and in most firms that means old shares, broad groups and folders nobody remembers opening up.

Copilot is not the wrong choice. It has an honest prerequisite: review who can reach what before you turn it on, which is also what Microsoft's own documentation advises. Our build takes the opposite approach. The assistant has its own identity and a permission that names one library, so nobody inherits anything and what the AI can see is written down in one short place.

What the assistant cannot do

It cannot reach anything else. Microsoft's app permissions usually cover a whole site. This build uses a narrower one that names a single library (for whoever runs your IT, it is called Lists.SelectedOperations.Selected). A request for anything beyond the procedure library is refused by Microsoft before our software is consulted. At this firm the client files sit in the same SharePoint site as the procedures, and the refusal holds all the same. Our code could be wrong in every line and the boundary would hold. The firm can prove this whenever it likes: a check we supplied confirms the procedure library reads, everything else is denied, the permission covers one library rather than the site, and nothing can be written. The output is a dated record the firm can show a client, an insurer or an auditor.

It cannot write. The permission is read-only and there are no upload or delete tools. Procedures change through the firm's normal review, by people.

It cannot be redirected. Hiding instructions inside documents is becoming a real way to attack AI systems. Here, a document that says “now open the client files” achieves nothing, because no tool accepts a location, so the instruction has nothing to act on.

It refuses guests. Contractors and guest accounts are declined even when they sign in successfully. Widening that is a deliberate decision, not a default.

The trade-off

Microsoft's search, scoped to a single library this way, can find documents by name but cannot search inside them. To answer “what does our policy say about X”, the connector keeps its own search index: the extracted text of the library, around two megabytes for several hundred documents, refreshed every fifteen minutes.

That index is a copy of the firm's procedure text held outside SharePoint, and nothing from outside the permitted library ever enters it. The firm knows where it lives and on what terms, in writing, because “where does our data live” now has a second line in its answer.

Where to start

Two questions decide whether a firm is ready, and both will eventually be put to you in writing. Which of your libraries hold client information, and which hold the firm's own knowledge? Where does your data live, and who can reach it? Procedures are the sensible first connection: high value to staff, owned by the firm, nobody's confidential information.

Related reading: Can you connect Copilot or Claude to Xero Practice Manager?
Related reading: Your engagement letter probably doesn't mention AI. After the TPB's new guidance, that's a problem.

Common questions

Can you connect AI to SharePoint safely?
Yes, and you do not have to connect everything. The safest pattern gives the AI its own identity with read-only access to one named document library, so Microsoft's permission system refuses everything else in SharePoint, including client files. Avoid connections that inherit a person's full permissions unless you are confident in every permission that person holds.
Can Copilot or Claude read our SOPs and answer questions?
Yes. Both can answer questions from a firm's procedure documents. Microsoft 365 Copilot does it using each person's existing SharePoint access. A custom connector can do it through a single scoped grant, which keeps the AI's reach independent of how tidy each person's permissions are.
Is it safe to put client files into an AI tool?
Treat client files and firm procedures as different decisions. Client data going into an AI tool can be a disclosure to a third party, which raises consent obligations under the Tax Practitioners Board's guidance on AI use. Procedures, templates and internal knowledge sit outside those obligations, which makes them the sensible place for a firm's first AI connection.
What is an MCP server?
MCP, the Model Context Protocol, is an open standard that lets an AI assistant such as Claude use external tools and data sources. An MCP server is the small piece of software that exposes those tools. Our SharePoint connector's MCP server offers exactly four read-only tools over one library, which is what makes its behaviour easy to reason about and easy to prove.
Nathan James
Founder, Worktopia
Nathan started Worktopia after years inside a Brisbane accounting firm, moving it off legacy systems and into the cloud. He writes about the practical side of security and IT for practices that would rather be doing the work.
Kip, the Worktopia mascot, holding a shield

Know what your AI can reach.

The boundary between the firm's knowledge and your clients' information is the line every AI rollout has to hold. Our Cyber Compliance Health Check maps where your data lives, who can reach it, and what an assistant could see before you connect one.

Start a Health Check or call 1300 856 912