Personal AI accounts are the real leak: how MSPs can let clients use AI without exposing the data

The bigger AI data risk is usually the account users sign in with, not the AI tool itself. Verizon's 2026 DBIR found 67% of AI users on corporate devices use non-corporate accounts. MSPs cut that risk by approving the AI tools the business needs on business-tier plans, steering logins to them, blocking pastes and uploads to unapproved AI, and reporting what happens.

Why blocking AI stopped working

For a while, the answer to AI risk was to block it. Block ChatGPT, publish a policy, move on. That stopped working once AI moved inside Microsoft 365, Google Workspace, and the browser itself.

Blocking also has a side effect anyone who has tried it will recognize. People don't stop using AI. They move to a phone, a home laptop, or a free account they set up themselves. The work still gets done, just somewhere the business can't see and doesn't own.

So the useful question isn't "how do we keep AI out?" It's "whose account is the data going into?"

How common are personal AI accounts at work?

More common than most business owners assume. Verizon's 2026 Data Breach Investigations Report found that two in three AI users on corporate devices sign in with non-corporate accounts. IBM's Cost of a Data Breach Report 2026 saw the share of security incidents involving shadow AI more than double in a year, to 43%.

The pattern behind those numbers is easy to picture. Someone is up against a deadline, the approved tool is blocked or clunky, and a free AI account is one tab away. Nobody thinks of it as a security decision, which is exactly why it rarely gets treated as one.

Why is a personal AI account riskier than a business one?

The same prompt carries different risk depending on where it lands. In a business workspace, the company sets the terms. In a personal account, the employee does, and the MSP can't see any of it.

The offboarding row is the one to underline. Every personal account full of client work is a small archive that leaves with the next resignation, and nobody at the company can audit or delete it.

For an MSP, that reframes the job. You don't need to stop clients using AI. You need their staff using AI in accounts the client owns.

How can MSPs let clients use AI without losing the data?

Six steps, in this order. The goal is to make the approved path the easy one, and every other path visibly harder.

1. Approve the tools people need, on business plans. Most clients need more than one AI tool: a general assistant, the copilot built into their productivity suite, maybe a specialist tool for one team. Agree on the list with the client and put each tool on a business or enterprise tier, where the company owns the workspace and training is off by default. Which tools is the client's call. Your job is to make the choice stick.
2. Make the approved tools the default. Allow the approved AI sites, warn on the ones you haven't reviewed, and block the ones you've ruled out. Category-based filtering handles the long tail of new AI sites. Plan for one catch: Microsoft 365 apps now carry Copilot features, so blocking an entire AI category can break Word, Excel, Outlook, etc., unless you allow the Microsoft 365 URLs first. And remember desktop AI apps and AI browsers, which web filtering alone doesn't cover. Atakama’s built in AI controls guide walks through these rules so that an AI hardening rule can stop desktop apps such as ChatGPT, Claude, and Microsoft Copilot from launching on Windows and Mac devices running Atakama.
3. Steer sign-ins to business accounts. Approving a tool doesn't help if users log in with a personal email. Use single sign-on where the AI vendor supports it, and add a browser-level check that warns or blocks when someone types personal credentials into an approved AI tool. Expect gaps: passwordless sign-ins, passkeys, and sessions that are already signed in don't show a password field to check. Atakama's SaaS login control does this using the client's business domains, scoped to the whole tenant, specific users, and security groups.
4. Close the paste and upload paths to unapproved AI. Blocking pastes and file uploads to AI sites you haven't approved shuts the most direct way data leaves, without blocking the sites themselves. This acts on the destination, not the content. It's the right control for "nothing goes into AI we haven't approved," not for filtering individual sentences. In Atakama, clipboard and upload blocking targets destinations by URL, content category, or business app classification.
5. Watch what goes into the approved tools. Even on a business plan, some data shouldn't go into a prompt: credit card numbers, ID numbers, patient details. Prompt-level detection flags those so you can coach the person and tighten policy. Treat it as a signal, not a filter. Atakama's sensitive AI prompt detection covers the web versions of ChatGPT, Claude, Copilot, Gemini, Grok, Meta AI, Perplexity, and DeepSeek, without storing the prompts themselves.
6. Show the client what changed. A control the client never sees is easy to cut at renewal. Report approved versus unapproved AI use, what was warned on or blocked, and where sensitive data showed up, then walk through it at the quarterly review. Atakama's Client Health Report is shipped monthly to clients and includes AI usage and block and warn counts.

If you manage many clients, build this once: a baseline policy that applies to every client, with client-specific exceptions layered on top. In Atakama, that's a global policy with tenant-specific rules scoped to specific end users, security groups, and locations.

What should you check before approving an AI tool?

Before a tool goes on a client's approved list, get a clear answer to each of these questions. A "no" doesn't always rule a tool out, but it should change how tightly you control it.

