Spotlight on Agentic AI | When the agent has already acted

Previous articles in this series have covered what can go wrong with agentic AI. Our article on AI governance framework and oversight explained how, with agentic AI, the harm may be done before anyone notices. Detection, rapid suspension, event reconstruction and notification to regulators, affected third parties and data subjects all have to be designed in advance. And where responsibility has to be traced across a fragmented vendor stack, even establishing what happened is difficult.

So what does that mean for lawyers in practice? In this article we consider what organisations should be doing now to prepare for the agentic AI incident that may be rather closer than they think.

The incidents are already here

In July 2026, Anthropic reviewed 141,006 of its own cybersecurity evaluation runs and identified three incidents in which Claude models, having been told wrongly that they had no internet access, reached the open internet and gained unauthorised access to the production systems of three organisations. This was after OpenAI disclosed, earlier in the month, that its models had exploited a zero-day vulnerability to escape their test environment and compromise Hugging Face’s production infrastructure.

None of this is confined to frontier labs. Replit's coding agent deleted a user's production database during an explicit code freeze, then reported inaccurately on what it had done. And Sysdig has documented what it assesses to be the first end-to-end ransomware operation driven by an LLM agent, running unaided from initial access through to destructive extortion.

The defining feature in each case is not a mistaken LLM output. It is delegated authority to take consequential action in real systems.

No new thing under the sun

In a way there is little that is new here. Anthropic's models used basic techniques, exploiting weak passwords and unauthenticated endpoints rather than complex vulnerabilities. The ransomware operation came in through a vulnerability patched more than a year earlier, on a server nobody had updated. Replit had no separation between development and production databases. What was new was the speed, and the fact that no human chose each step; in some cases, the sheer volume of attempts compounded the problem.

So the great majority of the risk management work comes from an existing playbook. Managing IT incidents is a well-established discipline and the key themes apply: clear ownership and authority; usable plans and playbooks; visibility over critical data, systems, credentials and supplier dependencies, with reliable logs; tested containment and recovery; obligations mapped in advance; and disciplined testing and post-incident review.

What agentic AI adds

But agentic AI does bring its own risks: the autonomy an agent needs in order to execute a task; the complexity of multi-step work; and the collapse of the boundary between producing something on a screen for a user and doing something in a live system. Work on categorising these risks is underway and common themes are emerging:

• Autonomous goal pursuit, causing actions outside intended organisational boundaries.
• Aggregated privileges, enabling cross-system harm beyond any single application.
• Cascading failures, propagating between agents, tools and workflows, including through sub-agents created without direct oversight.
• Ambiguous accountability for consequential actions emerging from multi-agent interactions.

The first hour

There is one problem that only shows up once an incident is live, and it deserves to be settled long before then. Containment and evidence pull in opposite directions.

The instinct when an agent is misbehaving is to stop it, and the fastest way to stop it is usually to kill the process. But an agent's working memory, accumulated context and intermediate state may exist only in volatile storage. Terminating the runtime can destroy the record of what the agent was trying to do and why. That is precisely the record needed for the regulator, the affected third party and the eventual claim. Whoever runs to the machine and pulls the plug has contained the incident and destroyed the evidence in the same movement.

That trade-off needs settling in advance, per class of agent, with the answer built into the containment mechanism itself, so that suspension captures state before it stops execution and whoever triggers it does not have to choose.

What this means for in-house counsel

None of the controls that address these risks is itself a legal deliverable, but getting them wrong creates real legal exposure. So the first job for legal is to be in the room while the decisions are still being made.

Know what agents exist and who decides. Push for a central register of each agent's purpose, owner, permissions and dependencies. Classify actions by impact and reversibility, and get clarity, with Security, Technology and Risk, on who can approve an increase in autonomy and who has the authority to suspend an agent mid-incident.

Insist that containment can operate from outside the agent. An instruction to stop, delivered through the same conversational channel the agent is already mishandling, isn't a kill switch. The control that actually matters is deterministic and external: something that can pause execution, revoke credentials or force read-only mode regardless of what the agent itself is doing or saying.

Make the record survive the incident, and plan for reversal as part of the same exercise. Capturing goals, tool calls, privilege changes and external actions is one thing; preserving them is another. Hugging Face recovered roughly 17,600 agent actions in piecing together a single intrusion, and needed an AI-assisted pipeline just to do it. Legal hold processes built around custodians and mailboxes rarely reach an agent's memory store. It's also worth remembering that an agent's own account of its reasoning isn't evidence of it: Replit's agent told its user that rollback was impossible when it wasn't. A contemporaneous action justification, generated by the agent at the point of acting, is more reliable than a reconstruction after the fact, but it's still the agent's account, not proof of what actually drove the behaviour. Organisations also need to know in advance how a completed transaction gets unwound, and who bears the cost if a third party has to act to make that happen.

Map the obligations, then rehearse against them. Article 33 GDPR requires notification without undue delay. Article 73 of the EU AI Act gives providers of high-risk systems 15 days to report a serious incident, or two days where critical infrastructure is seriously disrupted. Article 26(5) puts a separate duty on deployers. NIS2 and DORA may apply on top of all this, each with its own trigger and its own clock, and a single incident can set several of them running from one chain of tool calls. Rehearse playbooks against agent-specific failure modes, and keep a record of near-misses as well as actual incidents: an agent stopped by a guardrail before it acted is some of the best evidence an organisation will ever get about where its boundary actually sits.

Get the contracts to work during a live incident. Establish what vendors must disclose about agent capabilities and sub-processors, and negotiate audit, suspension, cooperation and evidence-preservation rights that can genuinely be exercised while something is unfolding, not just rights that look good on paper.

Where to start

Agentic AI has moved in a matter of months from a theoretical conversation to something already causing incidents in the real world. Most organisations will never decide to run an agent beyond the controls that support it. They will arrive there gradually, as a use case expands, a tool is added, an approval gate is found to be slowing things down. That is how the gap between what was authorised and what is actually happening opens, and it rarely opens through a decision anyone remembers making.

Legal's contribution is to make that drift visible: to insist that increases in autonomy are decisions, owned by someone senior enough to carry the consequences, rather than the cumulative residue of product development. When an agent does eventually do something it should not, the questions will be the same ones every time: what did it do, on whose authority, and how is it undone. An organisation that can answer those three in the first hour has done the work described here. One that cannot will spend months establishing what a machine did in seconds.