14 min read

Should an MSP Trust Claude With Client Data?

Picture of Gary Boyle Gary Boyle : Published

BMK Vision Roundtable
Josh Peterson and Gary Boyle discussing whether an MSP should trust Claude with client data and how much AI security risk to accept, on the BMK Vision Podcast roundtable.

Josh Peterson does not lock his car. He will park anywhere in any city, leave the keys in the cup holder, and walk away, and the people who travel with him have learned to say "Josh, please lock the car" every single time. He opened this episode with that confession because it explains something about how he just set up Claude. He created a ConnectWise security role, an API member called Josh's Fun Project, gave it read and write on time and expense settings plus read on agreements and companies, and wired it into a small app that enters his time for him. His starting assumption was the same one he brings to the parking lot: nothing bad is going to happen. Then he asked Gary Boyle whether that makes his skin crawl. The question underneath is the one every MSP owner is now facing, whether they built an integration last weekend or are being asked by a client to approve one: should an MSP trust Claude with client data, and how much AI security risk is the right amount to accept? BMK has been circling this since last week's conversation about whether an MSP should sell the app it built with Claude, and it sits on top of two older arguments about why data risk is the MSP's invisible liability and why your security stack is lying to you. This episode is about the judgment call in the middle of all three.

Gary's answer refuses to be a yes or a no, and that is the point. The leadership judgment is that risk tolerance is a prior you bring to the decision, not an output of it, and most owners have never examined theirs. The execution discipline is that an app built in one or two prompts and an app built from a plan, a scaffold of documented rules and a stated goal carry very different exposure, even when they look identical on screen. The positioning question is what an MSP tells clients it is for: Gary's view is that running AI security audits is simply what an MSP should do, not a differentiator. The financial leverage is the uncomfortable part. Gary calls the gap between an AI-first MSP and a locked-down one a cheat code, and he argues that the data is at risk either way, because you cannot stop a CFO from running the spreadsheets through a model at home on a Sunday night. And the long-term strategy is where the conversation lands: an MSP that moves from using AI to building with it stops being limited by what someone else's software can give it, and the custom work it can now do for every client is the differentiation the industry has talked about for twenty years. What follows is how BMK thinks about each of those.

Listen on Your Favorite Platform

Your Risk Tolerance Was Set Before You Read the Documentation

Josh's unlocked car is a better model of how MSP owners make AI decisions than any framework. When Gary asked whether he leaves the car unlocked because he has never had it broken into, Josh's answer was that people simply do not steal from him; other bad things happen to him, but not that one. It is not an assessment. It is a prior, formed by experience, and it determines what he does before any analysis starts. His ConnectWise integration was built on the same prior. He wanted write access because leaving it at read-only felt like an incomplete project, and he reasoned that the worst case was some bad time entries and a few confused invoices, which would be his fault for bracketing the rules badly rather than Claude going rogue. Gary agreed with that reading, with one condition: it depends entirely on whether Josh knows what the rules are, wrote them down, reviewed them and set a goal the app can be judged against. The honest finding from the first ten minutes is that most owners never examine the prior. They arrive at an AI decision either as someone who parks anywhere or as someone who checks the locks twice, and then they go looking for reasons. BMK's view is that the first act of leadership here is to notice which one you are, because every security conversation you have with your team and your clients will be filtered through it.

  • Risk tolerance is an input to the AI decision, not a conclusion you reach from it. Know yours before you argue about controls.
  • The realistic failure for a scoped integration is bad data from badly written rules, not a model acting on its own.
  • What makes Josh's setup defensible is not the access level. It is that the rules exist, are documented and can be reviewed.

Where the Risk Actually Lives: Keys, Scope and One-Shot Apps

Gary has watched Claude's coding ability move, over roughly a year, from barely able to write working code to running thoughtful tests and stopping itself at problems before the user understands why they are problems. It scopes work carefully and reads the documentation for the APIs it calls. The exposure is not that the model is careless. It is that a non-developer cannot tell whether it chose the right things, and does not know how to feed it bad data to see whether it accepts what it should refuse. His example is simple: give it access to a folder and ask it to clean things up, and deleting everything is a perfectly logical interpretation. The sharper risk is older than AI. When Josh asked where his security risk sits once the business use case is satisfied, Gary's answer was "all over the place," starting with the private and public key pair that makes the API connection work. People paste those keys into text files, documents and email. The worst case is pasting them directly into Claude so it can build the integration, which Josh admitted he had done, and which Claude had scolded him for. Once a key has been in a model, it has been given up; unless you re-key, the model knows it, and nobody can tell you with certainty whether anything that enters an LLM is logged, read or retained. A key pair is a password. Treat it like one.

