Turning Point

The upheaval will come faster than most people expect, and the drivers, on reflection, will be incredibly obvious.

Australian businesses have already dipped their beak in AI, mostly in the name of ad hoc efficiency, occasionally heavily embedded and sometimes even deployed directly to the face. But the extremely mild impact on employment in Australia indicates that at this point, AI is largely used as a tool that supports the people already employed. In some circles, this is leading to a feeling that this is all going to work out fine. There is no fire. An chat with your friendly LLM, doesn’t seem to hold a threat of vendor lock-in. However, these integrations have been low risk, with little structural change. The is smoke is clearly on the horizon.

But the fire is coming. The changes that will hit employment hard will be the forced adoption of fully autonomous systems: AI agents running with minimal oversight. I’ll make a case for when and why this might happen.

Resistance is futile

Despite the wild proliferation of capability, organisations are largely resisting adoption of semi- or fully automated systems. It makes sense. Handing over the work completely to established American megacorps will be a strategic double sacrifice. Fully committing puts a few outcomes on rails. It guarantees some level of employment drawdown, This will naturally lead to a kind of institutional offloading of knowledge. Over time, agent-optimised markdown libraries will have the real working understanding to execute the grind of the work. This will be a difficult and expensive change to reverse. And in a bid to mitigate risk and lower implementation cost, organisations will likely silo this transition to a single private company. One company that will then hold the only means to get the work done. The saviour of this reality appears to be, strangely enough – China. More on that later.

Government will be among the most resistant of all. It has an inherent bureaucratic caution and no mandate (at least initially) to minimise cost at the expense of employees. Beyond that, it faces political pressures, data sovereignty/security rules, and union action. What scenario could shatter a social obligation to keep employing people, not AI systems?

Loose assumptions

The prevailing assumption is that the move to an agentic, autonomous workforce will be driven by ideology, competitive pressure, or leaders who just want to cut costs. To be fair, they all apply. But none of them is the forcing scenario that breaks the social contract and causes mass job losses. Choices can be avoided, I have decades of expertise in this. What I see coming is a cost organisations can’t choose to avoid.

Melting the sea ice

The key driver, at least initially, will be economics in adversarial environments. AI adoption by white hats and black hats is predictably stratospheric. Over the last 12 months, the trend has become clear: the number of reported vulnerabilities is increasing. Right now, a significant number of new vulnerabilities are published every week. It’s accelerating every day.

The severity is escalating too. Critical issues were at 75 per week on average through 2025; it’s averaged over 350 per week in the last two months. The current response is for the human workforce to patch, and patch, and patch again. Inevitably some changes have already occurred in business practices to be more proactive or to lock environments down further. These are expenses and will be more. The human employees are getting faster with the aid of AI but automated mass exploitation for fun and profit requires no board-level business decisions. The marginalised individuals or, worse, organised groups with a thirst for destruction don’t need permission to hand over control to autonomous systems. The gap between disclosure and disaster is shrinking rapidly.

PHP vulnerability

Recently, a critical vulnerability in PHP (PHP2Shell), software that runs a large share of the world’s websites, required a suitably urgent response. The corporate response, I’m sure, was swift for all the reasons businesses face when protecting their digital systems. The instructive example is a sector totally allergic to automated AI: public education.

Take a public school system. Education was the 2nd largest sector to be targeted, so it would treat the flaw as the top priority it is. Say the system runs 1,000 schools. Its field team is 500 technicians, each working about 1,300 hours a year on site, or 650,000 hours in all. Above them, a few dozen senior technicians and service managers escalate and co-ordinate.

A conservative estimate of the effort that one vulnerability would take:

That’s about 1,300–3,400 hours. It excludes central office staff and any IT staff schools hire themselves. So the true figure is higher.

One vulnerability. And that’s not clean-up. It’s simply the proactive move the job requires. To foreshadow where I’m going, multiply by however many critical vulnerabilities arrive next month, and then by however many more arrive before the end of the year.

Backburning

That table is the cheap scenario. It assumes there is time to do it properly.

Historically, most critical flaws never get abused by people with ill intent. But the value proposition goes up with our increasingly connected society. Only about five a week land on CISA’s list of vulnerabilities known to be exploited in the wild. Comforting, until you look at the timing. Around a quarter of those were being exploited within a week of disclosure. Even this is a leisurely exploit time compared with the PHP example. Cloudflare reported millions of attempts to exploit it within hours of disclosure.

Say it takes roughly a week (it does) to get a human to every one of those 1,000 schools, and that’s if nothing else is on fire. AI shrinks the attacker’s side of that race to hours, or, much less when they deploy autonomy.

My somewhat obvious observation, is that the turning point arrives when the gap between disclosure and exploit gets shorter than even the most flexible schedule can accommodate. An AI-assisted technician is faster, but the level of agent access required to move really quickly is currently off the table in all but the loosest government organisations. Education holds deep reserves of the public’s private information, so no school system will hand over that access lightly. The moment will arrive with a snap of workloads and response times colliding with only one possible outcome.

More autonomy for the agents will be the only answer.

The ocean of potential costs

Of course patching is only the first cost. As attackers use AI, more attacks will succeed, and each successful attack brings much larger costs.

1. Patching public surfaces. The first and smallest cost: staff time to find, fix and check exposed services, every time a new critical flaw lands.
2. Breach notifications. Depleting goodwill and damaging the brand.
3. Being sued. Customers taking action when their personal data is exposed.
4. Losing ideas. The cost of stolen intellectual property.
5. Fixing the damage. Rebuilding and repairing internal systems once they’ve been broken.

