Anthony Hines · August 2026
Most technology functions have a list of jobs that never quite got finished. The asset inventory that is almost complete and almost accurate, the data extracts copied somewhere convenient for a project years ago but for some reason never got deleted, the leavers process that works most of the time, the patching backlog that grows a little faster than it shrinks, and the systems that went out of vendor support years ago and never make the cut for funding and sit ring-fenced behind a risk acceptance that has been renewed so many times nobody remembers who first created it. Anyone who has spent a career in technology can probably recite a version of this list, and for a long time it has felt acceptable, because while the deficits were real, a justifiable, threat-led, risk-based approach was taken to prioritising remediation and we never envisaged any threat that could identify all of our gaps, everywhere, all at once.
The industry has spent decades building defence-in-depth on the honest assumption that no single layer is bulletproof and an imperfect control is tolerable because whatever slips past it should be caught by the next layer, and the assumption held for as long as mapping a pathway through the holes in one layer after another took a skilled attacker weeks of expensive effort.
The average time between a vulnerability being disclosed and being exploited was roughly sixty days in 2018/2019 based on Mandiant's numbers, by 2023 it was five days, and in its most recent analyses the majority of the vulnerabilities being exploited had no fix available at all and the zero-day now the norm. In February 2026, Mozilla patched twenty-two Firefox vulnerabilities surfaced by one of Anthropic's models, fourteen rated high severity, and in April Anthropic disclosed that a newer model had found a denial-of-service flaw that had sat in OpenBSD for twenty-seven years. Those findings came from the defensive side of the research world but nothing keeps that capability on the side of the good guys.
We have always been awake to zero-day attacks, and detecting and blocking them is what a good part of the security product market exists to do. AI finding new vulnerabilities and turning them into exploits at speed makes that job harder, but ought we not be able to rely on the rest of the defence-in-depth to hold?
Mapping and chaining together the gaps in our defences that were already there is work that modern AI is particularly suited to, and that has created a sudden change in the equation on which decades of risk-based choices were made.
Meanwhile, organisations are in a race to take advantage of this new technology and are deploying AI agents directly into the middle of their own accumulated technology debt, where these agents will do what they were built to do, which is reach everything that the permissions allow and answer with whatever data they can find.
An assistant wired into the corporate estate does not break permissions, it exercises them, all of them, on behalf of whoever asks. Microsoft's deployment guidance for Copilot addresses this problem, and in 2024 Gartner reported around forty per cent of rollouts delayed by three months or more while firms dealt with permissioning issues. The AI assistant that hands an intern a document written for the remuneration committee is faithfully executing twenty years of access decisions that nobody ever went back to revisit before they deployed AI.
Boards hear far less about the risks their legacy technology stack poses to AI adoption than about the AI-enabled attackers, though the former is the part they can do most about.
Every IT security practitioner has known for a long time that they can't protect what they don't know about, and it's no secret that most large organisations struggle to produce a complete and accurate picture of what they run. IT estates grew through mergers and acquisitions, through project teams provisioning what they needed at the time but never cleaned up, through cloud subscriptions that never touched procurement processes, and creating and maintaining it all was the unglamorous work that nobody ever got promoted for.
Alongside the estate nobody mapped sits the estate everyone knows about and has learned to live with. The end-of-life systems that no vendor supports and no change budget quite stretched to, surviving behind compensating controls designed against the threat picture at the time they were written. Autonomous reconnaissance works from whatever is reachable, not from the inventory database, and it does not get bored. The forgotten server is the first thing it finds and an agent integrated across the estate will happily connect to systems that appear on no diagram and exist in no asset register.
Europe's operational resilience rules already expect a firm to identify and classify what it runs and to keep a register of the technology arrangements it depends on, and the UK regime expects the services that matter to be mapped to the assets they run on, and so the regulators might assume this is already taken care of.
The question a board can ask is whether our IT inventory is complete and accurate, and how we would know if it wasn't.
While most firms can point to their systems of record, I suspect far fewer can say where the data went. The extracts taken for a migration, the reporting spreadsheet that became a critical dependency, the shared drives and collaboration spaces that accumulated a decade of working files and the software-as-a-service tools each holding their own slice.
Data minimisation has been a legal requirement for personal data in Europe since 2018, and a requirement is hard to press against data sprawl that nobody can see. The reality of retrieval-based AI ends the illusion of comfort, because an AI assistant will answer from any copy it can reach, however it came to be reachable.
The question a board can ask is where the data that matters has been copied to, and how anyone would know.
The access that assistant exercised was nobody's mistake, because system entitlements accumulate over careers, joiner/mover/leaver processes are often imperfect, and recertification is completed by managers facing volumes that make genuine examination implausible when the control designed for hundreds of entitlements meets hundreds of thousands. Service accounts, tokens and now agents carry standing access of their own, and in many enterprises they outnumber the people. When an AI agent inherits a person's permissions, the entitlement that has sat unused since a role change five years ago is suddenly used routinely.
The question a board can ask is when anyone last proved who and what can reach the things that matter most, whether the proof covers all the agents and service accounts as well as all the people, and how we know we know them all.
Every deferred patch in the queue, like every entitlement nobody revoked, was deferred for a reason that made sense at the time, whether it be a change risk, an unsupported dependency, or a system that cannot come down during trading hours, and the reasons still hold. What has gone is the time those reasons used to buy. When exploiting a known weakness took weeks of skilled effort, deferral was a calculated delay. Now that trying every door costs an attacker nearly nothing, a deferred patch is an open door with a published address, and a backlog that was signed off under the old economics is due a fresh read under the new ones.
Accurate inventories were always required, access review is among the oldest expectations in the audit repertoire, data minimisation has been law for years, and change and patch discipline sit inside control frameworks that long predate any of the current AI capabilities, and so none of this brings a new obligation. Defensible choices get recorded, a control assessed as effective, a risk formally accepted, an exception approved with an expiry date that has been extended more than once. That is how risk management works when finite resources are set against competing demands.
The trouble is, a debt that was cheap to hold comes due the day an attacker's AI tools, or the firm's own AI agents, drive a truck right through the holes it left.
The question a board can ask is whether each significant exception, brought back to it today, still sits inside the risk appetite it believes it holds.
It's a question that should be asked not least because under the senior managers regime every acceptance sits ultimately under a named, accountable owner, boards of listed companies are being asked under the governance code to declare the effectiveness of their material controls, and Europe's resilience rules place responsibility for technology risk on the management body itself.
Fixing this needs nothing new, just the old work done to a standard that would survive somebody else's review. Know what you run, including the parts that are embarrassing. Find out where the data went. Prove who and what can reach the things that matter, and retire the access that shouldn't be there. Measure how long known gaps stay open rather than counting how many sit in the queue.
Boards being asked to approve AI programmes would be wise to ask on what foundations this new capability will sit, and how much of the AI budget should go to shoring up those foundations first.
That list of jobs that never quite got finished has always been the real work of security, and for years leaving parts of it undone was tolerable. If the new AI capabilities now inside the estate, and the ones pointed at it from outside, don't force us to reconsider that tolerance, then what will?