Is It Safe for MSPs to Share Claude Artifacts With Clients?

The Spreadsheet Is Dead, and Your Clients Already Know It

Josh asked a client to build out their sales pipeline, and the client sent back a spreadsheet. Instead of filling it in, Josh opened Claude and built a working model of what the pipeline should be: a small web application with real calculations, editable fields and the client's own prospects in it. Most of it came from the first prompt. Roughly seventy one-line tweaks later, it worked. He did not call an IT person or ask a data analyst for anything. What Claude calls an artifact can be a document, a spreadsheet, a presentation or a functioning app, and for an executive who has always wanted calculators and dashboards but skipped them because they took too long, that changes the economics of every internal tool.

The implication for an MSP owner is that your clients' executives are about to build things whether you are involved or not. The demand for small, specific software inside every business was always there. It was suppressed by cost and time. With that suppression gone, the only open question is who guides it, who secures it, and who gets paid for it.

• AI artifacts collapse the cost of internal tools from a development project to an afternoon, which releases years of pent-up client demand.
• The executive who builds a tool is now doing work that used to route through IT, which moves the MSP's relevance up or out.
• An artifact is often a proof of concept in disguise, and a proof of concept is the beginning of a paid engagement.

Is It Safe for an MSP to Share Claude Artifacts With Clients?

The answer depends almost entirely on how the link is shared. Josh's first instinct was the public share link, the one that lets anyone with the URL open the app. Gary's concern was specific and historical: when shared AI conversations first appeared, people shared them publicly, search engines began indexing those URLs, and information leaked that nobody realized was exposed. A public link holding a client's financials is the same as posting their spreadsheet to the internet. Invite-only sharing is different. The person has to be invited by email and has to authenticate to open it, and the owner can assign them editor, commenter or viewer rights. That is, as Gary put it, the same trust model as right-clicking an Excel file in OneDrive and sharing it to one address. You are trusting the platform's back end, as you already do with Microsoft.

Two practical problems remain even with invite-only sharing. The first is identity friction: during the live recording, Josh shared to an address that was not attached to Gary's account, and Gary could not open the app at all. The second is versioning. Gary shared a multi-page trip agenda as a public page, kept editing it, and his wife kept seeing the old version, because the published link was pinned to an earlier release. Before an MSP builds a client workflow on top of a shared artifact, it has to confirm who can see it, whether they see the current version, and whether the data in it belonged in the tool in the first place.

• Never put client data behind a public AI share link. Treat it exactly as you would a public link to the client's financial files.
• Use invite-only sharing tied to authenticated accounts, and assign the narrowest role that does the job.
• Test what the recipient actually sees after you make changes. A shared link that does not update is a quiet source of bad decisions.

You Already Own the Governance, You Just Have Not Applied It Here

Gary named why MSPs cringe at all of this. Inside Microsoft 365, an MSP can stop employees sharing documents through Teams to anyone outside the organization with a single policy setting. Email can be scanned for sensitive content on the way out. Claude's share button has none of that around it. An employee can drop a data set into a model and then publish an app built on that data through a link the MSP never sees. The instinct to restrict is not paranoia. It is the same instinct that built every data loss prevention policy you already run.

The useful reframe is that this is not a new discipline. Sharing is sharing, and the rules MSPs wrote for OneDrive, Teams and email transfer directly to AI tools: who is allowed to share outside the organization, with whom, what data classes are allowed into the tool at all, and whether the client has agreed to have their data there. Josh's first step with a client's prospects should have been a conversation, not a prompt. Once the client has said yes and the sharing model is invite-only, the risk looks a lot like every other collaboration platform you already manage.

• Ask the client before their data goes into an AI tool. Consent is the first control, not the last.
• Extend existing external sharing policies to AI platforms rather than inventing a parallel rulebook.
• Enterprise and team tiers put users inside a managed tenant, which is where client work belongs.

Restriction Is a Service, Not a Strategy

Gary described a large, very successful, very conservative MSP owner who told BMK flatly that his firm is not doing AI development. If a customer wants it, they will help with governance and guide the journey, but they will not build anything. Josh's view is that this is probably right for that business, which is vertical and serves clients whose demand is predictable. Gary's worry is that it describes most of the industry, and that stopping at restriction is hard to defend as beneficial to any client. He has been on that side himself. When he ran an MSP he wanted everything locked down because he did not want the phone call about a breach.

The trouble is that clients do not feel the value of being locked down. They forget how much the security work protects them, because nothing new happens. They simply stop getting hit with ransomware and assume that is how a business works. What they do feel is friction: blocked sites, slow device approvals, a provider that says no. The MSP that asks how it can generate more leads, more revenue or lower cost for the client, and then uses AI to deliver it, is offering something the client can actually see. In Gary's words, that is the MSP that wins.

