How to make a managed IT provider (MSP) AI-native: a playbook

On 2 July 2021, attackers used flaws in Kaseya VSA, a remote monitoring and management (RMM) product, to push ransomware through about 60 managed service providers to between 800 and 1,500 of their clients. In Sweden, the Coop grocery chain closed about 800 stores for almost a week[43]. Those businesses were reached through the tool their IT provider used to look after them.

Every MSP runs that kind of channel. The RMM agent on each endpoint, the PSA that holds every client's tickets and contacts, the documentation tool with the passwords, and delegated admin access to each Microsoft 365 tenant add up to standing access to dozens of other companies at once. The Five Eyes cyber agencies wrote a whole advisory about it in 2022[1].

In April 2026 Kaseya, which also owns Datto, launched agents it says work "without manual intervention", and contrasted them with tools that "surface a recommendation and hand it to a technician"[28]. Agents are about to drive the channel attackers used in Kaseya VSA. The question for an MSP is who each agent acts for, which client it can reach on a given call, and whether anyone can show afterwards what it did.

The difference is reach. A law firm's agent can embarrass the law firm. An agent with an MSP's RMM access can take down every client at once, and the MSP will be asked to prove what it did by clients, auditors, insurers and, in the EU and soon the UK, a regulator. Tier structure and pricing change last, at Stage 5, once the controls have held at real clients.

Most MSPs are at the start. In Kaseya's 2026 survey, 53% said they already use AI to automate ticketing, patching and monitoring, but more than half had automated only about a quarter of their workload (vendor-run survey)[27].

An MSP will add agents around its PSA, RMM and documentation tool, not replace them. Each tool can govern its own agent, but none answers the cross-tool questions: which technician is this agent acting for, does that person have this access at this client, and where is the one record of it all.

OrchKernel is built to be that layer. Agents ask it before they act. It checks the call against rules, holds it for a named person when needed, runs it with credentials the agent never sees, and writes it to a tamper-evident log. What it is not: it is not a PSA, an RMM, a patch orchestrator or a security tool. The PSA stays the system of record for tickets, agreements and billing. The detail is in the OrchKernel blueprint.

An MSP takes "ongoing responsibility" for a client's IT under a service agreement, usually for a flat or near-fixed monthly fee[47]. Leading MSPs get about 75% of revenue from those agreements[42]. That makes the economics of AI unusually direct. Under hourly billing, saved time is lost revenue. Under a flat fee, every minute a technician does not spend on triage, notes, time entry or a repeat fix is margin.

Public numbers on MSP labor and margin are thin. These are the ones we could source:

We found no public median for SMB MSP margins. Service Leadership publishes medians and quartiles only to paying members, so this page does not quote a "typical" agreement margin.

Vendors publish plenty of numbers on where technician hours go. Thread says AI handles "50-100% of dispatch work"[35]. Kaseya says its triage removes "up to 80%" of categorization errors[28]. One ConnectWise customer reported 25% less average ticket time[32]. One Pia customer says a typical onboarding fell from about two hours to under ten minutes[36], and one Rewst customer recovered $120,000 through billing reconciliation[37]. A study Kaseya commissioned, based on eight MSPs, puts savings at $2,600 per technician per month[29]. All of these are vendor claims, none publishes a baseline, and nobody has published an independent figure for time lost to notes, alerts or billing leakage.

They still show where to look: dispatch, repeat tickets, thin notes, missing time, agreements that drift from what is deployed, and alert noise.

In Kaseya's 2026 survey, the share of MSPs whose typical client spends more than $25,000 a year fell from 75% to 41% in one year, 71% named winning new clients as their top challenge, and the share struggling to hire technicians rose from 9% to 16%[27]. A drop that steep in one year may reflect a change in who answered, so read it as direction, not size. MSPs are not growing their own tool spend fast either: N-able, which sells RMM and security tools to MSPs, reported dollar-based net revenue retention of 103% in 2025, so its existing customers spent about 3% more than a year earlier[25]. Smaller clients, harder hiring and slow growth in spend all push the same way: more clients per technician, without more risk per client.

