Block, warn, or redact: how MSPs should stop AI data leakage for small clients

Most AI data leakage at a small business runs through two paths. End users paste or upload client data into AI tools nobody approved, and they type sensitive details into the tools that were approved. For most small clients, the right setup is to block pastes and uploads to unapproved AI outright, monitor prompts on approved tools for sensitive data types, and warn on personal logins. Redaction has a place, but mostly for regulated clients with structured identifiers and someone to tune it.

Where does AI data leakage happen at a small business?

Rarely through one dramatic event. It happens in small, ordinary moments, spread across five paths:

• Pastes into unapproved AI tools. A client email, a range of spreadsheet cells, or a contract clause copied into a free AI chat to get a quick summary.
• File uploads. A payroll export, a scanned intake form, or a full contract dropped into an AI tool to "check it over."
• Personal accounts on approved tools. The domain is the same as the company's approved assistant, but the account isn't. Business plans from the major AI vendors generally keep customer data out of model training by default and give an admin control over the workspace. A personal account gives the business neither.
• AI inside existing apps. Copilot in Microsoft 365 and AI features in the CRM, help desk, and accounting system process data under each vendor's own settings.
• Desktop apps and agents. Native AI apps and agents work outside the browser, so browser-based controls don't see them.

Each path needs its own control. That's why a single "AI DLP" switch rarely works for a small client, and why the first task is deciding which response fits which path.

Should you monitor, warn, block, or redact?

Every AI data control comes down to four responses. Each one trades protection against friction differently, and most small clients need three of them at once.

The stance for unapproved AI should be firm. There's no business reason for client data to go into a tool nobody has reviewed, so block pastes and uploads there rather than warn. Content-aware decisions belong on the approved tools, where end users are supposed to do their work.

There's also a practical difference between the two kinds of rules. A destination rule, such as "no pastes into AI sites outside the approved list," rarely misfires, since it doesn't need to understand the text. A content rule, such as "flag prompts that contain account numbers," is smarter but sometimes wrong. That difference shapes everything in the next section.

What can sensitive data detection actually recognize?

Detection is good at patterns and weak at meaning. Knowing which is which keeps an MSP from promising a client more than the tool can deliver.

• Structured identifiers detect well. Card numbers can be validated with checksums, so most random 16-digit strings don't count. Social Security numbers and phone numbers are recognizable, especially when nearby words such as "SSN" or "phone" add context. Bank account numbers have no standard format, so they're hard to spot without words like "account" nearby.
• Names are less reliable. Named entity recognition models recognize many names, but accuracy drops on unusual names, nicknames, and names that double as ordinary words.
• Context is invisible. A memo about an upcoming acquisition, a pricing strategy, or a client's legal problem described in plain words contains no pattern to detect. Detection won't catch it, which is why training and an approved tool list still matter.

Scale changes how much false positives hurt. At an enterprise, a security team absorbs the noise. At a 20-seat client, ten false alerts a week is noise someone at the MSP must read, and under a block or redact rule a false positive stops or changes real work. For most small clients, that makes monitoring the right response for content on approved tools and blocking the right response for destinations that aren't approved.

Who handles the alerts?

Decide this before turning anything on. An AI data control that produces alerts nobody reads is worse than none because the client assumes someone is watching. A simple model works for most MSPs:

1. Separate reports from tickets. Blocked pastes and uploads to unapproved AI belong in a monthly report, not the ticket queue. The control already did its job.
2. Ticket only what needs a person. A prompt flagged for a high-risk data type, such as health identifiers or card numbers, at a client where that data is regulated deserves a ticket. A phone number in a prompt usually doesn't.
3. Group events. One ticket per end user per day is enough. Ten tickets for ten pastes from the same person will result in technicians ignoring the queues.
4. Treat unblock requests as service requests. Route them into the PSA with a response target, such as one business day. A slow answer pushes end users toward their phones and personal laptops.
5. Set a noise budget per client. If a rule produces more tickets than a technician can review in a few minutes a week, tune the rule rather than the technician.
6. Report patterns to the client, not people. The quarterly review shows trends by data type and tool. Names go to the client's owner privately, if at all.

