Most of the AI noise in boardrooms is still about better search. People talk about copilots, chat assistants and tools that make it easier to find or draft things. That is fine, but it is yesterday’s problem.
The real shift is happening where AI stops answering questions and starts doing work. Agentic systems are being wired into ticketing, identity, finance and operations, making decisions, calling tools and moving data inside live workflows. That is not “a smarter Google”. That is a new operator inside your estate.
Once you let AI act, the risk changes shape. The speed and autonomy that make agentic AI attractive are the same things that can turn a small mistake into a serious security, operational or data incident before anyone has time to react. That is why security agencies across the Five Eyes are now publishing joint guidance telling organisations to slow down and treat agentic AI as a high-risk technology unless strong controls are in place.
For a mid-market business, the question is no longer “should we use AI?” It is “who owns the risk when an AI agent can touch our systems, data and workflows – and are we sure our MSP has not moved faster than our governance?”
Why AI-Driven Workflows Change Your Risk Profile
The promise is obvious. Less manual work. Faster handling. More consistency. Better use of your internal team. I understand why that appeals.
The problem is that the strengths of agentic AI are tied to the same things that create risk. NCSC guidance on adopting agentic AI points to broader access to systems and data, behaviour that is harder to predict, actions that can be harder to spot and systems that are more difficult to explain afterwards. That should get any sensible leadership team’s attention.
For a mid-market firm, the likely failure is not a headline-grabbing catastrophe. It is something smaller and more irritating that still costs real money. An agent closes a batch of tickets on the wrong logic. An onboarding workflow grants access more widely than intended. A data-moving process copies personal information into a platform that was never meant to hold it.
That is why most of the advice in this area misses the point. People talk about whether the model is smart enough. I care more about whether the controls are tight enough.
The ICO guidance brings the discussion back to earth. If personal data is involved, your responsibilities around accountability, governance, lawfulness and fairness do not vanish because a supplier built or ran the workflow. The business using the system is still responsible for understanding what it does and putting proper safeguards around it.
From Assistant to Autonomous Workflows: What Just Changed in Your Estate
The easiest mistake here is to treat agentic AI like better automation. GOV.UK describes agentic workflow as a model where AI agents interpret goals, break work into steps, use tools and adapt based on feedback rather than following one fixed script. That matters because an agent has more room to decide how to get to the outcome, which is exactly why weak governance becomes expensive quickly.
In practice, your MSP might propose an agent that triages support tickets, resets credentials, updates records in another system, pushes a script or closes a request without an engineer touching every step. Plenty of mid-market firms will hear that and think efficiency. My first thought is permissions. My second is accountability.
You would not give a new engineer broad access to live systems without rules, logging and supervision. I would not do it with an AI agent either.
Who Owns the Automation Risk: You or Your MSP?
Both sides carry risk, but the accountability should not be fuzzy. Your business remains responsible for how AI is used inside its operations, especially where decisions, access and personal data are involved. Your MSP should be responsible for designing and operating the service inside clear boundaries that you have agreed.
Too many businesses buy automation as if they are outsourcing judgment. They are not. If an MSP deploys an agent into your estate and nobody on your side can explain what it can access, what approvals exist, what logs are kept and where a human still signs off, your governance has already failed.
I would split ownership into three layers. Senior leadership owns the business risk and should know where autonomous systems sit inside the risk register and outsourcing model. Process owners own the business logic and should define what the agent can do, what it must escalate and what stays off limits. The MSP owns the quality of the design, which means strong views on least privilege, auditability, rollback and where not to automate yet.
Rules of Engagement for AI in an MSP-Managed Estate
Before any agent goes near production, I would want written rules of engagement. Not a deck. Not a promise. Something you can point to later.
Start with scope. NCSC guidance recommends starting small and using low-risk tasks with established security controls from the outset. In plain English, that means narrow, reversible tasks with clear success criteria – not broad autonomy because the workflow looks impressive in a demo.
Then set three boundaries. First, system boundary – exactly which systems the agent can read, write or trigger actions in. Second, decision boundary – which actions it can automate, which stay recommendation-only and which always need human approval. Third, failure boundary – what happens when source data is wrong, systems disagree or confidence is low. GOV.UK is clear that unintended behaviour is part of the design challenge with agentic workflow, which is why testing, guardrails and regular review matter so much.
For most mid-market firms, there should already be obvious red zones unless extra controls exist – payroll, finance, HR case data, privileged identity changes, regulatory submissions and anything else that can create irreversible impact.
What to Demand From Your MSP Before Automating Core Workflows
A decent MSP should be comfortable with direct questions here.
Ask for the architecture in plain English. Where does the agent run. Which systems does it call. How are credentials handled. What is the fallback when the workflow fails. If the answer sounds like product language rather than operational reality, keep pushing.
Ask about identity and permissions next. Agents should have their own identities, their own access profiles and narrow roles. If the model relies on shared service accounts or broad administrative rights because “it is easier that way”, the design is telling you more than the proposal is.
Ask about logging and failure handling. You should be able to reconstruct what the agent did, why it did it, what data it used and which changes it made. You should also know who gets alerted, how fast the workflow can be stopped and what the rollback path is if something goes wrong.
Why AI Security Controls Matter More Than the Demo
This is the bit I care about most. Before you get into contracts, product choices or vendor promises, ask whether the security controls are strong enough to justify autonomous action in the first place.
The baseline is not exotic:
- Least privilege for every agent identity.
- Separation between recommendation, approval and execution for high-impact workflows.
- Strong logging and attribution for every material action.
- Change control for prompts, policies, connectors and model updates.
- Testing against failure conditions, not just the neat path in the demo.
- A kill switch and a clear escalation route.
Most failures in this area will come from ordinary weaknesses – bad permissions, poor monitoring, thin review and muddled ownership – not from science-fiction scenarios.
Where Your MSP Contract Still Matters for AI Governance
Security controls come first, but the contract still needs to catch up with reality. Legal commentary on agentic AI is starting to make this point clearly – many agreements were written for human-delivered services and ordinary software, not for semi-autonomous systems making or triggering decisions inside live operations.
At a minimum, your MSP agreement should make six things clear:
- Whether agentic systems are being used at all in service delivery.
- Which parts of the service involve autonomous execution and which do not.
- What approval model applies to higher-risk actions.
- What logging, incident response and notification obligations exist.
- How changes to the workflow, model or connectors are governed.
- What happens if an agent contributes to outage, data loss, unauthorised access or compliance failure.
Lazy ambiguity is dangerous. If the supplier says the AI is just part of the tooling, that is exactly when I want to know what rights that tooling has and where liability lands when it goes wrong.
Where to Say No – and What to Ask Next
There is nothing old-fashioned about drawing red lines. It is good management.
For most 200 to 2,000 user firms, I would be very cautious about allowing unreviewed privileged access changes, unrestricted movement of sensitive personal data between systems, financial adjustments, changes to regulated records or high-impact HR decisions without a human in the loop. That is not anti-automation. It is what sensible sequencing looks like, and it lines up with current NCSC guidance to start with low-risk tasks and apply security controls from the start.
If your MSP is already talking about AI agents, do not start by asking what the platform can do. Ask which workflows they want to automate first, what permissions the agents would actually hold, which actions are blocked without human approval, how you would know if one made a bad decision and what changes in the service agreement once autonomous execution enters the picture.
If those answers are clear, written down and technically credible, you may have the basis for a sensible pilot. If they are vague, over-reassuring or full of platform language, stop there.
My view is straightforward. If your MSP is wiring AI into your workflows, but nobody is accountable for what those agents can touch, you do not have automation. You have unmanaged risk.
FAQs
- How is agentic AI in my MSP different from the AI copilots my team uses?
Copilots mostly help people search, summarise or draft, while agentic AI in an MSP actually runs parts of your IT workflows. Once an MSP agent can change tickets, permissions or data, you are dealing with an AI operator inside your estate, not just a smarter search box. - Who owns the risk if an MSP-run agentic AI workflow breaks something?
Your business still owns the automation risk and data risk, because it is your operation, your systems and your customers. The MSP should own design and day-to-day running of those AI workflows inside clear rules; if those rules are vague, neither side has real accountability. - What should we ask our MSP to show before we let agentic AI automate core workflows?
Ask them to map where the AI agents run, which systems they touch, what permissions they have, how actions are logged, and how they roll back failures. If your MSP cannot answer those AI governance basics clearly, they are not ready to run autonomous workflows in your production estate. - Where should a 200–2,000 user firm draw hard lines on AI automation with an MSP?
Treat privileged access changes, sensitive personal data, financial postings, regulated records and major HR decisions as high-risk and keep a human in the loop for those AI-driven workflows. Start with narrow, low-risk automation that is easy to reverse so you can learn safely before expanding the agentic AI scope. - If we already trust our MSP, do we still need separate AI governance for agentic AI?
Yes. Trust in the MSP does not replace your legal and operational responsibilities for AI and data. You still need documented scope, decision rules, security controls and contract language around agentic AI workflows, or you are relying on goodwill instead of governance.
You must be logged in to post a comment.