1. Is there a business or enterprise plan, and will the client pay for it? A tool with only consumer plans can't be brought under company ownership.
2. Is training on company data off by default on that plan? Check the vendor's own policy page, not the sales deck.
3. Does the company own the workspace? Admins should be able to add and remove users and keep the data when someone leaves.
4. Does it support single sign-on or domain controls? If staff can sign in with any email, a personal account is always one click away.
5. Is there an admin console or audit log? You need to see who uses the tool without asking each person.
6. Where is the data stored, and for how long? Some clients have residency or retention rules in their contracts or regulations.
7. Does it have a desktop app, browser extension, or agent features? Each is a separate path to cover, and some sit outside browser controls.
8. What does it connect to? Connectors to email, file storage, or a CRM let the tool reach far more data than what's typed into it.
9. Who at the client signed off, and when will you review it? Write it down. AI tools change their terms and features often.

What does this look like for a 25-person firm?

Here's how it typically plays out, using a hypothetical 25-person accounting firm as the example.

Before. The firm blocked ChatGPT last year after a partner read about AI data leaks. End users quietly moved on. A few use ChatGPT on their phones to draft client emails. Someone in advisory pays for a personal AI subscription. Copilot has appeared in Outlook, and nobody is sure whether it's allowed. The MSP has no idea what client data has gone where.

The decision. In a 30-minute conversation, the managing partner and the MSP agree on three approved tools: Microsoft 365 Copilot for everyday drafting, ChatGPT Business for research and analysis, and the tax research tool the advisory team already relies on. Everything else in the AI category moves from blocked to warn for 30 days, so the MSP can see what people reach for before deciding what to block for good.

What changes for end users. Each person gets a company ChatGPT login tied to their work email. If someone tries to sign in with a personal address on a work laptop, they see a warning. Pasting into AI tools that aren't on the list is blocked, with a short explanation and a way to request access. Day to day, most people notice one thing: the AI tools they wanted are now allowed.

What the MSP reports at the next review.

• Which AI tools people used, approved and unapproved
• How many warnings and blocks fired, and whether that number is falling
• Which access requests came in, and which tools to add or rule out
• Any prompts flagged for sensitive data, such as client Social Security numbers, so the business can follow up with training

The company ends up using more AI than before, and the MSP finally has governance in place and can show where the data goes.

How should MSPs raise AI governance with clients?

Lead with enablement, not fear. Most business owners already suspect their employees use AI. What they don't want is another lecture about risk, or a bill for blocking something their team finds useful.

A better way to frame it at the quarterly review:

• Start with what's already happening. Show which AI tools people are using today. That one page usually does the persuading for you.
• Offer a yes, not a no. Position the service as getting staff the AI tools they want, on accounts the business owns. The controls come second.
• Tie it to what the owner already cares about. Client confidentiality, contracts that limit where data can go, insurance and compliance questionnaires about data handling, and what walks out the door when someone leaves.
• Agree on the approved list together. The client picks the tools; you make the choice stick. The decision stays with the business, where it belongs.
• Make it recurring. AI tools change and new ones introduced regularly. A standing line item to review usage, approve or retire tools, and report on exceptions turns a one-off project into an ongoing service.

Done this way, AI governance reads as the MSP helping the business adopt AI safely, not as one more thing the MSP says no to.

What MSP partners say

The goal is control that clients barely notice, so staff keep using AI and the MSP keeps the data in the right accounts.

"Atakama has become a critical part of how we protect and manage the modern browser. The visibility and control it gives us is a value add for our customers, helping us secure users without adding friction to their day-to-day work."

Ryan McNally, COO, Courser

FAQ

Can EDR see what employees paste into ChatGPT?

Usually not at the level of what was pasted. EDR is built to watch processes, files, and system behavior on the endpoint, not text typed into a web page. Some vendors sell separate data protection modules for that. A browser-level control sees the paste and the sites it's going to.

Should we just block ChatGPT and other AI tools?

Blocking everything tends to push more shadow AI use with less visibility. A better pattern is to approve the business-tier tools people need, make them the easiest option, and block or warn on the rest.

How do I stop employees using personal ChatGPT accounts at work?

Give them business accounts first, then enforce them. Use single sign-on where the AI vendor supports it, plus a browser-level check that warns or blocks personal credentials on approved AI tools; Atakama's SaaS login controls are one option. Passwordless logins, passkeys, and existing sessions are hard to catch, so pair the control with a clear policy.

Do prompt-monitoring tools store employees' AI prompts?

It depends on the tool, so ask before you buy. Some keep prompt text for review; others log only what was detected. Atakama's sensitive AI prompt detection logs the date, app, user, and data type, and doesn't store the prompts themselves.

What should an MSP look for in an AI governance tool?

Multi-tenant management, allow, warn, and block per AI tool, controls on pastes and uploads, a way to tell personal logins from business ones, coverage for desktop AI apps, and reporting a client can read. Ask each vendor which of these work today and which are on the roadmap.

Can an MSP manage AI controls across many client tenants?

Yes, if the tool is built for it. Look for a baseline policy you set once and apply to every client, with per-client exceptions on top. In Atakama, that's a global policy plus tenant-specific rules scoped to specific users, security groups, and locations.

Next step

For more on running AI governance per client, see the AI security use case page, browser DLP, and credential risk. Related: how to make a client's AI policy enforceable and block, warn, or redact for AI data leakage.

Sources

• Verizon, 2026 Data Breach Investigations Report, pp. 12-13
• IBM and Ponemon Institute, Cost of a Data Breach Report 2026, July 2026
• OpenAI, How your data is used to improve model performance and Managing data, sharing, and privacy in ChatGPT Business