The deeper discipline is about how the app came to exist. In the vibe-coding world Gary calls it one-shotting: prompting once or twice and accepting whatever comes out because it appears to work. The alternative is the sequence any real development effort follows, a plan, the code and a goal stated up front, with a scaffold of documentation and business rules that the owner reads, corrects where it is wrong, and only then implements. Claude will write most of that scaffolding; the owner's job is to review it. The less you put in, the more the model has to assume about what the rules and the plan should be, and those assumptions are where the surprises come from. An app that was planned can be reasoned about. An app that was one-shot can only be observed.

  • Models now scope and test well. The gap is that a non-developer cannot verify the choices or try to break them.
  • API keys are passwords. If one has touched an LLM, re-key it and decide where the new one lives before you create it.
  • Plan, code, goal. A one-shot app that appears to work has made assumptions you never saw.

How Much AI Security Risk Should an MSP Accept?

Josh's real problem is not his own integration. It is the client conversation. Nine months ago, a client who wanted information out of ConnectWise got sent to BrightGauge or a side spreadsheet. Now Josh can see the path clearly: create the security role, create the member, get into Claude, and build the artifacts and prompts that pull the information on a running basis. He will be pitching that to a trusted service manager or account manager, and then the owner will arrive with a list of everything that has to happen first. Josh's instinct is that the barriers are overkill, and he is honest that he is not a good judge of whether they are. So he asked for a framework: here is minimum effective security, here is maximum, and an MSP lives somewhere in between. Gary's answer started with a diagnosis of the industry. For the past few years MSPs have missed what AI was going to be, and the safe position they gravitate to is an AI governance play: assess which AI tools a client has subscribed to, where AI is embedded in HubSpot or QuickBooks, where data might be leaking out. Gary's view is that this is what any MSP should already be doing, not a specialty and not a strategy, and that stopping there means stopping in fear mode.

Josh reduced the whole question to a fork. Either you believe the LLM companies can access and exploit everything you give them, or you do not. If you believe it, the second question is whether that stops you from using the technology. Gary accepted the fork and then undermined the lock-down branch of it. An owner who decides the data will be taken and therefore bans AI has a policy, and good luck with it. The CFO goes home, does not share the owner's beliefs about security, and faces a choice between five minutes with the spreadsheets in a model or five weeks without one. He already has the files on his home computer. The technology is embedded in the SaaS products the company already pays for, so the data is leaking anyway. Gary's conclusion is blunt: he does not believe you can stop it even if that is your policy, and once you accept that and then see what the models can do, the gap between the production you can get and the risk you were trying to avoid is almost unfair to the people who quit at the first level. BMK's position is that the right amount of risk is not a number. It is whatever amount you can accept with your eyes open, having first admitted how much is already being taken.

  • Running AI security audits for clients is table stakes, not a differentiator. The MSPs that stop there have chosen fear mode.
  • A lock-down policy does not stop the leak. It moves it to the CFO's home computer and the SaaS tools you already pay for.
  • Decide the fork consciously: can they take it, and will you play anyway? Then size the risk you are willing to accept.

Should an MSP Trust Claude With Client Data?

Josh framed the question as a matter of consistency. If his fear is that some entity can get his clients' names, financials and the details of how they do business together, then he has to apply that fear to every tool he uses. He has already decided to trust ConnectWise, which has everything. He trusts QuickBooks Online, which has everything. Why would he conclude that the LLM is the bigger risk than either of them? If he fears one, he should fear them all. Gary took the argument further. He does not know whether ConnectWise runs AI agents in its back end today, but he knows plenty of partners have connected software to it that analyzes the data with AI, and his belief is that eventually all software will use AI, so the question becomes which models those vendors are using and whether they protect the data the way a cloud provider was expected to in 2020. Then he reached back a decade. The 2010s were "move everything to the cloud," and in doing that every business trusted everyone with all of its data without knowing what would be done with it. Plenty of cybersecurity incidents since have shown it was not safe. The question now is simply whether the LLMs get the same data set the cloud already has. Gary's personal view is that you should not trust anyone, and in the same breath he said that if the policy makes you miss what the technology can do for you, the trust question is almost beside the point.

