AI Hardening 101 for MSPs

A practical breakdown of controls you can deploy today — and what to think about next.

Your clients are using AI tools. Most of that usage is happening without your knowledge or approval. And unlike regular web traffic, AI interactions carry something uniquely risky: sensitive data, in plain language, flowing to third-party services you have limited visibility into.

A user pasting a patient intake form into ChatGPT. A paralegal running a client contract through an AI summarizer. A finance analyst prompting Copilot with revenue figures. These aren't edge cases — they're happening daily, across every vertical you support. The data goes somewhere. It gets processed, potentially stored, and in some cases shared with downstream integrations you didn't know existed.

For MSPs, this creates three distinct problems. First, compliance: if a client in healthcare, legal, or finance has sensitive data exfiltrated through an AI tool, you're in the conversation whether you want to be or not. Second, access control: AI tools can surface data the user was never supposed to see — a misconfigured Copilot permission set can expose SharePoint files across departments. Third, exfiltration: intentional or not, sensitive data leaves the client environment in a way that's invisible to most existing security stacks.

The good news is that you have more controls available than most MSPs realize. The challenge is understanding where each one actually sits in the data flow, and what it can and can't see.

The data flow

Before any control makes sense, you need to understand the journey. Here's what happens when a user interacts with an AI service — from the moment they open a browser tab to the moment the response comes back.

Each layer in that flow is a potential control point. But not all of them are equally useful for AI — and understanding the gaps is the key to building something that actually works.

Layer 1: DNS and network filtering

DNS filtering is the easiest place to start. You block the domains, you block the service. Fast to deploy, no complex configuration, and effective for stopping access to unsanctioned tools entirely.

The problem is that DNS is blunt. You can block chat.openai.com, but you can't distinguish between a user running a legitimate business query and one pasting a client's confidential data. You're choosing between all access or no access — there's no middle ground. And critically, DNS operates before the browser even loads. It can't see what's inside a conversation once access is granted.

Network-layer controls — SASE solutions, next-gen firewalls — give you more granularity. You can inspect outbound traffic, flag suspicious data patterns, and block based on content. But network inspection has real limitations when applied to AI traffic specifically. Most AI services use HTTPS. Without SSL inspection, you're looking at the destination, not the content. And SSL interception introduces its own complexity — certificate errors, latency, and the operational overhead of managing exceptions. It's a broad-stroke tool on traffic that increasingly needs surgical precision.

Use DNS and network controls as your perimeter layer. They're worth having. But don't mistake them for AI governance — they're not seeing what actually matters.

Layer 2: Browser-level control

The browser is where the actual interaction happens. The user composes the prompt, attaches a file, and submits. Everything up to that moment — DNS, network, firewall — has no visibility into what's being sent. A browser agent does.

With a browser extension deployed to managed devices, you can inspect the actual prompt before it leaves the client environment. That means you can flag a prompt containing PHI before it reaches the AI service, block an unsanctioned tool regardless of what DNS policy is in place, and enforce per-user or per-tenant policies — allowing certain departments to use specific tools while restricting others.

This is also where a subtle but important risk lives: data exposure through AI responses. If a client's Microsoft Copilot is misconfigured and a user's query surfaces documents they shouldn't have access to, that exposure happens in the browser. You won't see it at the DNS layer or the network layer. Browser visibility catches it.

The other thing browser-level control survives: edge cases. A user on a home network, connecting through a personal hotspot, bypassing your corporate DNS — the extension is still there. The prompt still passes through it. Controls that rely on routing traffic through your infrastructure fail the moment a user steps off the managed network. Browser-level controls don't.

Layer 3: Cloud-side visibility

Once a prompt reaches the AI service, it's in the vendor's environment. You no longer control it. The vendor processes it, stores it according to their retention policies, and may pass it to downstream integrations — plugins, APIs, connected apps — that you didn't authorize and probably don't know about.

This is where visibility tools that reach into cloud services matter. For Microsoft environments with the right licensing and device enrollment, Purview can surface AI activity — what users are querying, what sensitive data patterns are showing up in prompts and responses. But it requires setup: device onboarding, DLP policy configuration, and in some cases a SASE integration to capture traffic from non-Microsoft services. The fuller the deployment, the more it covers — but the more infrastructure it requires.

For tools outside the Microsoft ecosystem — standalone ChatGPT, Claude, Grok, and others — you need SaaS visibility tools that audit connected integrations and data flows at the OAuth layer. What's connected to what. What permissions have been granted. What data the service is authorized to access.

Cloud-side visibility is inherently reactive. The data has already been sent. But it's the right layer for compliance documentation, audit trails, and identifying oversharing before it becomes a breach notification.

Layer 4: Policy and governance

None of the above is worth much without a policy that defines what you're enforcing. A clear AI usage policy — which services are sanctioned, what data types are off-limits, how violations are handled — is the foundation that makes every technical control meaningful.

Without it, you're reacting to incidents. With it, you have something to point to when a client asks why their user was blocked from submitting a prompt, or when a compliance auditor asks how you're managing AI data exposure.

An AI Acceptable Use Policy doesn't need to be long. At minimum it should define sanctioned tools, data classification rules (what can and can't go into an AI prompt), and an acknowledgment process so users can't claim they didn't know. Tie it explicitly to the technical controls you have in place — DNS rules, browser policies, audit logs — so the policy and the enforcement match.

Putting it together

No single control covers the full picture. The goal is layered defense — each layer catching what the others miss.

Layer	What it catches	Where it falls short
DNS filtering	Access to unsanctioned services	All-or-nothing; no content visibility
Network / SASE	Traffic patterns, volume, destination	Encrypted traffic; broad-stroke; off-network blind spots
Browser agent	Prompt content, data in files, real-time policy	Requires managed device deployment
Cloud DLP / audit	AI activity within connected platforms	Reactive; requires licensing and infrastructure
OAuth governance	Shadow AI integrations, standing permissions	Periodic auditing required; doesn't prevent real-time exfil
AI usage policy	User behavior, accountability, audit trail	Only as good as enforcement — generate one free here

Start with what you have. DNS filtering and a written policy costs nothing to implement today. Add browser-level visibility as your precision layer. Work from there based on your clients' risk profile and compliance requirements.