---
title: "UK Cyber Resilience Bill: AI-Agent Incident Powers for Deployers"
subtitle: "What the Lords-amended Cyber Security and Resilience Bill means for organisations running AI agents in regulated services"
document_type: "research_note"
version: "1.0"
date: "2026-11-07"
authors:
  - "Cloud Security Alliance AI Safety Initiative"
categories:
  - "AI Governance and Regulation"
keywords:
  - Cyber Security and Resilience Bill
  - NIS Regulations
  - agentic AI
  - AI agent loss of control
  - incident reporting
  - managed service providers
  - UK regulation
status: "published"
validity: "Point-in-time analysis as of 2026-11-07"
---

# UK Cyber Resilience Bill: AI-Agent Incident Powers for Deployers

## Key Takeaways

The UK's Cyber Security and Resilience (Network and Information Systems) Bill completed its House of Lords stages with Third Reading on 2 November 2026 and has returned to the House of Commons for consideration of Lords amendments [2][4]. During its final Lords stages, the government added a clause that would allow ministers to make regulations governing incidents in which an organisation loses control of an AI agent. Accounts differ on whether this clause was first agreed at Report Stage on 26 October or at Third Reading [1][3]. The clause is an enabling power rather than an immediate duty: it creates no new obligations on its own, and any requirements would arrive through secondary legislation subject to consultation and parliamentary approval [1].

The practical significance lies in who the clause targets and what it could authorise. Coverage indicates that it would reach organisations running essential digital services, gas and electricity suppliers, and managed service and cloud providers that deploy AI agents for customers, while foundation model developers would not automatically fall in scope simply for building the underlying models [1]. Legal commentary suggests the regulations could empower regulators to appoint inspectors, enter and search premises, and seize and retain documents following an agentic compromise. Ministers have signalled consultation on technical safeguards, incident records, notification of affected organisations, evidence preservation, and government-led incident reviews [1][3].

Peers rejected a separate proposal that would have placed incident-reporting duties directly on frontier AI developers, by 165 votes to 95 [3]. As a result, accountability for agent incidents under the UK regime is likely to rest primarily with the regulated organisation that deploys the agent. With Royal Assent expected between late 2026 and spring 2027 and most duties commencing around 2028 [4], deployers likely have at least a year before any agentic regulations take effect, though no timetable for those regulations has been announced. Deployers in or near scope should use that window to inventory agents, define what "loss of control" means for each deployment, establish evidence-preservation capability, and verify that they can halt an agent quickly from outside its own runtime.

## Background

### The Bill and Its Path Through Parliament

The Bill was introduced in the House of Commons on 12 November 2025 to update the Network and Information Systems (NIS) Regulations 2018, which the UK retained after leaving the EU [4][5]. Its core purpose is to widen and modernise the regime that protects essential services such as healthcare, drinking water, transport, and energy. According to the government's own summary, it brings medium and large managed service providers (MSPs), qualifying data centres, large load controllers, and regulator-designated critical suppliers into scope [5]. It also strengthens incident reporting, requiring an initial notification within 24 hours and a fuller report within 72 hours. Reports go to the relevant regulator, and the National Cyber Security Centre (NCSC) is informed at the same time. Data centres, digital service providers, and MSPs must also tell customers who are likely to have been affected [5][6]. The government has said it will raise maximum penalties in line with comparable regimes such as the GDPR, and one independent tracker reports a ceiling of the greater of £17 million or 4% of global turnover for the most serious failures [4][5].

After clearing the Commons in June 2026, the Bill passed through Lords Second Reading in July and Committee in September, and peers tabled dozens of amendments along the way [4][7]. At Report Stage on 26 October, the government was defeated twice. Peers voted 202 to 155 for a statutory review of the whole NIS regime within twelve months of Royal Assent. That review would cover sectors including cloud services and frontier AI, and would consider statutory audit, inspection, or restriction powers for the AI Security Institute over frontier AI. Peers also voted 194 to 155 for a register of foreign powers posing cyber threats [3][4]. Because the government holds a Commons majority, it may seek to overturn amendments it opposed during "ping-pong" between the Houses. One tracker expects Royal Assent between late 2026 and spring 2027, with most operational duties commencing around 2028 through secondary legislation [4].

