AI Agents

    AI agents and cyber risk: prepare your incident response before the alarm goes off

    October 10, 2026·15 min read

    Attackers have agents. Who is gathering the evidence in your organisation? Documented threats, the agent’s own attack surface and six decisions to make before the alarm goes off.

    Attackers have agents. Who is gathering the evidence in your organisation?

    In June 2017, I was in the offices of a large Danish shipping company when the computers around me began shutting down. One by one. I disconnected my own computer from the network and saved it. For the company, it was too late. It took a long time and an enormous effort from the IT department before the damage was dealt with.

    The attack was disguised as ransomware, but designed to destroy. It entered through a compromised software update, and because the entire network was connected, nothing could stop it. No AI was involved. It still spread faster than anyone could react, and I have never forgotten what it looked like.

    I thought about it again when DTU's notification arrived. On Friday, October 2, DTU published a notification about a cyberattack. Up to 200,000 current and former users may be affected.

    Unauthorised parties had compromised DTU profiles and used them to access DTUBasen, the university's identity and access management system. From there, data was extracted: civil registration numbers, names, home addresses and, for active users, the names and telephone numbers of next of kin. The information goes back to 2003.

    DTU has contained the attack, brought in external specialists and reported the breach to the Danish Data Protection Agency. The university says it cannot establish how many people were actually affected.

    Let me be precise about what we do not know. The notification says nothing about how the profiles were compromised. It does not mention AI. I have no basis for saying the case has anything to do with AI agents, and I will not speculate.

    It does, however, raise the question every security department must be able to answer today:

    When the alarm goes off on a Friday morning, how quickly can we gather the evidence ourselves, understand the scope and decide on the right interventions?

    Answering that well has become harder over the past year. Some attackers have agents doing the work. Defenders may have access to the same tools, but in many organisations they are not yet integrated into incident preparedness.

    I teach people to build and use AI agents, at ITU and in companies. Here I bring together the picture for those responsible: what is documented on the attack side, what defenders can use agents for, where the agent itself becomes a risk, and what needs to be ready before your own Friday morning.

    1. Attackers use agents as a workforce

    In November 2025, Anthropic published what it calls the first documented case of a large cyberattack carried out without substantial human involvement. The actor, which Anthropic assesses with high confidence to be Chinese state-sponsored, targeted around 30 organisations. AI did 80–90 percent of the work. Humans intervened at four to six critical decision points per campaign. It succeeded in a small number of cases.

    At the time, it was a single case. Ten months later, it is a pattern.

    Anthropic's September 2026 threat report describes operators routinely running agent swarms: a lead agent divides reconnaissance and post-intrusion work into tasks and sends them to many subagents working in parallel.

    One actor, probably based in China, targeted around 50 organisations, and one of its workflows produced more than a dozen possible zero-day findings in a single month. A group affiliated with ShinyHunters extracted more than 2,100 sets of Azure AD tokens from over 40 companies' tenants in around 34 hours.

    On September 8, Google's Threat Intelligence Group (GTIG) reported a multiagent framework with which attackers went from a compromised cloud resource to a running campaign harvesting credentials at scale in under six hours.

    In May, GTIG also described a zero-day exploit it assesses with high confidence to have been developed with help from an AI model. Google disrupted the campaign before it was used at scale.

    Attacks at agent speed

    Documented figures from 2025–2026.

    FigureMeaningSource
    80–90%of the work in a state-sponsored attack against around 30 targets was performed by AIAnthropic, Nov. 2025
    2,100+sets of Azure AD tokens extracted from over 40 tenants in around 34 hoursAnthropic, Sep. 2026
    54%click rate for AI-generated phishing emails versus around 12% for traditional emailsMicrosoft Digital Defense Report 2025

    It is the pace that has changed. The same attacks, but faster, cheaper and more scalable.

    Model 1. Selected figures from the attack side.

    And on the most everyday front, Microsoft puts the click rate for AI-generated phishing emails at 54 percent, compared with around 12 percent for traditional ones.

    Perspective

    None of the sources shows that all attackers now use autonomous agents. Much of what hits Danish companies is still stolen credentials, unpatched systems and phishing. The difference is that agents make the same attacks faster, cheaper and more scalable. It is the pace that has changed.

    I discussed, worked on and thought about these issues for a long time while at Nexi Group, where I was part of the team behind MitID for a year and a half. Threats to the central digital infrastructure serving more than five million users were discussed every day, 24/7.

    2. The time between a flaw and its exploitation has disappeared

    The figures in this year's major threat reports tell the story better than any opinion.

    Mandiant's M-Trends 2026 puts the average time from disclosure of a vulnerability to exploitation at approximately minus seven days. Exploitation routinely happens before a fix exists. A few years ago, the median handover from the group gaining initial access to the group exploiting it took over eight hours. In 2025, it took 22 seconds.

    CrowdStrike's Global Threat Report 2026 measures the average time criminal groups take from an initial foothold to lateral movement at 29 minutes. The fastest took 27 seconds. You read that correctly: 27 seconds.

    The time has gone

    From vulnerability to exploitation and lateral movement.

    FigureMeaningSource
    −7 daysaverage time from disclosure to exploitation of a vulnerabilityMandiant M-Trends 2026
    22 sec.median handover from access broker to exploiter in 2025 (previously over 8 hours)Mandiant M-Trends 2026
    29 min.average time from foothold to lateral movement. Fastest: 27 secondsCrowdStrike Global Threat Report 2026

    Attackers have automated their bottlenecks. Patching cycles are still often measured in weeks.

    Model 2. The pace on the attack side.

    Put those figures alongside your own reality. Patching cycles are often measured in weeks. Approving an urgent intervention in production often takes hours. The first manual timeline of an incident can take an entire working day, because data must be pulled from five systems across three time zones.

    That is where the gap emerges. Attackers have automated their bottlenecks. In 2017, it was a worm without AI. Today, attackers have agents that can plan, adapt and work for hours without a break.

    3. Vulnerabilities are now found faster than anyone can fix them

    In April, Anthropic launched Project Glasswing: selected partners, including AWS, Apple, Microsoft, Google and CrowdStrike, gained access to a non-public model, Claude Mythos Preview, to find vulnerabilities in critical software before attackers do.

    The May status update is the most interesting part. Together, the partners had found over 10,000 high- or critical-severity vulnerabilities in their own software. In the open-source part, 90.6 percent of findings assessed by independent security firms were real. But of the approximately 530 serious flaws reported to maintainers, only 75 had been fixed.

    Project Glasswing

    Status update, May 2026.

    FigureMeaningSource
    10,000+high- or critical-severity vulnerabilities found by partnersAnthropic, May 22, 2026
    90.6%of independently assessed open-source findings were realAnthropic, May 22, 2026
    75 of 530reported serious flaws had been fixed by maintainersAnthropic, May 22, 2026

    The bottleneck has moved. From finding weaknesses to verifying, disclosing and fixing them.

    Model 3. Finding has become easy. Fixing has not.

    Anthropic itself writes that progress in software security used to be limited by how quickly vulnerabilities could be found, and that the constraint is now how quickly they can be verified, disclosed and fixed.

    Counterargument: VulnCheck examined 1,061 vulnerabilities found with AI assistance. Only 14 of them, 1.3 percent, are confirmed to have been exploited. VulnCheck assesses the impact so far as real but modest, and says AI primarily increases the volume of findings, giving defenders a chance to fix them first.

    For a CIO, the point is the same, whichever interpretation you favour. The bottleneck has moved from finding weaknesses to sorting, verifying and fixing them at a matching pace. That task falls to your own team.

    4. In Denmark, the threat level has risen and leadership is accountable

    On September 24, the Danish Agency for Societal Security, which now includes the Centre for Cyber Security, raised the threat level for destructive cyberattacks from medium to high. Its reasoning concerns Russia, which the agency says is waging hybrid warfare against the West and showing greater willingness to take risks. The agency particularly addresses companies and authorities responsible for critical infrastructure. The threats from cybercrime and cyberespionage were already rated very high in the overall assessment from November 2025.

    Meanwhile, the Danish NIS 2 Act has been in force since July 1, 2025, while telecommunications, energy and finance have their own rules. The law makes cybersecurity a leadership responsibility. Management must approve the measures and oversee them. In the most serious cases, a person at executive level in a private company that is an essential entity under the law may temporarily be prohibited from exercising management functions.

    Status as of October 2026

    The threat level for destructive cyberattacks is high (raised September 24, 2026). The NIS 2 Act (Act No. 434 of May 6, 2025) has been in force since July 1, 2025. This is not legal advice: always confirm the status against retsinformation.dk and the Danish Agency for Societal Security, and involve your own legal department.

    This makes incident preparedness a matter for executive management and the board. When a board asks how you will handle an incident, the answer must be able to show that you have practised it.

    5. Defenders have agents too

    The most solid figures I have found come from a randomised trial of Microsoft's Phishing Triage Agent in Security Copilot. Security analysts with the agent found up to 6.5 times as many real threats per working minute and achieved 77 percent better accuracy in their assessments than the control group.

    Humans with agents

    Randomised trial, Phishing Triage Agent.

    FigureMeaningSource
    6.5×up to this many real threats found per working minuteBono, arXiv 2511.13860
    77%better accuracy in assessments than the control groupBono, arXiv 2511.13860
    53%more time spent on emails that were actually maliciousBono, arXiv 2511.13860

    The agent took the noise; the human had time for the dangerous cases. That is the pattern to design for.

    Model 4. The study was conducted by Microsoft on its own product and concerns a bounded task.

    What matters is where the benefit came from: the agent sorted the queue and explained its assessments. Analysts then spent 53 percent more time on emails that were actually malicious. The agent took the noise, and the human had time for the dangerous cases. That is the pattern to design for. It is humans working with agents who win here.

    Two caveats: the study was conducted by Microsoft on Microsoft's own product, and it concerns phishing triage, a bounded task with a clear ground truth. It tells us less about complex incidents.

    Key figures

    Since November 2025, Security Copilot has gradually rolled out as part of Microsoft 365 E5 and E7. It includes 400 Security Compute Units per month for every 1,000 user licences, up to 10,000 SCU per month. They do not roll over to the next month. If you have E5, you may already be paying for capacity nobody on the team uses.

    Google and CrowdStrike promise similar benefits from agent-based SOC solutions, but as far as I have been able to find publicly, without published independent measurements behind them. Treat the figures as marketing until you have measured for yourselves.

    The third route is local models with open weights, if incident data must not leave the organisation.

    6. The agent is itself a new attack surface

    This part rarely gets much space in vendors' presentations.

    Logs contain text controlled by the attacker: user agents, URLs, DNS queries, usernames. When a language model reads your logs, it also reads that text. If an attacker writes instructions into a field, the model may follow them.

    A research preprint from May 2026 tested exactly that. Log summarisation was the most vulnerable task: one type of manipulation succeeded in 96 percent of trials without defences. With the strongest defences, the average success rate fell from 26.6 to 11.8 percent. Lower, but not zero. The study used one small model and has not been peer reviewed, but the mechanism is real.

    CrowdStrike reports that more than 90 organisations have been hit by malicious prompt injection. GTIG describes malware that uses configuration files to make AI coding assistants execute commands, and trojanised MCP servers, the small integrations that give agents access to tools, published on PyPI and in official GitHub repositories.

    In December 2025, OWASP published a top 10 of risks for agentic applications. At the top are agent goal hijacking, misuse of tools, and misuse of identity and privileges.

    Four rules for an agent in incident preparedness

    The consequence for the security team is concrete.

    RuleRequirementWhy
    AccessRead-only access and nothing elseThe agent's tools and permissions are themselves an attack surface.
    ContentLogs and documents are data, never instructionsThe attacker controls the text in log fields.
    EvidenceEvery claim points to a specific log entrySo the analyst can verify it against the source.
    AuthorityInterventions require a human with a mandateExamples: disabling accounts, isolating systems.

    Every agent is a new identity: with an owner, least privileges and inclusion in your access reviews.

    There is one final consequence, especially for those who own identity and access. Every agent the organisation deploys is a new identity with access and privileges. It must have an owner and only the permissions the task requires, and it must be included in your access reviews like any other account. Microsoft is building this into the platform with Entra Agent ID and Agent 365. I work as an administrator on Agent 365 and see it in practice every day. A pleasure for a hands-on person like me.

    The DTU case involved an identity and access management system. That is the kind of system your agents will soon need to be registered in too.

    7. What the first hours look like when the agent works for you

    1. Extraction and filtering. Millions of log lines must not go into a prompt. Searching, filtering and parsing are done with ordinary deterministic tools: KQL, Python, grep. The model receives relevant excerpts. Time zones and event IDs are preserved throughout, or the timeline falls apart.

    2. The timeline. The agent assembles events from identity, endpoint and applications into one timeline, with each line referencing its source. This is work that often takes hours manually.

    3. The hypotheses. The agent suggests competing explanations for initial access and the subsequent sequence, and separates observations from assumptions. Missing evidence becomes concrete questions: which logs are missing, who do we need to ask? Which actors might be involved? How long has it been going on?

    4. Verification. The analyst checks important claims against the source. This is where professional expertise lies, and it is the step that must not be skipped under time pressure.

    5. Containment. The agent proposes a prioritised list of interventions with expected operational consequences. The human decides. In utilities and production, IT and OT must remain separate, and the person responsible for operations must be involved in the assessment. A course or an agent gives no authority to change industrial control systems during an attack.

    6. Remediation and prevention. A fix is tested in a sandbox with a rollback plan. Then you use the same kind of capability Glasswing has demonstrated to look for related weaknesses elsewhere in your own code and configuration.

    If the incident is a zero-day in an identity component, the work starts elsewhere. The agent sorts the vendor's advisory, maps which identities and privileged accounts are exposed, and drafts communications and a runbook. Humans decide what gets shut down, and in what order.

    Scenario

    Imagine that, in step two, the agent sees a series of logins at 03:12 on a service account from an unknown IP range. It concludes that this is scheduled maintenance because a field in the log says so. The field was written by the attacker.

    What catches the error? Two controls. The rule that text in log fields is never an instruction or an explanation in itself. And the requirement that every maintenance conclusion must match a registered change in your change log. No change, no all-clear.

    No change, no all-clear.

    That is why I believe a good exercise must show both a useful result and an error the participants discover themselves. Verification belongs to the profession, on an equal footing with the analysis itself.

    8. Six decisions to make before the alarm goes off

    Agents for incident preparedness cannot be introduced in the middle of an incident. Most of the work happens beforehand.

    1. Which model may see your logs. There are three realistic routes: a local model with open weights, an approved EU-hosted model, or the tools in your existing security platform. Open weights and open source are not the same, and neither local operation nor EU hosting alone determines security. Assess quality, data flows, subcontractors and licences. And distinguish ordinary Microsoft 365 Copilot from Security Copilot.

    2. What the agent can reach, and with which permissions. Read-only access to bounded sources, traceable tool use and a fixed output format. Treat the agent's access keys as seriously as production credentials. Anthropic recommends the same for AI API keys in its September report.

    3. Who may decide on interventions. Who may disable accounts, isolate servers, shut down an integration? Write it down before the agent proposes it.

    4. An exercise environment with ground truth. Synthetic logs with noise, false leads and missing data. Without ground truth, you cannot know whether the agent helps or merely sounds convincing because it lacks context.

    5. Whether the environment can be recreated. Version-pinned dependencies, exercise data, configuration examples and instructions that a colleague who did not build it can follow. My suggestion is that it must be possible to recreate it within a day on an agreed platform. Otherwise the tools will not be ready when they are needed. It is not acceptable for the public or users to be without a critical service for a long time.

    6. What you measure. Time from alarm to a verified basis for decisions, the quality of the analysis and the number of errors the team catches. Without measurements, the next budget discussion becomes a matter of opinion.

    9. Three questions for your next management meeting

    1. How long did it take us last time to produce a timeline of a security incident, and who produced it?

    2. Which AI tools are we already paying for in security, and who on the team uses them today?

    3. If an agent tomorrow proposes disabling 40 accounts, who says yes, and on what basis?

    If you can answer all three, you have a starting point. If not, you know what the next exercise needs to address.

    10. What I work on

    I help companies with a tailored master class in AI agents for cyber incident preparedness. The team works hands-on with cases from its own daily work using synthetic data, builds and tests its own agents, and practises the first hours of an incident with an agent as an assistant. The focus is adapted to the team: incident analysis in the SOC, identity security, or governance of the agents you deploy yourselves. The programme can be taken as half a day, one day or two days. Write to me if you would like to hear what it could look like in your organisation.

    Sources

    Status as of October 2026. Figures from threat reports are reproduced as reported by the vendors themselves.

    Originally published on Substack October 10, 2026.