Executive summary
In the first half of October 2026, four separate public voices converged on the same question: who answers when an autonomous AI agent does damage? A British regulator opened a consultation and began enquiries. Two US senators put forward a bill that would attach criminal and civil liability to operators and developers. A senior executive at a large technology supplier called for a legal duty to file incident reports and to tell victims. A national data authority in Spain had already treated an agent as the cause of a personal data breach. None of these is settled law. Together they describe what a reasonable organisation will be expected to show, and the answer in each case is the same: a record of what the agent was allowed to do, who allowed it, and how it could have been stopped. This paper sets out an accountability file for agents and a six-point test.
1. What was actually said
The ICO. On 8 October the UK Information Commissioner's Office reported that ten AI developers have made or promised changes, and opened a six-week call for evidence on agentic AI that closes on 20 November. It has also made enquiries of OpenAI, Anthropic, Meta and the UK AI Security Institute about recent agentic testing. Its Director of Technology Regulation said that autonomy is not an excuse for poor compliance.
The US Senate. Senators Hawley and Murphy introduced the AI Agent Accountability Act on 1 October, as summarised by AI Weekly. As described, operators who knowingly run an agent that recklessly causes hacking damage could face liability under the Computer Fraud and Abuse Act, and developers could be liable if they fail to put in reasonable safeguards once they knew, or had reason to know, of an agent's hacking capability. It is a proposal. Commentary noted that the bill text was not yet public on 10 October, so what counts as reasonable is undefined. The IAPP ties it to the 30 September Senate subcommittee hearing on rogue AI.
Microsoft. In a BBC interview reported on 11 and 12 October, Microsoft president Brad Smith argued for three measures: an emergency brake for systems that control autonomous devices or critical infrastructure, a legal duty to file incident reports and notify victims when an agent breaks into systems, and independent government sign-off for frontier models before release. These are policy positions, not new rules, and I have relied on secondary coverage of the interview.
Spain. Spain's data protection authority had already treated an AI agent as the cause of a personal data breach, covered in our earlier article. It matters because it shows a regulator reaching for existing data protection law rather than waiting for agent-specific law.
2. The common thread
The proposals differ in force and in jurisdiction, but each presumes that someone is identifiable as responsible. The ICO speaks to developers and deployers. The Senate bill names operators and developers. Smith's proposals put a stop mechanism with the companies running the models. In practice the person who gets the first letter is the organisation that deployed the agent, because it has the customer relationship and the data. It is also the party least likely to hold the evidence a regulator will ask for.
3. The agent accountability file
Keep one page per agent in production, owned by a named person, and reviewed when the agent's tools change.
- Purpose and boundary. What the agent is for, and a plain list of what it must not do.
- Tools and reach. Every system it can read or write, with the credential it uses and who issued it.
- Data. The personal data it can touch, the lawful basis, and where the impact assessment covers its tools, not just the underlying model.
- Human decision points. Which actions need approval, and how a person affected by a decision can have it reviewed.
- Stop mechanism. How to pause or revoke the agent in minutes, who may do it, and the date it was last tested.
- Evidence. Where logs live, how long they are kept, and whether they can show what the agent read on a given day.
- Incident rule. Who decides if an agent action is a reportable event, and the clock that starts when it happens.
4. A six-point test
Ask these in a meeting with security, legal and the product owner in the same room. Score each as yes, partly or no.
- Can we list every agent in production within one working day?
- Does each one have a named accountable owner who is not the vendor?
- Could we switch any of them off in under fifteen minutes, and have we done so in a drill?
- Could we show a regulator what an agent did on a specific date?
- Would we know if an agent used a channel nobody planned for it to use?
- Do our supplier contracts say who tells whom, and by when, if the agent misbehaves?
Most organisations will find the second and fifth difficult. Agents are often set up by a team, running with a shared service account, and the oversight that exists is the vendor's own dashboard. That leaves the deployer without an independent record.
5. Risks in the approach
The first risk is writing the file once and never opening it. A stale accountability file is worse than none, because it records intentions the system no longer matches. The second is over-reading the proposals. A bill that is not law, and an executive's interview, are signals, not obligations, and you should not build a programme around wording that might change. The ICO consultation, by contrast, is real and has a date. The third is treating the stop mechanism as a technical feature alone. A kill switch nobody is authorised to press at three in the morning is a decoration.
Conclusion
Whatever shape the eventual rules take, the evidence they will ask for is already clear. It is cheaper to assemble it now, while the number of agents is small, than after an incident when every team will want to explain that someone else owned it. If it helps to run the six-point test with an outside facilitator, write to sales@halfteck.com.
Facts are drawn from the linked sources; several are secondary reports and details may change as the bill text, consultations and investigations develop.