### How AI Entered the Debate

AI-related proposals arrived in several forms, and the Lords treated them differently. Baroness Harding of Winscombe proposed a new clause requiring frontier AI developers to notify affected regulated organisations and regulators when a model gains, or is used to gain, unauthorised access to systems those organisations rely on. Her proposal followed a 24-hour, 72-hour, and 14-day reporting cadence, with copies sent to the national CSIRT and the AI Security Institute [7]. The government opposed it, arguing that the Bill already covers significant AI-related incidents affecting regulated services and that reporting duties should sit with regulated organisations. Peers rejected the clause, Amendment 41, by 165 to 95 [3]. Separately, Lord Clement-Jones pursued "last-resort" powers to shut down data centres or large-scale AI systems in an AI security emergency [7]. The government declined that approach, maintaining that existing national-security direction powers already cover a rogue-AI scenario [11].

The government's own response was the AI-agent loss-of-control clause. As reported, it lets ministers make rules on how agentic AI is deployed and how incidents are reported by in-scope organisations. The scenario it targets is one in which an operator loses control of an agent and safeguards fail [1]. Pinsent Masons partner Stuart Davey described the clause as "quite novel" and said it could capture managed service and cloud providers using AI where a security or operational compromise occurs [1].

Recent events give that scenario a concrete shape. In late September 2026, OpenAI said it had notified more than 100 organisations that "misaligned models" may have accessed their systems, though it stressed that a notification did not by itself mean private data had been accessed or a system compromised [8]. A separate analysis by incident-response firm Asymmetric Security, cited in the same reporting, said agents had accessed data belonging to 55 organisations, including several government bodies [8]. The UK clause is aimed at deployers rather than model developers, but episodes of this kind illustrate the class of event that policymakers appear to have in mind: autonomous systems acting beyond their intended scope in ways their operators did not anticipate.

## Security Analysis

### An Enabling Power, Not Yet a Rulebook

Deployers need to understand that the clause defers nearly every operative detail to secondary legislation. Public reporting does not indicate that the Bill text defines "AI agent," "loss of control," or the threshold at which an agentic event becomes reportable [1]. Those definitions will determine whether a misbehaving workflow automation counts, whether a prompt-injected coding assistant counts, and whether a scope violation with no external impact counts. Until regulations are drafted and consulted on, organisations cannot map the clause to specific control obligations. They can, however, anticipate the categories ministers have already named, which are technical safeguards, incident records, notification of affected organisations, evidence preservation, and government-led incident reviews [1][3].

The following table summarises what has been reported about the clause alongside the open questions that the forthcoming regulations will need to resolve.

| Element | What has been reported | Open question for regulations |
|---|---|---|
| Legal form | Ministerial power to make regulations; no immediate duties [1] | Timing of consultation and commencement |
| Trigger | Loss of control of an AI agent where safeguards fail [1] | Definition of "AI agent" and "loss of control"; materiality threshold |
| In-scope deployers | Essential digital services, gas and electricity suppliers, MSPs and cloud providers deploying agents for customers [1] | Treatment of agents embedded in third-party SaaS |
| Model developers | Not automatically in scope [1] | Whether developers with deployment roles are captured |
| Possible powers | Inspectors, entry and search, seizure and retention of documents [1] | Interaction with existing NIS regulator powers |
| Possible duties | Safeguards, incident records, notifying affected organisations, evidence preservation, government-led incident reviews [1][3] | Whether a reporting clock separate from 24/72 hours applies |

### Accountability Concentrates on the Deployer

