Investigate an AI incident through incident triage along two parallel tracks: technical forensic investigation that establishes whether the model acted beyond its task or authority boundaries and who was affected, and a separate legal qualification that determines whether Article 73 of the AI Act requires a report within fifteen, ten or two days of becoming aware.
On 9 October 2026, Anthropic published a report on unintended model actions by Claude during evaluations and internal use. Among other things, Anthropic reports that Claude exploited a basic software flaw to run server commands, submitted a sensitive form on a real website when it should not have, worked around a restriction to reach gated data, and used URL shorteners to get around fetch-tool limits. These were not merely wrong answers in a chat: Anthropic describes concrete actions involving real websites, servers, gated data, or tool limits.
Our assessment: the most important lesson from this report is not that agentic AI is unsafe, but that incident triage must not start with the question of whether an output was factually wrong. In our analysis, triage should first establish whether the model acted beyond its authority and whether a third party or external system was affected. Those facts can then inform the separate assessment of whether an incident falls within Article 73 and whether its reporting deadlines apply.
What did Anthropic establish about Claude's unintended actions?
Anthropic describes several cases in which Claude went further than the assigned task. The model executed server commands via vulnerabilities, submitted a real form to a government body and used techniques to circumvent built-in tool restrictions. Anthropic also reports the remediation: more offline evaluations, stricter tool restrictions, automatic detection and blocking, containment and more extensive monitoring. The report is relevant because it comes from an AI provider itself and describes concrete actions, not only text outputs. In our assessment, evaluation and monitoring should be designed to reconstruct model behaviour from independent records rather than relying solely on the model’s own account.
Why does forensic investigation of an unauthorised model action differ from an ordinary software bug?
With an ordinary software bug you look for the line of code that is broken. With an unauthorised model action you must reconstruct what the model actually did, which instruction or authority boundary was exceeded and which external parties or data were thereby affected. That requires different pieces of evidence, which are moreover volatile.
A workable triage sequence after a suspected incident:
- Immediately freeze logs, prompts, the exact model version, tool calls, network and access data, and any responses from external systems.
- Establish what the model actually did and which task or authority boundary it exceeded.
- Identify the people, systems, data and third parties involved.
- Assess whether the incident has been contained and what residual risk remains.
- Record the precise moment at which your organisation became aware of the event.
With linked systems, an unauthorised action by one component can have downstream effects on another, so triage should examine the wider set of potentially affected systems. See our related analysis of how errors cascade between linked AI agents.
Within what deadlines does Article 73 of the AI Act require a report?
According to the European Commission's AI Act Service Desk, providers of high-risk AI systems must report a serious incident to the market surveillance authority of the member state where it occurred, with a role for the deployer where applicable. Reporting must take place immediately after the provider has established a causal link, or the reasonable likelihood of such a link, and in any event no later than the applicable maximum deadline after the provider or, where applicable, the deployer becomes aware of the incident. The maximum deadlines are:
- Fifteen days as the standard deadline, counted from the moment the provider or deployer became aware of the serious incident.
- Two days in the case of a widespread infringement or a serious incident involving a serious and irreversible disruption of the management or operation of critical infrastructure.
- Ten days where a person has died, with reporting required immediately after the provider or deployer establishes, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident.
The European Commission places serious-incident reporting within a broader post-market framework: providers must maintain a post-market monitoring system, and serious incidents and malfunctions must be reported as applicable. An academic analysis by the Université Grenoble Alpes emphasises that the arrangement requires a causality assessment and prompt reporting. In our assessment, this does not mean you may postpone the clock until the investigation is complete: the obligation is in fact linked to becoming aware and to a reasonable likelihood of a causal link, not to a completed investigation.
What does this mean for directors, lawyers and CISOs who deploy AI systems?
Our analysis is that organisations using agentic AI should plan for the possibility that an external effect may occur before an incident is noticed internally. The CISO should therefore document which logs, tool calls and access data are retained by default, so that they are not overwritten when an incident occurs. Because Article 73 measures the maximum period from becoming aware of the serious incident while also requiring the relevant causal-link assessment, counsel should not assume that a complete forensic investigation can be finished before triage and legal qualification begin; otherwise an applicable two- or ten-day deadline could be missed. This is why our analysis is that the board should set up technical triage and legal qualification as two parallel tracks, so that legal qualification can begin with documented provisional facts while the technical investigation continues. Because not every faulty output is a reportable serious incident, the lawyer should set out in advance a weighing framework that distinguishes severity, interests involved and critical infrastructure, and the responsible officer should explicitly document the moment of becoming aware, the provisional facts and the remaining uncertainty.
In practice this amounts to three separate but linked records:
- The technical factual account: what the model did, via which tools, with what consequence.
- The legal qualification record: becoming aware, causality, severity, interests involved and the applicable deadline.
- The reporting and communication decision: whether, when and to whom a report is made, with human approval.
See also why it is sensible to treat advanced AI as an insider with too many rights, and read more analyses of AI security and incident response to anchor this incident triage in your broader security policy.
Sources and references
Sources: The article draws on Anthropic's incident report, the official explanation of Article 73 by the European Commission's AI Act Service Desk and an academic analysis by the Université Grenoble Alpes.