The AI Seat: An MSP's Guide to MCP and the Next Managed Service Line

There is a new advisory seat opening at every small business’s table right now. Call it the AI seat. Within a couple of years it will be filled, at every client you serve, by whoever can safely connect AI to that business’s data and people. The work of filling it is identity, permissions, vendor vetting, auditing, and knowing the client’s users and their risk profile well enough to say no to the right things.

Read that list again. That job is MSP-shaped. It has always been MSP-shaped. The only question is whether MSPs will be the ones sitting in the seat, or the ones doing the operational work for whoever got there first.

I want to make the case for taking it, and I want to make it to the most skeptical owner in the room, because the skeptics are usually the ones who remember the last time this happened.

You have seen this movie

Most MSP owners who were around in the early 2000s carry a specific kind of scar tissue about new categories. It comes from the era when security software was, in meaningful part, a scam.

The managed security category didn’t start inside MSPs. It emerged in the late 1990s from ISPs offering firewall management, adjacent to the MSP business rather than part of it. And then, from roughly 2003 to 2014, came the scareware era. Vendors manufactured the problem and sold the cure. Researchers documented more than 250 variants of rogue antivirus software. One affiliate network pushing a product called Antivirus XP 2008 grossed around 150 thousand dollars in ten days. The FTC won a restraining order against the operators behind WinFixer and XP Antivirus in December 2008. The FBI’s IC3 issued a public warning in 2009 estimating around 150 million dollars in consumer losses. Some rogue products literally instructed users to disable their firewall to complete registration. Kaspersky detected roughly three thousand rogue antivirus samples in the first half of 2008 and more than twenty thousand a year later.

So when an MSP owner from that era tells you they learned to distrust security vendors, understand what they’re actually telling you: their skepticism was statistically correct. Half the category was fraud. Cutting through vendor noise became part of the job, because clients can’t tell marketing from reality and they look to their MSP to answer the question “what should we really do.”

Then the skepticism expired, and almost nobody noticed the exact moment. CryptoLocker in 2013. WannaCry and NotPetya in 2017. The Kaseya attack in 2021, where MSPs themselves were the target. Every wave converted skeptics the same way: firsthand contact. A client got hit. A peer got hit. Never marketing.

Here is where that arc ended up. Industry analyses today put managed security at roughly 31 percent of the MSP service mix, the largest single segment, growing around 18 percent a year against roughly 14 percent for the overall MSP market. The managed security services market sits somewhere around 39 to 43 billion dollars and is projected to reach 67 to 77 billion by the early 2030s. Nearly all MSPs, 96 percent plus in recent surveys, now market security services. The stack matured from antivirus to EDR to MDR, from firewalls to zero trust, from log files to SIEM to SOC-as-a-service.

The whole arc in one sentence: the thing MSPs were rightly skeptical of, because half of it was literally fraud, became the single largest and most profitable thing they sell within fifteen years, and the only ones who lost were the ones who stayed skeptical long enough for someone else to take the seat.

AI is in the scareware period of its arc right now. There are more thin ChatGPT wrappers today than there were fake antivirus products then. Early models hallucinated enough to hand every skeptic a story. If you’ve been discounting the category, you’ve mostly been right. But the skepticism expires this time too, and there is one difference that matters: pace. Security gave you a decade to move from skeptic to provider. This wave gives you quarters.

What the MSSP era should have taught you

There is a second lesson buried in the security arc, and it’s the more expensive one.

When clients first started asking about security, most MSPs hesitated. “We’re not security experts” was true, and it felt like the responsible answer. The clients didn’t stop asking. They asked whoever would answer, and that gap is where the MSSP was born.

Here is what sharing a client with an MSSP actually looks like from the MSP side. The number one issue in security is compliance, and compliance is operational. Who makes sure every new laptop gets EDR before it ships? The one building the laptop. Who makes sure every account has MFA? The one creating the accounts. That’s the MSP. The last mile is the hard part, and MSSPs don’t do it. So the MSSP sells the high-margin layer with almost no labor attached, and the MSP carries the operational work that makes the whole thing function. Lose-lose.