• Security work becomes invisible when it succeeds, so it cannot be the only value an MSP delivers.
• A smaller MSP with a diverse client base has the most to gain from exploring AI builds, because it has the least differentiation today.
• Last year's call to move toward advisement still stands. AI tools simply give that advice something tangible to deliver.

From Four-Grand Fixes to Owning the Website

The clearest case in the episode is a small, AI-forward MSP owner who noticed he kept getting tickets about a client's old custom scheduler application. He told the client's CEO he could probably rebuild it. The CEO agreed the app was old, possibly insecure and never did what they wanted. Over a weekend, the MSP fed Claude Code the recorded conversation with the client, screenshots and the old code, and asked it to build a replacement. Around five hours of supervised work later, the new app did everything the old one should have done and signed users in with their Active Directory credentials. He is not a developer. He billed it as a project of about twenty hours at two hundred dollars an hour, roughly four thousand dollars, to fix something that had been broken for years.

Josh's caveat is the right one: an MSP doing this should be candid that it is not a software house, and explore the build with the client rather than posing as an expert. Gary's counter is that custom developers were never uniformly good either, and old code written by rotating teams is often insecure and inconsistent. His sharpest argument is about websites. Most MSPs say they do not do websites, so a contractor (call him Johnny) builds one, and when it gets hacked and starts sending spam, the MSP still takes the call. With AI tooling, the MSP can own that website, secure it, integrate it with the client's scheduler, and make it generate leads. Twenty more leads a month is worth more to a client than a web filter, and the two are not mutually exclusive.

• Legacy line-of-business apps that generate tickets are the most natural first AI build an MSP can offer.
• Price the outcome as a defined project and be explicit about who maintains the result when it breaks.
• Owning the website removes a security blind spot and turns it into a revenue conversation with the client.

Frequently Asked Questions

Is it safe to share a Claude artifact with a client using a public link?

Not if it contains client data. A public link lets anyone with the URL open it, and shared AI content has been picked up and indexed by search engines before. Use invite-only sharing for anything containing real business information.

What is a Claude artifact?

An artifact is something Claude produces alongside a conversation, such as a document, a spreadsheet-style tool, a presentation, a web page or a small working application with calculations and data entry.

How does invite-only sharing in Claude work?

The owner invites specific people by email. Each person must sign in with an account tied to that address, and the owner can assign them the role of editor, commenter or viewer.

Should an MSP ask permission before putting client data into an AI tool?

Yes. In the episode, Gary Boyle separates an MSP's own internal data, where the productivity gain may justify the risk, from client data, where the client has to agree first.

Can an MSP that is not a software developer build apps for clients with AI?

The episode describes a small MSP owner, not a developer, who rebuilt a client's legacy scheduler in Claude Code in about five hours of supervised work and billed it as a roughly $4,000 project. Josh Peterson recommends being explicit with the client that the MSP is exploring the build with them rather than acting as a software house.

Why should an MSP consider building client websites?

Because the MSP already takes the call when a client website is hacked. Gary Boyle argues that AI tools now let an MSP own, secure and improve the site, including turning it into a source of leads for the client.

Episode Highlights

• 01:17 - A Claude demo built for a client held their real prospect data, which opens the question of whether client data belongs in AI tools at all.
• 02:49 - Claude artifacts let an executive build a working app in under an hour, which makes the spreadsheet the wrong default for internal tools.
• 05:06 - Public AI share links have been indexed by search engines before, so a public link holding client data is a leak.
• 06:13 - Invite-only sharing with roles mirrors the OneDrive and Teams governance MSPs already enforce.
• 12:33 - A shared document that silently pins an old version is a governance problem, not just an annoyance.
• 14:13 - A quick AI demo for a client is a proof of concept, and a proof of concept is the start of paid work.
• 15:18 - A conservative MSP that refuses AI development may be right for its niche, but restriction alone does not grow most clients.
• 19:27 - The shift toward advisement that MSPs discussed a year ago now has tangible AI deliverables behind it.
• 21:17 - If you gave up on AI in 2025, you are judging tools that no longer exist, and the only way to see that is to build something yourself.
• 25:22 - Software vendors face pressure to innovate, but no vertical vendor will solve every edge case inside a client's business.
• 28:38 - A small MSP rebuilt a broken legacy app with Claude Code over a weekend and billed about four thousand dollars.
• 37:12 - Trusting AI-written code is a lot like trusting a self-driving car: the comparison is against the average human, not perfection.
• 39:17 - MSPs that do not do websites still own the fallout when one is hacked, so owning the website becomes the better offer.
• 41:38 - Connecting ConnectWise to Claude in read-only mode is teaching account managers about effective hourly rate on their own.

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.

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

• How to measure profitability in ConnectWise or any PSA tool
• Three project indicators that drive MSP profitability margins

Want to Continue the Conversation?

Deciding whether your MSP builds with AI or only governs it is a strategy question, and strategy is what the Vision Operating System is built to answer. If you are working through where AI fits in your services, we would like to hear how you are approaching it.