Automated, AI-driven patching won’t be only about saving money on patching. It is about preventing these much larger costs, which follow every exploit that gets through. As attacks become faster and more frequent, people alone will not be able to close the gaps quickly enough.

Why the change is unavoidable

Government departments don’t manage headcount for economic output. Their mandate is to deliver a service, and part of that is keeping the service environment safe. That safety has a cost, and the cost cannot exceed a certain amount, because departments and governments have budgets to manage. Budgets become a deeply political issue when the numbers stop adding up.

One PHP flaw barely dents the budget. It’s somewhere between a fifth and a half of one percent of the field team’s yearly hours. But these vulnerabilities won’t arrive one at a time on a schedule. And we know the numbers are increasing. Take an illustrative twenty critical flaws a year that need the kind of attention PHP would. The patching load becomes 26,000 to 67,000 hours, or 4 to 10 percent of the whole program, spent running to stand still. Then the critical count quadruples, as it just did. That’s 16 to 41 percent.

Plenty of these programs are genuine success stories, keeping costs down and delivering. Even well-built, well-run programs will have their operating models melted in the face of these numbers.

So the shift to AI-assisted patching, or to an AI system that simply manages it, will not be ideological. It will be unavoidable. And it won’t stop at assisted. The social contract will be bent into submission.

“Just centralise it”

The obvious objection is that the answer is centralised auto-patching and a move to SaaS. Both are already happening. But in public education there is a firm ideological position that schools should be as autonomous as possible, within constraints.

That autonomy is precious. It matters, in practice because centralisation in education has been bitterly fought. It has translated to less choice, in technology stacks, less choice means monocultures. In a monoculture, adaptation and the adoption of better practice are obliterated.

This example can be generalised to embody one of the most distasteful elements of corporate security models. It doesn’t have to be this way and there is plenty of scope for other answers.

Fiddling at the edges

The reality is, even the most aggressive moves to centralise and brick-in every orifice that offers a view of the countryside will take time and money itself. The uncomfortable truth many organisations will have to grapple with is the cost of running aggressive automated AI systems is plummeting. One miscreant with a Raspberry Pi jacked into an Ethernet port will also eventually mean a move to zero trust security models. When every surface on an internal network is in scope, the patching and re-patching will be like trying to stop a swarm of locusts with a stern look.

There is a storm coming and anyone wanting to go zero trust with a patchwork of systems, or keep the ability to innovate, or hold on to refined, efficient systems that might not comply with centralised security models, will look in the same direction.

The China exit

Earlier I said the saviour here is, strangely enough, China.

The meta argument that warps these assumptions on adoption is that the often unmentioned barrier to AI adoption isn’t capability. It’s trust. It’s the smouldering ember that burns at the heart of hesitations to handing an autonomous agent the keys to your network. Trusting whoever runs it: their servers, their legal jurisdiction, their profit motivation, their terms of service next year. For government, that trust is somewhere between absolutely not and illegal.

Without going into why, it is a fact that some of the most capable models now come out of Chinese labs with their weights published. However, open-weight models can come from anywhere. And their capabilities are nothing to be dismissed. Anyone can download them and run them on hardware they control, in their own data centre or a cloud down the road. It’s very possible to structure a setup where the data never leaves the building. You don’t have to trust the vendor. There is no vendor.

Yes, Canberra banned the DeepSeek app from government devices. The app phones home but it needs to be stated clearly, the weights don’t. A model sitting on your own racks is just software, and government knows how to audit software. Lock-in goes too, because there’s no single company holding the only means to get the work done. One of the biggest barriers to adoption quietly falls over.

Firestorm

The increasing hours required to triage the volume of threats will continue. I’m boldly speculating that budgets will not grow with this trajectory. The friction from the shortfall will weaken the resistance. The speed required to respond will ultimately be the combustion. These issues will multiply each other into an unsolvable conundrum and incinerate all that stands against it. For government in particular, autonomous AI systems will not be adopted because anyone wants them. They will be adopted because the alternative can no longer be paid for and their duty of care will not bend with real breaches. And if government, one of the most resistant organisations, is forced to adopt them, most businesses will have already done so.

Capable open-weight models will make these changes palatable. Automated AI systems built, deployed and used as a daily part of the workplace will put us in uncharted territory. The investment to get there will not be small, so the slippery slope to expand and get a return will be almost frictionless. I fear the worst of humanity will lead the way with the social contract already compromised and an opportunity to drive costs down. Competition will force others to follow. Mass lay-offs ensue.

Sources and notes

%%

Working notes (not for publication)

Planned graph: from theoretical to actual risk

A layered funnel chart over time, showing how raw counts narrow into real problems for organisations:

1. All published CVEs per year
2. Critical CVEs (CVSS 9.0+)
3. Known exploited vulnerabilities (CISA KEV additions)
4. Exploited vulnerabilities in software schools actually run (PHP, Microsoft, edge devices)
5. Optional: time from disclosure to exploitation, to support “faster than people expect”

Every figure needs a source; the published post gets an appendix stating precisely where each number comes from.

Data gathered so far (from search results; verify against the primary pages before publishing)

AI says Caveats to address

• Some raw CVE growth reflects more organisations issuing CVEs (CNA expansion) and the Linux kernel logging everything, not just worsening security. Worth a dry footnote.
• The exploited layer is rising, but far less dramatically than raw counts. Lean into it rather than overstate.
• The cost estimate is small relative to a departmental budget, so the argument rests on frequency and escalation, not one incident.
• School-employed IT staff (est. 600 to 1,000) is an estimate, not a published figure.