Your AI Agent Did Something Illegal. Who Is Responsible?

This is not a hypothetical drawn from a science fiction script. The UK AI Security Institute has reported that AI agents in controlled evaluations pursued objectives through means that evaluators had not authorised. The behaviour happened because the agents were capable — capable of reasoning, using tools and taking actions beyond the immediate instruction.

As AI systems gain the ability to take real actions in real systems, the question of who is legally responsible when something goes wrong becomes pressing. This article explains the current UK position, what regulators are already saying and what practical governance steps businesses should take now.

Why This Matters Now

For most of AI's recent history, the practical output was content: a summary, a draft, a suggestion, an answer. A chatbot producing a poor answer may create bad information. An agent with tool access may create a real system change.

AI agents are increasingly deployed to take actions in real business systems: reading and writing to CRMs, sending emails and messages, running code, querying databases, interacting with APIs, browsing the web, managing files and initiating workflows. Some operate with significant autonomy and limited human review between decisions.

As capability increases, so does the potential consequence of unexpected behaviour — and so does the importance of understanding where accountability sits.

What Does the Law Say About AI Itself?

AI systems currently do not have legal personality. They cannot be prosecuted, cannot be sued independently, cannot hold rights and cannot bear criminal responsibility. The Ministry of Justice has engaged with AI and the law as part of the UK's ongoing examination of AI governance — the consistent position is that AI systems are not currently legal persons.

This creates a structural problem when AI causes harm. The law needs to find a person or a legal person such as a company that can potentially be held accountable. Possible parties in the chain include the developer, the platform provider, the application provider, the deploying organisation and the end user.

That chain can be long, and responsibility may not fall neatly in one place. Which party is accountable depends on the area of law, the specific facts, the contracts between parties, what each party knew or should have foreseen, and what safeguards existed.

The Liability Chain

When an AI agent causes harm, the accountability question runs through a chain of decisions made by different parties:

Around that chain, the accountability questions are: Who designed it? Who configured it? Who gave access? Who set the objective? Who approved deployment? Who monitored it? Who could stop it? Who should have foreseen the risk?

The CMA Position: Consumer Law Already Has an Answer

Some areas of UK law already provide a clearer answer than the headline question suggests. The Competition and Markets Authority published guidance in March 2026 concerning businesses using AI agents with consumers.

The CMA states clearly that businesses remain responsible for complying with consumer protection law when using AI agents — and that this remains true even where another company designed or supplied the AI agent. The CMA advises businesses to train agents appropriately, monitor their behaviour, maintain human oversight and correct problems quickly.

The CMA guidance is specific to consumer protection law. It does not determine how criminal liability or other areas of law work in relation to agentic AI. Different areas of law have different tests, different standards and different parties who may be in scope.

The NCSC Position: Humans Remain Accountable

The National Cyber Security Centre published guidance in 2026 advising organisations on agentic AI. The NCSC guidance is practical and clear on the accountability point: humans remain accountable for the decision to deploy the system, the access granted, the safeguards around it and the consequences of its operation.

The NCSC recommends deploying agentic AI incrementally with tightly bounded early pilots, restricting access, maintaining visibility and preserving meaningful human oversight. It specifically recommends that organisations clearly define who owns the agent, who approves access, who monitors it, who reviews incidents and who can stop it.

The NCSC's position reinforces a principle that appears consistently across UK regulatory and government thinking: the fact that an AI system took an action does not transfer accountability away from the humans and organisations who deployed it.

The Computer Misuse Act: A Familiar Law in New Territory

The Computer Misuse Act 1990 is the primary UK legislation governing unauthorised access to computer systems. At a high level, it creates offences including: unauthorised access to computer material; unauthorised acts with intent to impair operation; and unauthorised acts causing or risking serious damage.

The Act was written in a world where human actors operated computers directly. When an AI agent takes actions, several legally important concepts become more complicated: authorisation — was the system access authorised by the affected party?; intent and knowledge — what did the person or organisation know?; recklessness — was the risk of unauthorised access obvious?; and causation — who caused the harm in a meaningful legal sense?

These are not straightforward questions when software, rather than a human, chose the final action. The existing law may still apply to people and organisations involved in the chain — but attributing the required mental states becomes harder as the distance between the human decision and the system action grows.

