Managing Agentic AI Is Now a Reportable Risk: What the UK Cyber Bill Means for Service Providers

On 12 October 2026, the government did something most of us had been expecting but still weren't ready for. In a statement tied to the progress of the Cyber Security and Resilience Bill, it confirmed two things that land squarely on managed service providers. First, MSPs are explicitly named as in-scope for the Bill's widened incident-reporting obligations. Second, incidents involving agentic AI — systems that act on their own, take decisions, and chain tasks together without a human pressing the button each time — now count as a trigger for reporting.

If you run or rely on an MSP, that second point is the one to sit up for. We've spent two years talking about AI agents as a productivity story. The government has just reframed them as a reportable risk.

What actually changed

The Cyber Security and Resilience Bill has been working its way through Parliament, and much of its early coverage focused on critical national infrastructure — energy, water, transport, the NHS. The scope has steadily broadened. The October statement makes the MSP inclusion unambiguous: if you provide managed IT, security, or digital services to other organisations, you are a link in a supply chain the government now wants visibility over.

The mechanism is incident reporting. When a significant incident hits, in-scope organisations must notify the relevant authority — in most cases the NCSC acting as the technical lead, with the sector regulator or ICO involved depending on the service. The timings matter: an initial notification within 24 hours of becoming aware, followed by a fuller report within 72 hours. Anyone who has worked under GDPR will recognise the 72-hour clock, but the 24-hour early-warning step is tighter and less forgiving.

What's new in the October framing is the explicit addition of agentic AI incidents to the list of conditions that can start that clock. Previously, you'd report because of ransomware, a data breach, a denial-of-service attack, a supply-chain compromise. Now add: an AI agent that took an action it shouldn't have, accessed data it wasn't authorised to touch, or caused disruption through automated decisions — whether or not a human or an attacker was directly involved.

Why agentic AI is a different kind of problem

Traditional incidents have a reasonably clear story. Someone clicked a link, credentials leaked, an attacker moved laterally, data left the building. You can reconstruct it.

Agentic systems break that neat narrative. Picture an AI agent given access to a client's ticketing system, their email, and their finance platform, with a brief to "resolve overdue invoices." It drafts chasers, escalates, and — because someone gave it broad permissions to save time — it starts issuing refunds it misread as corrections. No malware. No attacker. Just a system acting within its granted authority, doing the wrong thing at speed and at scale.

Under the old mental model, you might not have called that a cyber incident at all. Under the new framing, if that agent touched regulated data or disrupted a service, you may be looking at a reportable event with a 24-hour clock already running.

That's the shift MSPs need to absorb. The trigger is no longer only "were we attacked?" It's also "did an autonomous system do something it shouldn't have, and did it matter?"

The runbook gap

Here's the uncomfortable part. Most MSP incident-response runbooks were written for breaches and outages. They assume a security event with a human adversary and a forensic trail. Very few currently include:

• A clear definition of what counts as an agentic AI incident, written so an on-call engineer at 2am can make the call quickly.
• An inventory of where AI agents actually operate across your estate and your clients' estates, and what permissions each one holds.
• A decision tree for whether a given agent misfire crosses the reporting threshold.
• A 24-hour notification workflow with named owners, contact routes to the NCSC and relevant regulators, and templates ready to go.
• Logging detailed enough to reconstruct what an agent did, when, and on whose instruction.

That last point is where a lot of providers will struggle. If you can't show the chain of actions an agent took, you can't report accurately within 72 hours, and you can't defend your position afterwards. Agent observability — proper logs of prompts, decisions, tool calls, and data accessed — is now a compliance requirement, not a nice-to-have for the engineering team.

What to do before Report Stage

The Bill isn't finished its passage, which is precisely why this is the moment to act. Report Stage is when amendments get hammered out and the detail firms up. Waiting for Royal Assent to start building your process is leaving it far too late, because the obligations will bite on a defined date and your clients will expect you to be ready on day one.

A sensible order of work:

Map your agents. Build a register of every agentic AI system you run or manage, internal and client-facing. Record what each can access, what actions it can take autonomously, and who owns it. You cannot report on incidents involving things you haven't catalogued.

Tighten permissions now. The invoice-refund scenario happens because agents are given broad scopes to make them useful. Apply least privilege to agents the same way you would to human accounts. Narrow the blast radius before you're reporting on an explosion.

Rewrite the runbook. Add agentic AI as an explicit incident category. Give your team concrete examples so the threshold question is answerable fast. Bake in the 24- and 72-hour timings with named responsible people and out-of-hours cover.

Fix your logging. Make sure every agent produces a reconstructable audit trail. Test whether you could actually describe an agent's actions within the reporting window. If you can't, that's your first project.

Talk to your clients. Your contracts and shared-responsibility agreements probably don't mention agentic AI. They need to. Clarify who reports what, and make sure clients understand that AI tools they've deployed could pull you both into scope.

Run a tabletop. Walk through a simulated agent incident end to end — detection, assessment, notification, follow-up. You'll find the gaps on a Tuesday afternoon rather than during a real one.

The practical takeaway

The government has given MSPs something unusually clear: a dated statement, a named scope, a specific new trigger, and a notification clock measured in hours. That combination doesn't come along often in regulation, and it removes any excuse for vagueness.

The providers who treat this as a documentation chore will scramble when their first agent misbehaves. The ones who treat it as a prompt to actually understand where autonomous systems sit in their estate — and to build the muscle to detect, assess, and report fast — will come out ahead, both with the regulator and with clients who increasingly ask hard questions before they sign.

Agentic AI was always going to need governance. The Cyber Security and Resilience Bill has just put a date and a deadline on it.