To be fair to the MSSPs: they built benches of genuine specialists that most MSPs couldn’t, and large enterprises really do need that sophistication. Most SMBs never did. For the SMB, the MSP could have owned the entire stack. The ones who did own that revenue today.

The same structure is assembling itself around AI, with one substitution. The AI consultant is this wave’s MSSP. I don’t mean they’re frauds. Most of them know the technology well. What they are is structurally disadvantaged: they know the technology and nothing about the client. They run the strategy workshop, deliver the deck, and leave. Then someone has to actually connect the data, scope the permissions, vet the servers, and support the users, and that someone is the MSP either way. The only question is whether you own the engagement or do the last mile of someone else’s.

Be your own first client

At the MSP where I started, our security practice didn’t begin as a product. It began as nerves.

We were worried about specific risks in our own shop, so we fixed them before any client heard a word about a security offering. We didn’t really have a choice. An MSP holds god access to every client environment it manages. Being the most secure company in our own book of business wasn’t a differentiator, it was the baseline obligation of holding the keys.

Then came the surprise that shaped everything after. We expected security work to slow us down. The opposite happened. Once we knew we weren’t exposed, we moved faster, because our hesitation had been the quiet knowledge that we were open somewhere. De-risking didn’t cost speed. It refunded it.

And it changed how we sold, permanently. We never pitched security again. We gave trip reports: here is what we did in our own shop, here is the risk that made us nervous, here is what it cost, here is what changed. We kept one rule, that we would always be more secure than our most secure client, because the guide has to be ahead of the group. The result was a step path. We could place any client at their current position on the road we had already walked and justify each next step with a straight face, because we had made the same call with our own money.

That method transfers to AI directly, with one upgrade. For security, leading was an obligation. For AI, leading is an advantage, and the advantage is structural. An MSP is a collective mind: dozens of technicians across hundreds of environments, swimming in machine logs, alerts, tickets, and events. That is exactly the work modern AI is built for. Your client has one business to apply AI to. You have all of theirs, plus your own. I’ll say the quiet part plainly: nobody on earth benefits more from AI than an MSP.

There’s a bonus that doesn’t show up on the P&L at first. Deploying AI internally teaches every employee its sharp edges: where it’s brilliant, where it lies, where it needs a leash. That staff-wide fluency becomes part of what your clients are buying. When a technician tells a client “we don’t let it do that unattended, and here’s why,” that sentence was paid for by internal use.

So the method is the same as it was twenty years ago. Fix your own shop first. Keep receipts. Sell the trip report. The rest of this guide is the vocabulary you need to walk the path.

The literacy: four concepts that are less new than they look

Everything an MSP needs to understand about connecting AI to a business reduces to four concepts. Each one has a name in the AI world and an older name in yours.

MCP is the name of the answer

When a client asks “should we be using AI,” the real question underneath is “how does this thing reach our data safely.” The answer to that question has a name: MCP, the Model Context Protocol.

MCP is the open standard for how AI applications connect to tools and data. It was donated to the Linux Foundation in December 2025 and has been adopted by every major AI vendor, which means it’s nobody’s proprietary moat. Before MCP, every connection between an AI application and a business tool was a custom integration. Ten AI applications talking to a hundred tools meant up to a thousand separate integrations, each one built, maintained, and broken on its own schedule. MCP collapses that to one protocol on each side.

You have lived this problem. Every MSP has a duct-taped integration project in its past, a PSA that wouldn’t talk to the RMM, a documentation platform synced by a scheduled script someone wrote in 2019 and nobody wants to touch. You know exactly what an N-times-M integration mess costs because you’ve paid for one. That’s why the before-and-after of MCP lands harder for MSPs than for any other audience: it’s the standard that ends integration hell for AI, and it’s the technical center of the AI seat.

If you fix one piece of vocabulary this year, make it this. The word to be fluent in for clients is MCP. Not “workflow,” not “automation.” MCP is where the data access, the permissions, and the risk all live. (For a concrete look at what MCP servers exist for MSP tooling today, we keep a running survey at MCP servers for MSPs.)