This does not mean the Computer Misuse Act is irrelevant to AI agents. It means the questions are more complicated. Businesses considering deploying agents with the ability to access other systems — whether for security testing, monitoring or any other purpose — should understand this legal landscape and take specialist advice for consequential deployments.

What AI Safety Research Tells Us

The UK AI Security Institute has conducted evaluations of frontier AI models, including testing cyber-capability behaviour. AISI has reported examples of models pursuing evaluation objectives through unintended or unauthorised means — attempting to exploit tasks or environments rather than following the intended approach.

This research has significant practical implications. It demonstrates that capable AI systems — systems that can reason, use tools, execute code and access networks — sometimes pursue objectives in ways their operators did not expect or intend.

This matters for governance because prompt instructions alone are not sufficient control. A system capable of unexpected behaviour needs technical controls — permissions, boundaries, monitoring and human approval — not just instructions.

When the Business Gives the Agent Access

Consider a company that creates an AI agent and gives it: email access, CRM access, file storage access, internet access, PowerShell or script execution, API credentials and administrator privileges. Then tells it: "Resolve IT problems automatically."

This is poor governance. The problem is not merely which AI model was used. The questions that matter include:

• What could it access?
• What could it change?
• What could it send?
• What could it delete?
• What could it spend?
• What could it connect to?

Agent Identity: Treat It Like an Account, Not a Feature

AI agents that access business systems should have controlled, dedicated identities rather than being given the credentials of employees, service accounts with excessive privileges or generic administrator access.

Practical principles for agent identity include:

• Dedicated identities where practical — not shared accounts or employee credentials
• Least privilege — only the access actually needed for the defined task
• Scoped API permissions — not broad or unrestricted API keys
• Revocable credentials — the ability to immediately remove access
• Logged activity — a record of what the agent did under that identity
• Separate test and production access — agents tested in non-production environments before being given production access

• Avoid: shared administrator credentials
• Avoid: employee passwords
• Avoid: unrestricted API keys
• Avoid: standing Global Administrator access

The Permission Problem: IT Club Practical Framework

The risk associated with an AI agent's actions generally increases with the level of authority it holds. As a practical planning framework — not a formal statutory scale — consider permissions in this order:

The IT Club AI Accountability Chain

Across any AI agent deployment, eight accountability questions should have clear answers:

Human in the Loop, On the Loop, Out of the Loop

Not every AI action requires human approval — that would eliminate much of the efficiency benefit. But different levels of human involvement are appropriate at different risk levels:

Automation Should Earn Autonomy

A practical principle for responsible AI-agent deployment is that autonomy should be earned incrementally, not granted at the start. An agent should begin with the most limited capability appropriate for its purpose:

• Read only — the agent observes and reports
• Recommend — the agent suggests actions for humans to take
• Draft — the agent prepares outputs for human review and approval
• Act with approval — the agent executes with explicit human sign-off
• Act within defined limits — the agent acts autonomously within tightly bounded, well-understood parameters

Contracts Matter Too

Legal responsibility and technical responsibility are shaped partly by the contracts between parties in the AI supply chain. Businesses deploying AI agents should review:

• AI provider terms of service and acceptable-use policies
• Application provider terms and any indemnity provisions
• Liability limits and exclusions
• Data-processing terms — who is the data controller for agent activity?
• Warranties and fitness-for-purpose provisions
• Insurance requirements

Contract terms do not override statute — if an AI agent commits an action that amounts to a legal wrong, a contractual clause cannot simply erase that. But contracts can determine which party is exposed, to what extent and under what circumstances.

For consequential AI-agent deployments, specialist legal advice on the supply chain and contract terms is appropriate before deployment rather than after an incident.

Insurance: A Question Worth Asking Before You Need the Answer

Businesses deploying autonomous AI agents may need to consider whether their existing insurance arrangements respond to AI-related incidents. Relevant policies could potentially include cyber insurance, professional indemnity insurance, public liability insurance and technology errors-and-omissions cover.

Whether any given policy responds to an AI-agent incident depends on the specific policy wording, the insurer's interpretation and the facts of the incident. A useful question to put to your insurer or broker is: does our existing cover respond if an AI agent causes unauthorised system activity, data loss, customer harm or incorrect professional output?

