Frontier AI: defend at machine speed

Key takeaways · 1 minute

ENISA, the ESRB and European supervisory authorities are converging on one point: advanced AI models are shortening the time available between discovery, exploitation and response.

Action: identify the assets, dependencies and evidence involved before treating the topic as an isolated requirement.

The phrase “machine-speed threat” could easily become a slogan. In the European publications issued in July 2026, however, it describes a concrete operational problem. ENISA says frontier AI models are compressing the vulnerability-management lifecycle and attack chain, from discovery to exploitation, and calls for operational capabilities able to face machine-speed threats.1

The European Systemic Risk Board says frontier AI models may increase the speed, scale and sophistication of cyberattacks. Its assessment of systemic cyber risk for the European financial system moved from “elevated” in March 2026 to “severe” in June.2 European financial supervisory authorities subsequently called for a consistent, risk-based approach centred on prevention, detection and management of these risks.3

The conclusion is not “let an AI defend the information system autonomously”. It is more demanding: reduce the time between a change in the threat and a defensive decision without removing the controls required for security and availability.

Faster threats do not make security fundamentals obsolete

ENISA explicitly argues that security fundamentals matter more, not less, in the AI era.1 The agency highlights risk-based vulnerability prioritisation, integration of defensive capabilities into the software-development lifecycle, human-gated workflows, assume-breached architectures and defensive capabilities able to detect, correlate and respond much faster.1

The European Commission follows the same broad logic. Its 7 July 2026 Action Plan describes AI both as a way to improve cybersecurity and as technology that can be misused to automate attacks, identify weaknesses and increase their speed and scale.4

This shift therefore removes neither inventories nor patch management, segmentation, backups or logging. It makes their operational latency more visible.

An accurate asset inventory refreshed once a quarter may be too stale to answer a vulnerability that is exploitable today. A robust patching procedure that takes five days before the first decision may leave too large a window. A SOC that detects quickly but must manually discover who owns the affected application loses part of its advantage.

Decision time is often the new bottleneck

A defensive chain can be represented as six successive intervals:

FIG. 01Measure defensive latency instead of a vague automation level

Stage	Operational question	Common bottleneck
Discovery	Is a new threat known?	Sources are not integrated
Exposure	Are we actually affected?	Stale inventory or dependencies
Prioritisation	What is the potential impact?	Missing criticality and context
Decision	What can we do now?	Unclear ownership or guardrails
Action	Contain, patch or compensate?	Entirely manual process
Verification	Has risk actually been reduced?	No automated feedback

This table is not an ENISA framework. It is Cybercoria analysis derived from the temporal compression described by the authorities.1 2

It helps avoid the superficial response of simply buying more AI. The slow link may be missing criticality data, an approval process, poor dependency knowledge or an inability to deploy a patch without creating an outage.

Automating response does not mean automating every decision

ENISA explicitly refers to the need for human-gated AI workflows.1 That point matters: as defence accelerates, bad automation can itself become an operational risk.

Cybercoria proposes separating actions according to reversibility and blast radius. An organisation may pre-authorise evidence collection, enrichment, correlation or limited containment while requiring human approval for a global identity-policy change, a high-impact production patch or a destructive action.

A policy could be represented as:

response_policy:
  evidence_collection:
    mode: automatic
  exposure_correlation:
    mode: automatic
  reversible_containment:
    mode: pre_authorised
  production_patch:
    mode: human_gated
    canary_required: true
    rollback_required: true
  destructive_action:
    mode: human_gated

This is a design example, not a normative recommendation from the authorities. Its purpose is to make explicit where automation can save time and where false-positive or availability risk justifies a human decision.

ENISA also highlights a paradox: an expected increase in patch frequency may itself lead to more service disruption.1 A fast defence that breaks the critical service is not a mature defence.

Inventory freshness becomes a security property

When a newly exploitable vulnerability appears, the first question is not “how many servers do we own?”. It is “which actually exposed components use this technology, in which applications, with which dependencies and with what business impact?”.

A map or inventory can therefore be complete on paper and still be too old for an operational decision. As the threat cycle contracts, freshness of relationships matters more: component → workload → service → exposure → identity → data → business function.

That does not mean recalculating the entire information system every second. It means identifying which data changes quickly enough to become critical to a defensive decision and selecting an appropriate refresh mechanism for each.

Constructed case: a vulnerability appears in an exposed API

Consider a constructed case. A new severe vulnerability is published in a component used by application servers. The organisation does not start with a CVE list; it starts with the question “are we exposed?”.

Its inventory identifies seven instances of the component: three accessible behind an Internet-facing API, two used only internally and two present in the disaster-recovery environment. Application relationships immediately identify the supported critical service, its owner and its identity dependencies.

A fast but controlled chain can then be:

automatically ingest the vulnerability information;
correlate it with software inventory and exposed assets;
calculate context from exposure, privileges, data and supported function;
apply a reversible compensating measure where possible;
test the patch in a representative environment;
perform a canary deployment after human approval;
retain rollback capability;
verify that exposed instances are no longer vulnerable.

AI may help enrich, correlate or prioritise in this scenario. But the performance of the process depends just as much on inventory quality, dependency knowledge, deployment pipelines and rollback capability.

The case does not establish a universal response time. An industrial system, a transactional banking application and a stateless API do not have the same change risk or patching options.

Frontier AI also creates concentration and dependency questions

The ESRB warning is not limited to attack speed. It also highlights the concentration of leading AI providers outside the European Union and the strategic dependencies that may result.2

The ESAs likewise place the issue within existing ICT governance and risk-management frameworks and emphasise prevention, detection and management.3

For a CIO or CISO, the question therefore becomes twofold: how can defensive AI capabilities be used without creating a new critical dependency, and how will the organisation continue operating if the analysis service itself is unavailable, degraded or produces uncertain results?

A fast defensive architecture should retain fallback paths, exportable data and decisions that human operators can understand.

What the European publications do not prove

They do not demonstrate that all attacks are now driven by frontier AI models. Nor do they demonstrate that a SOC using AI is automatically more mature than one that does not.

ENISA describes its recommendations as an initial set rather than an all-inclusive checklist.1 The Commission Action Plan complements existing frameworks; it does not turn every technical proposal into a new regulatory requirement for every organisation.4

The signal that makes this a Watch topic lies elsewhere: several European authorities converged within weeks on the compression of the attack-defence cycle and the need to adapt operational capabilities.

Measure four latencies before adding another AI layer

Before buying or developing another automation layer, a security team can measure four intervals across recent incidents or exercises:

threat known → internal exposure identified;
exposure identified → decision made;
decision made → mitigation applied;
mitigation applied → effectiveness verified.

Cybercoria proposes no universal target for those four measurements. Their purpose is to locate wasted time.

If exposure analysis takes hours because inventory is incomplete, the issue is data. If a decision waits for an unknown owner, the issue is governance. If the patch is known but cannot be tested quickly, the issue is the delivery pipeline. If verification remains manual, the issue is observability.

Machine-speed defence therefore does not necessarily start with AI. It starts by removing the delays that the information system imposes on itself.