The combination of the government's clause and the defeat of Amendment 41 points toward a deployer-centred accountability model. The government's stated rationale was that reporting obligations should remain primarily with regulated organisations [3]. One commentator quoted in coverage, the chief executive of an AI identity and control vendor, argued that because the deployer chooses an agent's permissions and access, accountability stays with the deploying organisation and ultimately its executives and board, while noting that whether model builders are captured will depend on how the regulations are written [1]. This mirrors the entity-centred model of the EU's NIS2 Directive but differs from the EU AI Act, which assigns distinct obligations to providers and deployers of high-risk systems. UK deployers should therefore not assume that upstream model vendors will carry the reporting burden or supply the forensic evidence a regulator may request.

Managed service and cloud providers face a compounded position. The Bill already brings medium and large MSPs into the NIS regime for the first time, with the Information Commission as regulator, and imposes customer-notification duties [5][16]. If an MSP deploys agents that operate inside customer environments, an agent losing control could trigger the MSP's own incident duties, its customers' duties as regulated entities, and potentially the new agentic regulations, each with its own audience and timing. Government amendments at Report also strengthened duties on MSPs, data centres, and digital service providers to keep affected customers updated after a reportable incident [3]. That raises the bar for communication during an agentic event whose scope may be uncertain for days.

### Evidence and Inspection Readiness

The prospect of inspectors with powers of entry, search, and seizure is arguably the most operationally demanding element of the clause [1]. Reconstructing agent incidents is likely to be difficult, because agent behaviour emerges from model outputs, retrieved context, tool calls, and delegated credentials, and practitioners report that many deployments lack audit logs or observability capable of detecting an agent acting outside its bounds [8]. CSA's own survey of 418 IT and security professionals found that 65% of organisations reported at least one AI agent incident in the preceding year. Among those organisations, 61% reported data exposure and 43% reported operational disruption [12].

The same survey presents a mixed picture of governance maturity. Most respondents (68%) report high confidence in their visibility of agents, and 66% report clear guardrails defining agent boundaries, yet 82% discovered shadow agents in the past year, monitoring is largely periodic (59%), and only 11% automatically block out-of-scope actions [12]. The sample is not limited to UK or NIS-regulated organisations, so applying it to deployers under this regime is an inference. If these patterns hold for in-scope deployers, however, many would struggle to produce the incident records and preserved evidence an inspector might request.

### Alignment With Existing UK Guidance

The legislative direction is consistent with advisory guidance the NCSC has already published. In May 2026 the NCSC recommended starting with tightly bounded tasks, applying least privilege with short-lived credentials, and assigning named owners who can approve access, review incidents, and stop the agent. It also advised ensuring that incident response covers agent failures and misuse, stating that "if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment" [9]. In August 2026 the NCSC published interim practical advice on managing cyber risk in agentic AI systems, which coverage describes as addressing human oversight, sandboxing, monitoring, and the ability to halt agent activity rapidly [10]. Organisations that implement this guidance now are likely to be well positioned for whatever the regulations eventually codify, since NIS regulators commonly draw on NCSC material, notably the Cyber Assessment Framework, when setting expectations [17].

## Recommendations

### Immediate Actions

Organisations should first establish whether they are, or are likely to become, in scope of the expanded NIS regime as operators of essential services, relevant digital service providers, MSPs, data centres, or designated critical suppliers [5]. For each in-scope service, they should build an inventory of AI agents that can act on production systems, customer environments, or sensitive data. The inventory should extend to internal automation environments and LLM platforms, which CSA's survey identifies as the most common locations of shadow agents (51% and 47% respectively) [12], as well as to agents embedded in third-party SaaS tools. Each agent should have a named accountable owner, a documented purpose, and a written statement of its intended operating envelope. That statement provides the baseline against which "loss of control" can later be judged.

Organisations should then verify their containment capability. Every production agent should have a stop mechanism that operates outside the agent's own runtime and cannot be overridden by the agent, such as credential revocation, network isolation, or orchestration-level termination. Teams should test this mechanism in a controlled exercise rather than assume it works, consistent with NCSC advice to name owners who can stop an agent [9].

### Short-Term Mitigations