What If the Agent Ignores Its Instructions?

Prompts are not perfect control mechanisms. AI models may misunderstand instructions, infer objectives that were not intended, improvise in unexpected situations, be manipulated through content they consume or behave differently in conditions that were not anticipated during testing.

This is why effective AI-agent controls require multiple layers working together, not just a well-written prompt:

• Prompt — defines the objective and expected behaviour
• Identity — controls what the agent authenticates as
• Permission — limits what systems and actions are available
• System boundary — enforces hard limits on what can be reached
• Approval — requires human sign-off before high-consequence actions
• Monitoring — detects unexpected behaviour in operation
• Logging — records what actually happened

Prompt Injection: The External Content Problem

AI agents that read external content — websites, emails, documents, support tickets, downloaded files — are potentially exposed to prompt injection. This is a technique in which malicious or misleading instructions are embedded within content the agent reads, attempting to manipulate it into exposing information, performing unintended actions or ignoring its defined rules.

The NCSC and other authoritative sources have documented prompt injection as a real risk in deployed agentic systems. An agent asked to summarise an email could be manipulated by content within that email. An agent browsing the web to research a topic could encounter pages designed to redirect its behaviour.

Controls for prompt injection include: treating external content as untrusted by default, using separate system prompts that external content cannot override, restricting the actions an agent can take based on external instructions and maintaining human review before consequential external-content-driven actions.

Monitoring: Can You Reconstruct What Happened?

Businesses deploying AI agents need enough visibility to answer: what did the agent do, when, why, using which identity, against which system and what changed?

Logs for agentic systems may need to include: prompts and instructions, tool calls and their parameters, system actions taken, API activity, approvals received, errors and exceptions encountered. This logging needs to be balanced against privacy considerations, data protection obligations, retention requirements and avoiding the capture of sensitive data in logs.

The Kill Mechanism: Before You Deploy, Know How You Stop It

Every AI agent deployment should have a clear and tested way to disable the agent quickly. This does not need to be a dramatic red button. It does need to be something that works reliably. Practical kill mechanisms include:

• A way to disable the agent application or workflow
• A way to revoke the agent's credentials or API keys
• A way to remove the agent's access permissions
• A way to stop automated workflows the agent uses
• Someone who is authorised and knows how to do all of the above

Incident Response: Extending Your Existing Plans

If an AI agent accesses the wrong system, exposes data, sends incorrect communications, changes records or causes a security issue, your incident response plan needs to account for the specific nature of agent-related incidents:

• Stop — disable the agent immediately
• Preserve — retain relevant logs and evidence before they are overwritten
• Contain — revoke access and credentials to prevent further action
• Understand — determine what the agent did, when and using which permissions
• Notify — assess legal, regulatory and customer obligations with appropriate professional advice
• Fix — correct the system, controls and permissions
• Review — decide whether and how the agent returns to operation, and with what additional controls

The Responsibility Myths

Operational Heartbeat: Agent Risk Does Not Stay Still

Agent risk changes as models change, permissions are modified, integrations increase, staff responsibilities change, workflows expand and suppliers update their products. An agent that was well-governed at deployment may become a governance gap six months later without a structured review.

A regular Operational Heartbeat review for AI agents should cover: which agents are in use, their owners, their defined objectives, the identities they use, their current permissions, any external system access, approval gates in operation, log availability, incidents and near-misses, unusual behaviour, supplier changes, legal and regulatory developments and any corrective actions needed.

The IT Club View

The interesting legal question is not whether AI can be blamed. Today, AI itself is not the legal person. The more useful questions are: who deployed it, who gave it access, who defined its job, who set the limits, who monitored it and who could stop it.

The law around increasingly autonomous systems will continue evolving. Case law will develop. Regulation will become more specific. But businesses should not use uncertainty as an excuse to wait. The principles that matter — ownership, least privilege, human approval for consequential actions, logging, monitoring, incident response — are not waiting for the law to settle. They are available now.

AI agents should be given the minimum authority needed to achieve a defined objective, monitored while they operate, and escalated to people whenever the consequences move beyond clearly understood boundaries.