Vendors are named because the sources name them, not as recommendations; capabilities are as each vendor describes them. The column that matters is the last one: what each vendor says about approvals and logs.

Platform vendors compete on autonomy; governance shows up mostly in smaller tools. The MSP signs the client agreement, so the gap is the MSP's to close.

The 53% adoption figure above comes from a survey run by a company that sells the tools, and "AI" there likely includes rules-based automation that existed before generative AI[27]. We could not reach an independent survey of MSP AI adoption.

The best independent evidence is not from MSPs. In a study of 5,179 customer support agents, an AI assistant raised issues resolved per hour by 14% on average and by 34% for novices, with little effect on the most experienced[26]. BLS already builds it into its projections: it expects jobs for computer support specialists to fall 3% over 2025 to 2035 and names chatbots for troubleshooting as a reason[22].

Into the platforms that hold the keys. Kaseya bought Datto for $6.2 billion in 2022[44], and Silver Lake and Thoma Bravo own about 59% of N-able[25]. Private equity has also rolled up MSPs themselves, buying at $3 to 10 million of EBITDA[42]. We found no verified AI-first MSP at scale, so for an established MSP the route is changing how its own desk works.

The rest of this playbook is built around this picture. On the left, an agent inherits the MSP's standing access, the way RMM scripting and platform automation are commonly wired. On the right, the same agent goes through a gate that limits each call to one client and to what one technician may do there.

With the gate in place a wrong filter, a prompt injection or a stolen agent token reaches one client and one technician's access, on record. The Five Eyes advice asks the same of people: least privilege, no admin credentials shared across customers, separated customer data[1].

Six stages, ordered by risk to client systems rather than by tool. Stages 0 to 2 never change a client system. Stage 3 is the first that does, and it does so only with a technician's approval. Different clients can sit at different stages: a dental clinic under HIPAA may stay at Stage 3 for patching long after a small marketing agency reaches Stage 4.

Stage 0 plus two Stage 1 workflows, then one narrow Stage 3 class with friendly clients. We suggest triage and resolution notes with time entries, because both go after flat-fee labor, neither touches a client system, and both produce numbers you can compare within the quarter.

At day 90, two questions matter more than how many tickets the AI touched. Are the agent's drafts good enough that technicians have stopped rewriting them? And can you show any client every agent action at their site in the last month?

An agent can prepare each of these: gather the evidence, draft the change, propose the answer. A named person makes the decision, and the log shows whose it was.

The sector's worst incidents so far came through automation channels and help desks. Agents with RMM and tenant access will use the same channels.

These are scenarios, not reported events. Each is something an agent with too much reach could do at an MSP, and each maps to one of the control points.

In the US, the regulated party is usually the client. Rules reach the MSP through the client's duty to oversee providers and through contracts. NIS2 names MSPs directly, and the UK is legislating to. None of these rules exempts an action because software took it.

Across the FTC, SEC, NYDFS, CMMC, NIS2 and the UK bill, four duties recur. An AI agent acting in client systems falls under all four:

A Stage 3 ticket from start to finish. The agent does the reading and typing, the technician makes the call, and the change reaches one client through a gate that records it.

OrchKernel sits between AI agents and the systems the MSP connects, as drawn in the blast radius. Agents ask it before they act; it checks the rules, holds what needs a person, runs what is allowed with sealed credentials, and records all of it.

Where an MSP needs a control whatever tools it runs, who owns it, and what enforces it.

OrchKernel is source-available under the Business Source License 1.1 and runs on your own servers, so you can read the code that enforces these controls. The license allows production use where each deployment serves one organization, and it allows separate deployments for separate client organizations. A hosted or managed service in which one deployment serves more than one organization needs a commercial license. The terms are on the license page.

One deployment per client is within the license. Whether one deployment for your own desk, with agents reaching many client tenants, fits the standard license is to be confirmed with us before you rely on it.

Record the baseline before Stage 1 and track the same numbers at each stage. For most MSP operating metrics there is no public benchmark: the detail sits in paid peer groups and vendor dashboards, and we have not quoted any figure we could not source.

Sources were read in October 2026; dates are publication or data dates. Last reviewed October 2026.