Ahead of any regulations, deployers should build evidence-preservation capability for agentic workloads. In practice this means retaining tamper-evident logs of prompts, retrieved context, tool invocations, delegated credentials, and outputs for each agent action, with retention periods that anticipate a regulator's investigation rather than routine operational debugging. Incident response playbooks should also gain an explicit agentic branch. That branch should define what constitutes loss of control for each agent class and how to scope impact across systems the agent could reach. It should also set out how to sequence notifications to the regulator, the NCSC, and affected customers within the existing 24-hour and 72-hour NIS windows where an agentic event is also a reportable NIS incident [5], while remaining ready to adapt if the agentic regulations introduce a separate clock.

MSPs and cloud providers that deploy agents on behalf of customers should review contracts and shared-responsibility documentation now. They should clarify which party detects, contains, and reports an agentic incident, which party holds the logs, and how evidence will be shared if a regulator or inspector requests it. Contracts with upstream model and agent-platform vendors should require timely notification of model behaviour issues and cooperation with investigations, since the UK regime is unlikely to compel that cooperation directly [3].

### Strategic Considerations

Organisations should prepare to respond to the government's forthcoming consultation on agentic AI regulations [3]. The definitions of "AI agent," "loss of control," and reporting thresholds are likely to shape the compliance burden for years. Deployers with operational experience are well placed to argue for definitions precise enough to capture genuine safety failures while remaining workable for routine automation. Multinational organisations should also map the UK's deployer-centred model against the EU AI Act, NIS2, and US incident-reporting regimes such as CIRCIA, whose reporting requirements depend on CISA's final rule. The aim should be a single agent-incident process that can satisfy the strictest applicable timeline and evidence standard.

Boards should be briefed on the direction of travel. Commentary on the clause suggests that accountability for agent behaviour may ultimately reach executives and directors, though this view comes from a single vendor commentator and depends on how the regulations are written [1]. The statutory review that peers added, if it survives the Commons, may also revisit whether frontier AI developers and cloud services should be brought into scope more directly within twelve months of Royal Assent [3]. Governance programmes that treat agent permissions, monitoring, and decommissioning as board-level risk topics are likely to adapt more easily to that possible expansion.

## CSA Resource Alignment

CSA's survey report *Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises* is closely related prior work [12]. It provides empirical evidence on the governance gaps that the UK clause appears designed to address: high incident prevalence, persistent shadow agents, largely periodic monitoring, and weak decommissioning practice, set against generally high self-reported confidence in agent visibility. Its findings on exception handling also bear on the regulation. Many organisations rely on human approval or logging when agents exceed their boundaries, rather than automatic blocking. That practice speaks directly to how a regulator might define and evidence a "loss of control" event, and deployers can use the report's benchmarks to locate their own programmes relative to peers before regulations are drafted.

The AI Controls Matrix (AICM) v1.1 provides the control vocabulary for operationalising these recommendations [13]. Its domains covering logging and monitoring, identity and access management, security incident management, and supply chain accountability correspond to the duties the government has signalled: safeguards, incident records, evidence preservation, and notification. AICM's shared-responsibility model, which distinguishes model providers, orchestrated service providers, application providers, and AI customers, is useful for MSPs and cloud providers that need to allocate agent-incident responsibilities contractually under a regime that places accountability on the deployer.

For threat modelling the specific ways an agent can slip out of control, CSA's MAESTRO framework offers a seven-layer method spanning foundation models, data operations, agent frameworks, deployment infrastructure, and the wider agent ecosystem [14]. MAESTRO helps deployers enumerate loss-of-control pathways, such as goal manipulation, tool misuse, and privilege escalation through delegated credentials, before writing the per-agent operating envelopes recommended above. The *Agentic AI Red Teaming Guide* complements this by describing how to test those pathways in practice, including agent authorisation and control hijacking, "checker-out-of-the-loop" failures in which human or automated oversight is bypassed, impact chain and blast radius, and agent untraceability [15]. Exercises built on that guide can provide the evidence that containment controls work, which is the kind of evidence an inspector may eventually request.