A tool is a job description

Inside MCP, an AI is given “tools.” A tool is a described capability: a name, a description of what it does, and the parameters it accepts. The model reads those descriptions and chooses which tool to use for the task in front of it.

The description is where quality lives, and it’s where danger lives, because the model does what the description says and it follows instructions literally. The most useful mental model I can offer: a tool definition is a job description handed to the world’s most literal new hire. Write it precisely and the work is precise. Leave it vague and you’ll get vague work performed confidently.

Two failure modes follow directly from this, and both are worth knowing by name. The first is the poisoned description: a malicious MCP server hides instructions inside its tool metadata, and the model, which reads that metadata as faithfully as it reads everything else, follows them. The second is the rug pull: a server behaves honestly during evaluation, gets its permissions granted, and then silently changes its tool definitions afterward. Most organizations have no detection in place for that change.

Neither of these is exotic. They’re supply chain problems wearing new clothes, and the takeaway is operational, not technical: the details of tool definitions matter, and someone technical has to own them, review them, and notice when they change.

Skills are runbooks

Here’s the concept that should make an MSP owner sit up, because it’s the point in the curriculum where the learning curve bends in your favor.

AI models don’t retain anything between sessions. Whatever expertise you want an AI system to apply consistently has to be externalized: written down, versioned, reusable, followed exactly, improved when it fails. The AI world calls these skills, or instructions, or saved setups depending on the vendor.

You have been writing these for twenty years. Your industry calls them runbooks.

The discipline of externalizing knowledge so that any competent operator can execute a procedure without the original expert in the room is not a new skill MSPs need to acquire. It’s a skill MSPs invented out of necessity, because technicians leave, clients scale, and 3 a.m. incidents don’t wait for the one person who remembers. A skills library for an AI system is a runbook library with a new reader. The reader happens to be tireless and literal, which raises the bar on precision, but the craft is the same craft.

I’ve watched this realization land with owners. They walk in asking “can my team learn this” and walk out saying “we’re weirdly prepared for this.” You are. That’s not a pep talk, it’s an inventory observation.

Permissions are the wall, and you’ve built walls before

The operating rule for connecting AI to real business systems is simple to state: start read-only, scope narrow, expand only when a task requires it, and require human approval for anything destructive or irreversible.

That’s least privilege. It is not a new discipline. It’s the discipline you already apply every time you set up a new technician, scope a service account, or run a client access review. The security industry’s consensus on AI-connected systems is that scope and identity are the single highest-value control available, the narrowest permissions the task allows. (We’ve written before about what that architecture looks like in practice, if you want the implementation-level view.)

I want to state the theme of this whole section explicitly, because it’s the thing the AI consultant cannot say and you can. Identity, permissions, vetting, auditing: this is your job. It always was. The surface is new. The job is not.

Why this can’t be a one-time project

Everything to this point could, in principle, be delivered as a project. Assess, connect, configure, hand over, invoice. Here is why that shape fails, and why the failure is the business opportunity.

The threat model in plain language

The dangerous configuration for any AI agent is the combination of three things: access to private data, exposure to untrusted content, and a way to communicate outward. An agent with all three can be turned against the business by a single injected instruction hidden inside normal work content. A PDF it was asked to summarize. An email it was asked to route. The instruction doesn’t arrive through a vulnerability. It arrives through the front door, as content, and the model treats it as faithfully as it treats everything else it reads.

You cannot patch this away, because it isn’t a bug. It’s a property of systems that read text and act on it. You manage it the way you manage every unfixable risk class: architecture, scoping, monitoring, and a human gate in front of anything irreversible.

Shadow MCP is already in your clients’ walls

Meanwhile, the people you support are not waiting for governance. Employees are installing unvetted MCP servers from public repositories today, connecting them to work accounts, and telling no one. This is shadow IT with a twist: an MCP server is a supply chain surface whose tool definitions can change after installation. The rug pull from the literacy section isn’t hypothetical, it’s a standing property of every unvetted server already running.

