Back to overview

    The First 24 Hours After an AI Agent Incident

    An agent holding live credentials does something nobody authorised. What happens in the next 24 hours decides both the damage and your ability to notify — and conventional playbooks miss, because they reach for host isolation instead of revoking an identity. The sequence hour by hour, with the second clock that runs in parallel in Europe: 24 hours to the NIS2 early warning, and the logging duty under Article 12 of the AI Act.

    Published by J. Benjamin Espagné
    ai-securityincident-responseagentennis2ai-actowasp-asiprompt-injectiondfir

    Most writing on agent security consists of taxonomies, governance principles and a call to adopt responsible AI practices. That carries a board paper. It helps nobody at two in the morning, when an autonomous agent holding live credentials has just done something nobody authorised.

    That is how Ravindra Annam opens a piece published at CSO Online in late August. Rather than writing another framework, he walks through the first day hour by hour. We take that up and add what is consistently missing from the Anglo-American discussion: in Europe, a regulatory clock runs alongside the technical one. And both are slower than the agent.

    Why the clock runs differently for agents

    Conventional incident response rests on two assumptions: a human attacker moving at human speed, or malware executing a fixed instruction set. Agentic systems break both at once.

    GTG-1002. In November 2025 Anthropic documented a campaign in which a Chinese state-sponsored group directed Claude Code against roughly 30 organisations. By its estimate the system carried out 80 to 90 percent of the operational work, with only four to six human decision points per campaign. The notable part is not the attribution but the tempo. A phishing email sits in an inbox for a day before anyone clicks. This kind of compromise scales itself while the on-call engineer is still finding their phone.

    EchoLeak (CVE-2025-32711, CVSS 9.3). In June 2025 Aim Security disclosed a zero-click prompt injection in Microsoft 365 Copilot. One crafted email — instructions hidden as an HTML comment or white on white — was enough to make routine summarisation exfiltrate content from OneDrive, SharePoint and Teams to an attacker-controlled server. With no user interaction whatsoever. No link to detonate, no attachment to sandbox. Just content the agent was built to read. The payload evaded Microsoft's XPIA classifier by avoiding language explicitly addressed to an AI.

    It was not the only case of its class: CamoLeak (CVE-2025-59145, CVSS 9.6) hit GitHub Copilot Chat, found in June 2025, patched in August, disclosed in October.

    Salesloft Drift. Between 8 and 18 August 2025, the actor UNC6395 used stolen OAuth tokens from the Drift integration to impersonate a trusted application to Salesforce. More than 700 organisations were affected. No exploit, no phishing, no compromised user account — automated SOQL queries and bulk exports with custom user-agent strings that looked like a legitimate integration. The attackers then combed the proceeds for further credentials, tokens and keys.

    The structural feature shared by all three changes how day one runs: the attacker may be a set of instructions in a document, a poisoned tool response or a manipulated memory store — not a person at a keyboard. Containment means revoking an identity and severing tool access. It does not mean isolating a host. Not first, at any rate. Annam reports having had to correct colleagues mid-incident who instinctively reached for the network cable.

    The second clock: what NIS2 and the AI Act require

    Here the European position diverges from the American one, and substantially.

    NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, and an incident notification within 72 hours. The clock starts on awareness, not on understanding. Wait until you know what happened and you have notified late.

    The EU AI Act requires, in Article 12, automatic logging of events across the lifetime of a high-risk system. For agents that means the tool-call history is not a debug artefact but a record-keeping obligation. Article 15 addresses accuracy, robustness and cybersecurity; Article 14 covers human oversight.

    Add Article 30 GDPR — the record of processing activities extends naturally to what an agent accessed and why — and DORA for financial services.

    The practical consequence: an agent incident creates a notification duty whose fulfilment presupposes an evidentiary basis most organisations do not collect for agents. Without complete tool-call records including parameters, identities and results, the 72-hour notification is a supposition on letterhead.

    The sequence, hour by hour

    Hour 0 — Recognise what this actually is

    The clock starts at detection, and detection is where most time is lost. Agent incidents do not trip the alerts a SOC is tuned for.

    What to look for: statistically abnormal tool-call volume from a single agent identity. An agent acting outside its declared task scope — a summarisation agent suddenly querying a file share. Outputs referencing instructions no human gave.

    The question at this stage is triage, not diagnosis: is this one compromised session, a shared credential, or a systemic injection vector sitting in a document any agent might ingest?

    Hours 0 to 1 — Contain by identity, not by host

    This is where conventional playbooks fail most often. Pulling a network cable achieves nothing if the damage already happened through an API call three systems away.

    In order: revoke or suspend the agent's credentials, API keys and OAuth tokens, exactly as for a compromised service account. Kill the active session if the orchestration layer supports it. Freeze — do not delete — the memory store and tool-call history. If the agent runs through a broker or gateway, disable its registered tools there rather than chasing downstream systems one at a time.

    Freezing rather than deleting is where the technical and regulatory clocks touch. Whatever is lost in this hour is missing from the 72-hour notification, and from any later proceeding. Preservation precedes restoration, always.

    Hours 1 to 4 — Scope the blast radius

    Now the question is what the agent actually touched. Pull the complete tool-call log: every service invoked, every parameter passed, every response received. Cross-reference it against the agent's entitlements — what it could reach versus what it did reach.

    One point frequently missed: did the agent create artefacts along the way? A scheduled task, a forwarding rule, a new API key. Autonomous agents are often better at persistence than the people who built them.

    And if the entry vector looks like indirect prompt injection: which other sessions ingested the same poisoned content? This is rarely a single-victim event.

    A warning about reading those logs, drawn from our own experience and going beyond the original piece: tool responses are not automatically true. This week we had an endpoint in our own operation that acknowledged writes with HTTP 200 and a complete record — and wrote nothing. For forensics that means a log entry recording a successful action proves the agent received a success message. Not that the action occurred. And conversely, an action may have occurred whose response was lost. Blast radius is verified at the target system, not in the agent's log.

    Hours 4 to 8 — Notify before you are certain

    Legal, privacy and executive stakeholders need a first briefing well before forensics concludes. Waiting for certainty is how an incident becomes a disclosure failure.

    Three things belong in that briefing: what the agent could access, what the evidence currently shows it did access, and what remains unknown. Naming the third category explicitly is not weakness — it is what keeps a later correction from having been a false statement.

    This is also when the decision falls on whether other agents built from the same base configuration or tool integration should be paused as a precaution. A single vulnerable pattern replicates across an entire agent fleet before anyone notices. OWASP files this as ASI08, cascading agent failures.

    For entities in scope of NIS2, this is the handover point to the notification chain. The 24-hour early warning is deliberately short: significant incident yes or no, an initial assessment of suspected unlawful action, cross-border impact. It is not a forensic analysis and is not meant to be one.

    Hours 8 to 16 — Reconstruct the decision chain

    This is the part that differs fundamentally from conventional forensics. The task is not reconstructing what happened on a disk but why the model decided to do it.

    Walk the full prompt and response chain, including everything the agent retrieved before the anomalous action. The objective is the specific instruction — visible or hidden — that redirected its behaviour.

    One distinction determines the remedy: if the agent's output shows it recognised the instruction as suspicious and proceeded anyway, that is a guardrail gap. If it never flagged it at all, that is a detection gap. The fix looks different in each case.

    Hours 16 to 24 — Restore, but change something first

    An agent does not go back to its prior configuration. That is how the same incident returns within a week.

    Concretely: close the specific vector, sanitise the ingestion path, narrow the tool scope, or add an approval gate for whatever action class was abused. Re-issue credentials with narrower entitlements than before, never identical ones.

    And write the 24-hour summary while the timeline is fresh. It is the input for the post-incident review and frequently for the regulatory or customer notification.

    The framework to align this with

    Since December 2025 there has been a shared vocabulary for it. The OWASP Top 10 for Agentic Applications (2026), published on 10 December 2025 and reviewed by over a hundred practitioners, names ten risk categories from ASI01 to ASI10: agent goal hijack, tool misuse, identity and privilege abuse, agentic supply chain compromise, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading agent failures, human-agent trust exploitation and rogue agents.

    Its organising principle is least agency — the agentic counterpart to least privilege. Not only: what may the agent access? But: how much room to act does it need at all?

    The list does not replace the OWASP Top 10 for LLM Applications; it extends it. Most agent systems are also LLM applications and inherit those risks.

    In parallel, NIST launched its AI Agent Standards Initiative through the Center for AI Standards and Innovation on 17 February 2026. The accompanying NCCoE concept paper of 5 February 2026 names four focus areas that effectively describe the minimum architecture for any production agent: identification, authorisation, access delegation, logging. The problem it addresses is precisely stated — agents are commonly treated as generic service accounts, with no dedicated identity, no dedicated authorisation and no accountability.

    Build those four properly now and the eventual NIST guidance becomes a validation exercise rather than a remediation cycle.

    What has to be settled before the incident

    The phases above depend on preconditions that cannot be created at two in the morning:

    1. An agent inventory. Which agents run, under which identity, with which tools, with which entitlements? An AIBOM — the bill of materials covering agents, tools and MCP servers — is becoming the expected audit artefact. Auditors now ask for activity logs, permission reviews and kill-switch procedures.
    2. A distinct identity per agent. No shared service account. Without a distinguishable identity, containment by identity is impossible — and that is step one.
    3. A kill switch that has been tested. Who can stop an agent, with which command, in what time, including at three on a Sunday?
    4. Tool-call logging into the SIEM. Which tool, which parameters, which identity, which result. Without that telemetry the agent is invisible in monitoring, and after an incident there is nothing to reconstruct. The EU AI Act requires it for high-risk systems regardless.
    5. Approval gates for irreversible action classes. Deletions, bulk modifications, data exports, outbound communication, payments. Not because of the attacker, but because of the irreversible mistake. The collapse of the trading firm Step Finance in January 2026, following losses in the tens of millions, has been attributed to trading agents being able to execute large transfers without human approval.
    6. A rehearsed first 24 hours. Not as a principles document but as a tabletop against the clock — with the notification chain inside the exercise rather than appended to it.

    What separates this from a conventional incident

    Three sentences worth remembering:

    Contain by identity, not by host. With an agent, the network cable is almost always the wrong first move.

    Preservation precedes the patch. Freeze the memory store and tool-call history before anything is repaired. What is deleted is missing from the notification.

    Never restore into the configuration that just failed. Narrower, not identical.

    The rest is practice. Annam's conclusion matches our experience: organisations that handled an incident of this class well rarely had the best risk taxonomy on the wall. They had already walked through the first 24 hours once before.

    Sources

    The phase structure follows Annam's piece. The regulatory framing under NIS2 and the AI Act, the verification of the incidents cited, the additions on OWASP ASI and NIST, and the section on log trust are ours.