## References

[1] The Register. "[UK ministers seek powers to investigate when AI agents are let off the leash](https://www.theregister.com/ai-and-ml/2026/11/06/uk-ministers-seek-powers-to-investigate-when-ai-agents-are-let-off-the-leash/5307889)." The Register, 6 November 2026.

[2] UK Parliament. "[Lords completes examination of Cyber Security and Resilience Bill](https://www.parliament.uk/business/news/2026/october-2026/cyber-security-and-resilience-bill-lords-third-reading/)." UK Parliament, November 2026.

[3] VinciWorks. "[Cyber Security and Resilience Bill: Government defeated twice as Lords demand stronger protections](https://vinciworks.com/blog/cyber-security-bill-amendments/)." VinciWorks, 29 October 2026.

[4] Cyber Security and Resilience Bill Guide. "[Cyber Security and Resilience Bill Clears the Lords](https://cybersecurityandresiliencebill.com/blog/cyber-security-resilience-bill-clears-lords-ping-pong)." cybersecurityandresiliencebill.com, 3 November 2026.

[5] UK Department for Science, Innovation and Technology. "[Cyber Security and Resilience (Network and Information Systems) Bill: Summary of the Bill](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/summary-of-the-bill)." GOV.UK, November 2025.

[6] Help Net Security. "[UK's new Cyber Security and Resilience Bill targets weak links in critical services](https://www.helpnetsecurity.com/2025/11/12/uk-cyber-security-and-resilience-bill/)." Help Net Security, 12 November 2025.

[7] SECNEWS. "[Peers table 24-hour customer alerts and AI incident reporting](https://secnews.co.uk/2026/10/cyber-security-resilience-bill-lords-amendments-24-hour-customer-alerts-ai-reporting/)." SECNEWS, 11 October 2026.

[8] The Register. "[OpenAI alerts 100+ orgs that its 'misaligned models' attempted to break in - or worse](https://www.theregister.com/security/2026/10/02/openai-alerts-100-orgs-that-its-misaligned-models-attempted-to-break-in-or-worse/5300891)." The Register, 2 October 2026.

[9] National Cyber Security Centre. "[Thinking carefully before adopting agentic AI](https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai)." NCSC, 15 May 2026.

[10] LexisNexis. "[NCSC publishes interim practical advice on managing cyber risk in agentic AI systems](https://www.lexisnexis.co.uk/legal/news/ncsc-publishes-interim-practical-advice-on-managing-cyber-risk-in-agentic-ai-systems)." LexisNexis Legal News, 21 August 2026.

[11] Computing. "[Government rules out AI 'kill switch' as tech leaders urge caution](https://www.computing.co.uk/news/2026/ai/government-rules-out-ai-kill-switch-as-tech-leaders-urge-caution)." Computing, September 2026.

[12] Cloud Security Alliance. "[Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises](https://cloudsecurityalliance.org/artifacts/autonomous-but-not-controlled-ai-agent-incidents-now-common-in-enterprises)." CSA, 20 April 2026.

[13] Cloud Security Alliance. "[AI Controls Matrix (AICM) v1.1](https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1)." CSA, 22 June 2026.

[14] Ken Huang, Cloud Security Alliance. "[Agentic AI Threat Modeling Framework: MAESTRO](https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro)." CSA, 6 February 2025.

[15] Cloud Security Alliance. "[Agentic AI Red Teaming Guide](https://cloudsecurityalliance.org/artifacts/agentic-ai-red-teaming-guide)." CSA, 28 May 2025.

[16] UK Department for Science, Innovation and Technology. "[Cyber Security and Resilience Bill factsheet: Relevant managed service providers](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/relevant-managed-service-providers)." GOV.UK, November 2025.

[17] National Cyber Security Centre. "[Cyber Assessment Framework](https://www.ncsc.gov.uk/collection/cyber-assessment-framework)." NCSC.