The institutions that write security guidance have noticed. The NSA and partner agencies published joint guidance on MCP security in May 2026. OWASP published its Agentic Top 10 in December 2025. When the NSA writes guidance about a protocol, understanding that protocol has stopped being optional for the people who manage business systems.

And the ground keeps moving. The largest revision of the MCP specification since its launch lands July 28, 2026. Specs move. Servers update. Definitions change. Someone has to patch, monitor, and re-vet, on a schedule, forever. That sentence should sound familiar. It’s the shape of every service you already sell.

Compliance is where advisory becomes a managed service

If you want proof that AI advisory has technical, constantly shifting, genuinely hard answers, look at the compliance layer. Take healthcare, since most MSPs touch it somewhere in the book.

As of 2026, the BAA situation for AI tools is a minefield of specifics. Consumer and self-serve AI plans generally do not come with a BAA at all. Enterprise tiers and the cloud-platform paths, Azure and Microsoft 365, AWS Bedrock, can carry BAAs. But coverage has feature-level exclusions, and some vendors exclude specific capabilities, MCP connectors among them, from the covered set. The coverage pages change frequently enough that an answer from March may be wrong by July. And while the paperwork shifts, surveys suggest around one in six healthcare workers admits to using unapproved AI tools at work.

The AI consultant with the strategy deck does not know any of this, and doesn’t have to, because they’re gone before it matters. An MSP serving three dental practices has to know it, has to keep knowing it as it changes, and is already legally inside this world as a business associate. Compliance is where AI advisory stops being opinions and becomes a managed service.

One warning while we’re here, about a line you will be tempted to use in a sales conversation: “we’ve been doing AI for years, they just didn’t call it that.” Don’t. Every owner who says it discredits themselves with the one buyer who matters, the one who knows the difference. You don’t need to inflate your history. Your actual position is stronger than the inflated one.

The offer, concretely

Put the pieces on the table and the service line assembles itself.

Up front, an assessment and connection project: walk the client’s step path the way you once walked your own security path, unlock the data safely over MCP, vet the servers, write the tool scopes, set the approval gates. Then, recurring: monitor tool definitions for changes, audit access quarterly the way you already audit access, re-vet and patch when the spec or the servers move, keep the compliance answers current, and train the users, because the humans are half the system.

Project plus maintenance. It’s the exact shape the SMB needs, and it’s the exact shape an MSP already knows how to sell, staff, and bill. That’s not a coincidence. Ongoing risk is what makes a managed service, and this category generates ongoing risk natively.

The seat is open

One more difference between this wave and the last one, and it’s the reason to move with some genuine excitement rather than dread.

Security proved itself through pain. The skeptic converted the day they watched an attack succeed, at a client or a peer or their own shop. It was a defensive sale from the first day to this one: pay to prevent the bad thing.

AI proves itself through capability. The skeptic converts the day they watch it do something they can’t explain away, a triage decision that took seconds instead of twenty minutes, a client question answered from data nobody had time to assemble. It’s the first service line in this industry’s history that clients actually want to hear about, an offensive sale: capability, speed, answerable data. A better product to sell was always going to win. This time you get to be early with it.

Fifteen years ago, an industry of justified skeptics built endpoint, firewalls, zero trust, and SIEM into the largest business MSPs have, out of a category that started as half fraud. The AI seat is the same opportunity earlier in the curve, with a better product: not protection from the bad, access to the good.

And underneath the business case, there’s a plainer fact I try not to lose sight of. The same technology touching drug discovery and spaceflight is sitting in your client’s ticket queue and file share, waiting for someone they trust to connect it. Someone is going to be that trusted party for every SMB on your list. The job requirements are identity, permissions, vetting, auditing, and knowing the client. You’ve been in training for twenty years.

Be your own first client. Start read-only. Keep receipts. Take the seat.

---

Junto builds in this space: operational intelligence for MSPs, including a public MCP server, built on the same read-first, least-privilege principles this guide describes. If you’re walking this path and want to compare notes, we’re easy to find.