The cost of answering no is not theoretical. Josh was at a client site, with the owner away, working in an employee's Claude on a budget and forecast from a screenshot of their financials. The moment he moved the work from his own Claude to theirs, it refused: this contains your company's information, I cannot use it. They tried calling it a sample company and asking it to forget the name, and nothing worked. The good news is the client had secured it exactly as intended. The bad news is that the team lost all momentum and there was no version of that exercise they could do without AI. Josh's question to the owner afterward was whether unusable was what he wanted. Gary's answer to the lock-down instinct is the iPhone test: anyone can set a phone on a stand, record a video of their screen walking through every report, and feed the video to their own Claude, which will digest every number on it. For an enterprise with USB controls, mail filters and a locked cloud environment, restriction might be achievable. For the small and medium businesses MSPs actually serve, there is almost literally no way to stop the data leaving. Which brings Gary to the cheat code. Picture all your competitors locking down, lock down, lock down, no AI here, it will steal our information, and one or two of them saying screw it, I can get ten times more done, I do not need the billing department I once needed because the assessment and the billing take a couple of hours instead of a couple of weeks. Those are the ones who accelerate. Yes, their data is in trouble too. Everyone's is.

  • If you trust ConnectWise and QuickBooks with everything, singling out the LLM is not a security position. It is an inconsistency.
  • A control strict enough to stop an employee from using AI is usually strict enough to stop the work, and it still does not stop the leak.
  • The cheat code is real: AI-first MSPs pull ahead of locked-down ones while carrying the same data exposure everyone already has.

Two Forms of Risk, and the Levels That Follow

Josh's worry about his clients is that they will reach for an ethical standard, my ethics will not allow me to put client data at risk, and use it to do nothing. Gary granted that the concern is massive, and then named the second risk that nobody puts on the whiteboard: the risk of holding your clients back from doing more. History is full of the first kind of risk being treated as unthinkable until it was not. Putting a credit card into a website to buy from a stranger was, at one point in our lifetime, insane. Move fast and break things built Facebook and Uber, which would not exist if it had waited for permission to operate. The blacksmiths were right that cars would kill people, and the world decided it was worth it. Gary's claim is that MSPs are at that crossroad with the newest technology of their lifetime, trillions of dollars are being poured into it, and participating costs twenty dollars a month. He has never seen a bet that cheap to make, provided you analyze the risk properly. Josh's counterweight is from 2006, when he came back from ConnectWise's offices evangelizing so hard that a friend told him he was always selling some new idea. Of the fifteen things he has pushed over twenty years, maybe four came true. He feels the same conviction now, and Gary's advice from the week before holds: you cannot force a client to move faster than they are willing to. You can still demand the outcome you need as their consultant. They choose whether to make it hard on themselves or take the counsel and get there faster.

Where should an MSP be? Gary's levels from the previous episode set the scale. Level one uses ChatGPT as a search replacement and makes some images, and the harness keeps getting better. Level two is production: putting your own data in, building a dashboard that shows relevant numbers, processing the spreadsheet faster, finally producing the charts you never had the patience to build. Many MSPs are not there yet, especially when advising clients. Level three is a real application, not a single-person artifact, living on a cloud server with a database and scheduled jobs, home grown by the MSP or by a client with the MSP's help. That is where Gary wants people, because once you are there you are no longer limited by what someone else can give you. Most of the applications MSPs resell are, in his words, terrible, which is why everyone keeps switching, and the distance from level two to level three is a few more weekends of real digging. You cannot cross it without risking some of your data; nothing productive comes out of refusing to. Level four is a production app that consolidates several tools in a client's environment, and that is a different company, a software development company that also has an MSP. Josh's practical path is to pick the dashboarding tool or the PSA-to-accounting connector in your own stack and replace it as practice. Gary's warning is that the connector itself is a commodity headed to zero; the opportunity is the proof of concept you run on yourself, and then the custom application you can build for every client who has the same problem.

  • Holding clients back is a risk too. Weigh it against the data risk instead of pretending only one of them exists.
  • The bet costs twenty dollars a month. The analysis of the risk is the part that deserves your time.
  • Level three is the goal, level four is a different company, and the market is custom applications for clients, not one more SaaS tool.

Frequently Asked Questions

Should an MSP trust Claude with client data?

Not more or less than it trusts any other vendor that already holds the same data. An MSP that keeps everything in ConnectWise and QuickBooks Online has already decided to trust cloud vendors with its clients' information, and most of those vendors are adding AI to their back ends. The consistent position is to apply the same scrutiny to the LLM, scope what it can reach, keep credentials out of it, and accept that refusing to use it carries its own risk of holding the business and its clients back.

How much AI security risk should an MSP accept?

Enough to get real production out of the technology, decided with eyes open. The conversation argues that the data is already exposed through the SaaS tools a business pays for and through employees working at home, so a lock-down policy rarely eliminates risk. The practical approach is to acknowledge what is already leaking, scope AI access deliberately, protect credentials, and then set a risk tolerance you can defend rather than one driven by fear.

Is it safe to paste API keys into Claude or ChatGPT?

