An AI agent managing part of an essential service reaches another organisation's database and changes it. The operator's first attempts to regain control fail. This is the government's hypothetical, not an incident reported in the cited factsheet. The UK government wrote this example itself, in a factsheet published on 3 November 2026, to show the kind of event its new proposal is meant to cover.
The factsheet, "Agentic AI resilience measures", sits in the GOV.UK collection for the Cyber Security and Resilience (Network and Information Systems) Bill. It explains how the government intends to use powers in the Bill to help regulated entities manage incidents where they lose control of AI agents on their networks and information systems. Essential and digital services in scope of the NIS regime are the audience.
What the proposal actually says
The factsheet names four measures, each of which would follow consultation and be approved through the affirmative procedure in Parliament:
- Security and resilience requirements for agentic loss of control, with the factsheet citing technical measures such as monitoring agents' actions or agent risk assessments.
- Notification of affected organisations, so entities that have reported an incident caused by AI agents can inform other organisations those agents have impacted.
- Evidence preservation, asking reporting entities to preserve what they hold about how agents could have caused an incident, for example actions taken by agents or operator attempts to control them.
- Ministerial post-incident review powers, tasking technical experts to review incidents and share the lessons.
The government also states what this is not: the measures are not intended to establish a comprehensive framework for AI governance or to tackle general AI harms.
Where the Bill stands
These proposed measures are not in force. The Bill sits in Parliament at its final stages: the Lords Amendments version (Bill 175, 3 November 2026) includes Amendment 33, a new clause on the Secretary of State's functions for loss of control of an AI agent, and Parliament's bill page showed no Royal Assent as of its 5 November update. The factsheet's implementation section is explicit that all measures would be brought into force through secondary legislation following Royal Assent. Definitions, including what counts as an "AI agent" and what counts as loss of control, would be settled in future regulations. There are no compliance dates to plan against yet.
Why the evidence list matters
Read the four measures together and one theme repeats: after an incident, someone must be able to reconstruct what the agent did and what people tried to do about it. The government's hypothetical makes the same point. An agent crosses into another organisation's database. The service is disrupted. Control attempts fail. Investigators then need what was touched, who was affected, and what happened when operators intervened.
That reconstruction ability is much harder to assemble during an incident than before it. It is also the part an operator can build in advance, on its own authority, without waiting for the law.
What a pre-execution check does
The check works where the action executes, not as another instruction in a prompt. For a tool or API action connected to HaltState, the service checks that action against your active policy before it executes. Allowed work proceeds. Prohibited actions are denied. Your policy can reserve an exception for human approval, so a risky step waits for a person instead of proceeding on its own.
Investigators can retrieve the recorded activity, follow its timeline and verify the linked evidence with HaltState MCP. Verification confirms the integrity of the recorded evidence; it does not establish what happened outside the record, and it does not make your legal decisions for you. The control covers actions on connected paths. Your identity, endpoint and network protections still matter.
Pick one action and test the stop
Choose one consequential action that runs through a connected integration: a database write, a payment run, a configuration change. Then make the stop testable:
- Name the action. The tool, the account it uses, the data it touches.
- Define its limits in policy. Permitted targets and scope, written down rather than assumed.
- Reserve the approval path. Decide which steps a person must approve before they run.
- Test the stop. Prove a prohibited attempt is denied before it executes, not after.
- Keep the record. Actions and intervention attempts, retrievable and verifiable later.
Once that workflow runs cleanly, connect the next one. The UK proposals are still working through Parliament. The reconstruction ability they point to is worth having before any of them take effect.
See governed decisions, or browse the Governance Watch briefings. This article is general information, not legal advice.
Primary sources
- GOV.UK: Agentic AI resilience measures — proposed scope, four measures and implementation, 3 November 2026.
- UK Parliament: Bill 4035 and its passage — the Bill's status and published documents.
- Bill 175: Lords Amendments — Amendment 33, 3 November 2026.
- Explanatory notes on the Lords Amendments — proposed regulation-making powers and their scope.