MCP Servers and Client Data: The Permissions Question Nobody Asks
Agencies now connect MCP servers to client systems like QuickBooks and ad accounts. Before you do, understand what write access really means and how to scope it safely.
A recent demonstration made the rounds showing how AI agents with MCP (Model Context Protocol) servers can run an entire agency workflow: prospecting leads, auditing SEO, managing ad spend, and even touching a client’s books. The pitch was compelling. The pricing ranged from a few hundred dollars to five figures. But one thing was missing from all thirteen minutes: any discussion of what permissions the agency was actually requesting from the client.
That gap matters more than the tools themselves.
What MCP servers actually get access to?
An MCP server is a bridge between an AI assistant and an external system. Depending on how it is configured, it can read data or write it. Five of the seven servers in that demonstration connected to systems the client owns: their email list, their ad account, their books.
Read access is one thing. Write access means an agent can create campaigns, modify segments, or alter financial records. That is a materially different level of trust, and it deserves a different conversation.
Which tasks carry the most risk?
Not every use case is equal. Prospecting tools that pull public business data into a lead list are low risk to the client, since they touch systems the client does not own. SEO audits using read-only data sources are similarly contained.
The risk concentrates where writes happen. Building email segments means writing into a list the business spent years earning. “Fixing” wasted ad spend means changing live campaigns. Connecting to QuickBooks means touching their books. Each of these should be scoped deliberately, not granted by default.
How should you scope access?
Before connecting any server to a client system, ask three questions. First, does this task need write access, or is read-only enough? Second, can the access be limited to specific accounts, lists, or entities rather than the whole system? Third, how will changes be logged and reviewed?
Where read-only access works, use it. Where writes are genuinely needed, start with a narrow scope and expand only when a task demands it. Clients should always know which systems an agent can modify on their behalf.
The real product is judgment
The demonstration itself raised the fair question: every business owner can already log into QuickBooks or their ads manager, so what is being sold? The answer given was judgment, and that answer is correct. But the thing being handed over is not judgment. It is write access to the client’s financial and marketing systems.
If you are an agency adopting these tools, make permissions part of your pitch rather than an afterthought. If you are a client being asked to grant access, ask what scope is being requested and why. The agencies that can answer that clearly will have a real advantage over the ones that cannot.