No. A public and private key pair is a form of password, and once it has been entered into a model you should assume it has been given up. Re-key the integration, store the new credentials somewhere secure rather than in a text file, document or email, and question whether you needed to expose them at all.

What is the difference between one-shotting an app and planning it?

One-shotting means prompting a model once or twice and accepting an app that appears to work. Planning means stating a goal up front, building a documented scaffold of business rules, reviewing and correcting it, and only then implementing the code. The less input the owner provides, the more the model assumes about what the rules should be, and those assumptions are where unexpected behavior comes from.

What is the AI cheat code for MSPs?

It is Gary Boyle's name for the advantage an AI-first MSP holds while its competitors lock the technology down out of fear. Work that took a billing department days or weeks can take hours, and the MSP that accepts that its data is already exposed, like everyone's, and uses the tools anyway accelerates past the ones that do not.

What are the levels of AI maturity for an MSP?

Level one uses AI as a better search engine and writing tool. Level two puts business data into it for production, such as dashboards and faster analysis. Level three builds a real application with a database and scheduled jobs that the MSP or a client owns. Level four is a production app that consolidates several tools in a client environment, which effectively makes the MSP a software development company as well.

Episode Highlights

  • 00:00 - Cold open: if you trust ConnectWise and QuickBooks with everything, why would the LLM be the bigger risk?
  • 00:37 - Josh parks anywhere and leaves the keys in the car, which is the prior behind his AI risk tolerance.
  • 02:24 - Josh gave Claude a ConnectWise API user with write access to his time entries and asks whether that is reckless.
  • 05:28 - Claude scopes and tests code well now, but a non-developer cannot verify its choices or try to break them.
  • 08:37 - One-shotting an app is different from plan, code and goal, and the difference is where the surprises come from.
  • 11:37 - API keys are passwords; once one has been pasted into a model it has been given up and needs re-keying.
  • 14:36 - Advising AI-curious clients means running into owners with a list of everything that has to happen first.
  • 16:59 - MSPs missed the mark on AI and settled for a governance play that is table stakes, not a strategy.
  • 20:00 - The fork in the road: can the LLM companies take your data, and will you play anyway?
  • 22:56 - Fearing the LLM while trusting ConnectWise and QuickBooks is an inconsistency, not a security position.
  • 24:05 - All software will use AI, and the cloud decade already handed everyone's data to vendors nobody verified.
  • 26:16 - A client's locked-down Claude refused its own financials and stopped a forecasting exercise cold.
  • 28:26 - An iPhone pointed at a screen defeats most SMB controls, so lock-down rarely stops the leak.
  • 30:11 - What am I stopping? The AI cheat code that lets AI-first MSPs pull ahead of locked-down competitors.
  • 31:57 - Without a shared definition of the risks, owners fear the wrong things and apply ethics as a reason to do nothing.
  • 33:33 - Two forms of risk: leaking data and holding clients back, with online credit cards and cars versus horses as precedent.
  • 36:23 - Josh evangelized ConnectWise in 2006 the same way, and clients still cannot be forced to move faster.
  • 39:15 - Levels one to three, and why an MSP advising clients needs to be building, not just consuming.
  • 41:37 - At level three you are no longer limited by what someone else's software can give you.
  • 44:24 - Level four is a production app that consolidates tools, which makes the MSP a software company too.
  • 45:10 - Two practice projects: replace your dashboarding tool, then the PSA-to-accounting connector.
  • 47:34 - Run the proof of concept on yourself, then build custom applications for every client with the same problem.
  • 50:16 - Sixteen months into this conversation: go find a project and do your own risk assessment.

About the Co-Host: Gary Boyle

Gary Boyle is a Partner for Strategy & Business Development at Bering McKinley. With a background spanning network engineering, entrepreneurship, and strategic consulting, Gary brings real-world operator experience to helping MSP owners build stronger, more profitable businesses. On the Vision roundtable he co-hosts with Josh Peterson, working through the decisions that determine how an MSP grows, sells and runs.

Connect with Gary on LinkedIn →

About the Host: Josh Peterson

Josh Peterson is the CEO of Bering McKinley and host of The BMK Vision Podcast. Since 2004, Josh has worked with hundreds of MSP owners to build operationally sound, profitable businesses through consulting, peer teams, and direct coaching.

Connect with Josh Peterson on LinkedIn →

Related Resources from Bering McKinley

Want to Continue the Conversation?

Deciding how much AI risk an MSP accepts is a planning decision before it is a security setting, and it belongs in the same place as every other bet the business makes. Setting that tolerance deliberately, with goals and a plan behind it, is what the Vision Operating System is built to do.