The reporting side connects directly to policy. If the client's AI policy says certain data never goes into AI, these reports are the evidence that the rule is enforced. For more on that, see how to make a client's AI policy enforceable.

What does this look like for a small client?

Take a hypothetical 15-person accounting firm heading into tax season.

The starting point. End users paste client figures into free AI chat tools to draft emails and explain tax notices. One partner uploads full returns to a personal account to summarize them. Nobody has decided which AI tool is approved, and the firm handles Social Security and bank account numbers every day.

Weeks 1 and 2, monitor. The MSP turns on visibility without blocking anything new. The picture is typical. Two free AI tools account for most use, and a handful of end users account for most uploads.

Week 3, decide. The partners approve one AI assistant on a business plan, with company accounts for everyone who needs it. Every other AI tool is ruled out for client data.

Week 4 onward, enforce.

• Pastes and uploads to every AI site outside the approved assistant are blocked, and blocked uploads and pastes offer unblock requests.
• Prompts on the approved assistant are monitored for Social Security numbers and card numbers. A hit on either means the MSP opens a ticket, since that data is exactly what the firm can't lose.
• Signing into the approved assistant with a personal account triggers a warning that points to the firm account.
• Redaction stays off. The firm's work involves numbers that look like identifiers all day, and the partners would rather review a monthly report than have prompts altered mid-task.

The first monthly review. Blocked uploads drop after the first two weeks as end users move to the approved assistant. A few flagged prompts show where end users need a reminder. One partner asks for a second tool, and the MSP adds it to the approved list after a review.

The firm didn't stop using AI. It started using one tool it can see into.

How does this map to Atakama?

Atakama covers the monitor, warn, and block responses. The Clipboard and upload blocking rule stops pastes, file uploads, or both on destinations the MSP chooses, such as AI sites outside the approved list. On AI web apps including ChatGPT, Claude, Copilot, Gemini, and Perplexity, Atakama flags prompts that contain sensitive data types, such as card numbers, health identifiers, and phone numbers, and lists them on the Sensitive AI prompts tab of the Data Loss Prevention Insights page without storing the prompts themselves. SaaS login controls warn end users who sign in to an approved app with a personal account, where a password is entered.

For desktop AI apps, the AI hardening rule blocks unapproved apps from running on managed devices with the Atakama endpoint service. For MSPs, the benefit is one set of AI data rules applied across every client tenant from the same console, with a global baseline and client-specific exceptions on top.

FAQ

What is prompt-level AI DLP?

Controls that inspect what end users type, paste, and upload into AI tools and respond when it contains sensitive data. The response can be a report, a warning, a block, or redaction of the sensitive values before the prompt is sent.

Should MSPs block ChatGPT for small clients?

Not as a blanket rule. Approve the AI tools the business needs on business plans with company accounts, then block pastes and uploads to everything else. A total ban pushes end users to personal phones and laptops, where the MSP sees nothing.

Can Microsoft 365 block sensitive data from reaching AI sites?

In part. Microsoft Purview’s inline DLP in Edge for Business can audit and block text and file uploads to many consumer AI apps. Protecting data sent to unmanaged apps is a pay-as-you-go feature, it works only in Edge for Business, and its unmanaged-app policies apply to Windows devices managed by Intune. With a block policy in place, Purview also stops in-scope end users from using browsers the policy doesn't cover.

Is redacting sensitive data better than blocking it?

For most small clients, no. Redaction keeps work moving, but a false positive changes an end user's prompt without their noticing, and redaction can't recognize sensitive information that has no pattern. Blocking unapproved destinations and monitoring approved tools is simpler to run and easier to explain to the client.

Does AI DLP catch everything?

No. It misses sensitive information described in plain words, activity on unmanaged personal devices, and, for browser-based tools, native desktop AI apps. Pair it with an approved tool list, training, and controls on desktop apps.

What should an MSP report to the client?

Which AI tools end users rely on, how many pastes and uploads were blocked, which sensitive data types were flagged in prompts, and whether those numbers are falling. Show patterns rather than names.

Keep reading

For more on AI data protection across clients, see why personal AI accounts are the real leak, how to make a client's AI policy enforceable, how MSP policy inheritance should work, and our AI security use case page.

Sources

• Microsoft Learn, Learn about Microsoft Purview data loss prevention for browsers