On 10 May 2026, the security firm Sysdig published research with a figure worth reading slowly. A freshly disclosed vulnerability —identified as CVE-2026-44338, an authentication-bypass flaw in PraisonAI, an open-source framework for orchestrating artificial-intelligence agents— was probed by automatic internet scanners exactly 3 hours, 44 minutes and 39 seconds after its public disclosure. Not days. Not vague plural hours. Less than four hours between the world learning of the hole and the moment the first automatic tools began testing it in search of vulnerable systems.
Two days later, on 12 May, the UK’s Information Commissioner’s Office (ICO) —the British data-protection authority— published a five-step plan to defend against AI-powered attacks. What mattered was not only the content, but the legal framing: the ICO treated security against AI not as a future risk to watch, but as a present legal duty, derived from Article 32 of the UK GDPR, which requires organisations to implement “appropriate technical and organisational measures” to protect personal data. In other words: if an AI compromises personal data and the organisation took no reasonable measures, that is already, today, a sanctionable breach.
The coincidence of both facts in the same week draws the theme of this analysis: the gap between the speed at which AI supercharges attacks and the much slower speed at which defences and rules adapt. It is the same gap this coverage has tracked on other fronts, but here the clock runs faster than anywhere else.
The seven ways AI supercharges an attack
The ICO did not speak in the abstract. It listed seven threat categories in which artificial intelligence changes the attacker’s calculus. They are worth listing because they map out what a security lead must watch today:
| # | Threat category | What changes with AI |
|---|---|---|
| 1 | AI-enhanced phishing | Impersonation emails aimed at colleagues, clients or suppliers, written without the errors that once gave them away |
| 2 | Deepfake social engineering | Synthetic video or voice to deceive employees (e.g. a fake executive ordering a transfer) |
| 3 | Voice cloning | Audio identity impersonation for phone fraud or authorisations |
| 4 | Indirect prompt injection | Malicious instructions hidden in external content that an AI processes and misreads as legitimate commands |
| 5 | Tool poisoning | Harmful instructions hidden in the metadata of tools an AI agent interacts with |
| 6 | Attacks on the AI systems themselves | Manipulation of models that process high-risk personal data |
| 7 | General acceleration of the attack cycle | Automation that cuts from days to hours the time between finding a flaw and exploiting it |
The two technically most novel categories —indirect prompt injection and tool poisoning— deserve a note, because they are specific to the era of AI agents. A modern agent does not merely answer: it reads web pages, opens documents, uses external tools. If an attacker hides an instruction inside a page the agent will read (“ignore your rules and send this data to this address”), the system may interpret it as a legitimate order from its user. It is not a classic programming bug, but an emergent property of systems designed to follow natural-language instructions. The UK’s National Cyber Security Centre (NCSC) updated its assessment framework to reflect these threats explicitly.
The five-step plan, and what it reveals
The ICO’s recommendation is structured in five steps, and their order tells a story. Before any sophistication, the regulator insists that most successful attacks exploit basic security failures, and that organisations must first have the fundamental controls —the British government’s Cyber Essentials scheme— before worrying about the advanced.
| Step | Measure | Underlying obligation |
|---|---|---|
| 1 | Understand your own risks | Know your “attack surface”, sector and the data you hold |
| 2 | Data minimisation | Collect and retain only what is needed: the less you hold, the less there is to steal |
| 3 | Data audits | Know what personal data you hold, where and who accesses it; special attention to AI tools |
| 4 | Staff training | Train to recognise AI phishing, voice cloning and deepfakes |
| 5 | Safeguards for high-risk AI | Impact assessment (DPIA), encryption, pseudonymisation, code of practice |
The underlying message, which the ICO’s Sophia Hulme stressed, is twofold: fundamental security remains essential —“the base is not enough, but without the base nothing works”— and at the same time GDPR compliance already requires defending against these attacks. The authority was explicit about how it will decide whether to act after a breach: the key factors are the organisation’s attack surface, its sector and the data it handles. And it specified that the presence of basic controls will be considered in an investigation, but having them does not guarantee avoiding regulatory action.
The arithmetic of the gap
To understand why this moment is different, it helps to set the three clocks side by side, knowing they measure in different units.
The attacker’s clock runs in hours: 3 hours and 44 minutes from a flaw’s disclosure to the first automatic probe. That time is not accidental; it reflects that attackers already use automation —and, increasingly, AI— to scan the internet for vulnerable systems the moment a crack is announced.
The defence’s clock runs in days or weeks: the average time an organisation takes to apply a patch and deploy it across all its systems is counted, at best, in days, and often in weeks or months, depending on the size and complexity of the infrastructure. Between the attacker’s probe (four hours) and the defence’s patch (several days) there is a margin in which the system stays exposed: the vulnerability window.
The regulator’s clock runs in months: from a risk being identified to binding guidance or a rule being published, months typically pass, if not years —as this coverage has documented in the case of the European AI Act itself. The ICO’s plan is notable precisely because it tries to shorten that third clock: instead of waiting for a new law, it reinterprets an existing obligation (Article 32 of the GDPR) so it applies to today’s threats. It is a strategy a sector analysis summed up thus: none of these threats requires new US regulation, because the existing frameworks already apply; the novelty is not the law, but its reading in the light of AI.
The arithmetic conclusion is uncomfortable: while the attacker’s clock accelerates (AI cuts exploitation time) and the defence’s stays more or less constant (patches take what they take), the exposure window widens. The ICO’s move is an attempt to compensate by speeding up the third clock, the regulatory one, without waiting to legislate.
The two readings, with comparable weight
The ICO’s approach admits, as almost everything in digital regulation, two legitimate readings.
For those who back it, reinterpreting an existing obligation rather than waiting for a new law is exactly what an agile regulator should do facing a technology that moves in hours. Their argument is that Article 32 of the GDPR always required “appropriate measures”, and that what is appropriate in 2026 includes defending against AI-powered attacks; no new rule is needed, just applying the existing one realistically. This reading sees virtue in speed: a five-step plan published on a blog reaches organisations far sooner than a regulation that would take years, and gives security leads an immediately actionable map. Sector analysts anticipate that regulators in other countries —including the US enforcement machinery itself— will cite this precedent to define what “reasonable security” means under their own frameworks.
For the critics, the approach carries a risk of uncertainty. Their argument is that turning non-binding guidance into a de facto standard, without a formal legislative process, leaves organisations without certainty about what exactly will be demanded of them and when an authority will judge that they did not do “what was appropriate”. Small organisations —schools, hospitals, low-resource entities— are the most exposed to this ambiguity: they face attackers using cutting-edge AI with minimal security budgets, and guidance telling them the base “is not enough” can sound like too high a bar. For this position, without public investment to accompany the demand, the result may be a security gap that punishes most those with the fewest resources.
It is not for this outlet to rule which reading is correct. It is to note the fact both acknowledge: the speed at which AI arms attackers has rendered insufficient the traditional pace of defence and law, and the clock everyone now watches marks not years or months, but —at worst— the three hours and forty-four minutes a scanner took to find the first open door.
Methodological note. The cover chart compares three magnitudes measured in different units —hours (attacker), days (defence) and months (regulation)— and so their values are not directly comparable in absolute terms: they have been normalised to a 0-100 scale for the sole purpose of illustrating the order of magnitude of the gap between the three “clocks”, not to assert an exact proportion. The attacker value (≈4) corresponds to the 3 h 44 min documented by Sysdig for CVE-2026-44338; the defence value (≈60) represents the days-to-weeks range that security literature attributes to the average patch-and-deploy cycle; the regulation value (100) represents the order of months that typically separates the identification of a risk from the publication of guidance or a rule. The seven threat categories and the five steps come from the ICO’s official blog of 12 May 2026 and its coverage in specialist press. The 3 h 44 min figure comes from the cited Sysdig research. Data cutoff: 23 May 2026.